With GitLab 14.5 we're introducing security scanning for Infrastructure as Code (IaC) configuration files. Like all our SAST scanners, we've chosen to make this capability available for all customers for free to encourage secure coding practices with the rise of IaC. The initial version of this IaC security scanner supports configuration files for Terraform, Ansible, AWS CloudFormation, and Kubernetes and is based on the open-source [Keeping Infrastructure as Code Secure (KICS) project](https://kics.io/). This new IaC scanning capability joins our [existing Kubernetes manifest SAST scanner](https://docs.gitlab.com/ee/user/application_security/sast/#enabling-kubesec-analyzer).
You can now add a README section to your GitLab profile! This is a great way to tell others about, your interests, how you work, or anything else you want! To add a README section, create a new public project with the same name as your user account and add a new [README file](https://docs.gitlab.com/ee/user/project/repository/index.html#readme-and-index-files). The contents of that file are automatically shown on your GitLab profile.
When performing a failover, systems administrators use different tools depending on the underlying architecture. On a single-node Geo site, administrators can use the `gitlab-ctl promote-to-primary-node` command. However, multi-node sites did not support this command and required manual editing of configuration. This was cumbersome for large environments because it required updating dozens of configuration files.
Now, administrators can use `gitlab-ctl geo promote` on any node of a Geo secondary site to promote it to a primary. In a disaster recovery scenario or planned failover, this saves precious time and reduces potential errors when promoting a secondary site to a primary. This command also makes it easier to script the failover process.
As of GitLab 14.5, the commands `gitlab-ctl promote-to-primary-node` and `gitlab-ctl promote-db` are deprecated and will be removed in GitLab 15.0.
You can now define and enforce values for merge request approval settings at the group level. These values cascade and are used by any projects within the group. Group-level merge request approvals make it easy for organizations to ensure proper separation of duties across all teams. You only have to specify settings in a single location now, rather than needing to update and monitor every project.
When these settings are set at the group level, you:
- Can be confident that projects will use consistent separation of duties workflows.
- Do not need to manually check that every project has not had its settings modified.
Connecting a Kubernetes cluster with the GitLab Kubernetes Agent simplifies the setup for cluster applications and enables secure GitOps deployments to the cluster. Initially, the GitLab Kubernetes Agent was available only for Premium users. In our commitment to the open source ethos, we moved the core features of the GitLab agent for Kubernetes and the ability to use CI/CD with Kubernetes to GitLab Free. We expect that the open-sourced features are compelling to many users without dedicated infrastructure teams and strong requirements around cluster management. Advanced features remain available as part of the GitLab Premium offering.
Jupyter notebooks are key to data scientists' and machine learning engineers' workflows, but the file structure makes code review challenging. Often, the files can't be reviewed properly, and users are forced to accept those changes or treat their repositories as stores of data versus collaborative projects.
Now GitLab automatically strips out the noise and displays a cleaner version of the diff for these files. Human-readable diffs make it easier to review the substance of the change, without worrying about the formatting pieces that Jupyter Notebooks need.
