Grant group access to the GitLab Agent’s CI/CD Tunnel
The GitLab Agent for Kubernetes provides a secure connection between a Kubernetes cluster and GitLab. Until GitLab 14.2, the CI/CD Tunnel could only provide access to a cluster from CI/CD jobs ran in the Agent for Kubernetes’s configuration project. In GitLab 14.3, we introduced support for groups to access the Agent through the CI/CD Tunnel. As a result, every project under the authorized group has access to the cluster without the need to register an agent for every project.
Edit a table’s structure visually in the new wiki editor
Editing a Markdown table that has 9 columns and 25 rows is one thing. But adding a tenth column to that table in Markdown? That involves very repetitive and error-prone edits to every row. One mistake or misplaced | and the table fails to render.
The new WYSIWYG Markdown editor in the wiki lets you quickly and easily insert a table using the button in the toolbar. After selecting the initial number of rows and columns, however, dealing with the structure of the table can be more difficult. In GitLab 14.3, you can now click on the caret icon in the top right corner of any selected cell to add or remove columns and rows, either before or after the selected cell. Now, as your content scales, the complexity doesn’t follow suit.
Group-level permissions for Protected Environments
Typically, large enterprise organizations have an explicit permission boundary between developers and operators. Developers may deploy and test the application on lower-tier environments such as the development environment. Operators are responsible for deploying to higher-tier environments such as the production environment. Furthermore, in organizations where there are potentially thousands of projects under a single group, ensuring that all of the project-level protected environments are properly configured is not a scalable solution.
In this release, we are introducing group-level protected environments, based on the deployment tier as the identifier. This enables operators to responsibly lock down deployments to higher tier environments without unnecessarily preventing developers from doing their work as the maintainers of their individual projects.
Next Generation SAST to reduce Ruby false positives
GitLab SAST historically has been powered by over a dozen open-source static analysis security analyzers. These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month. These tools use a variety of different approaches for identifying vulnerabilities from basic regex pattern matching to abstract syntax tree parsing which can lead to issues with false positives. GitLab’s Secure tools already offer vulnerability fingerprinting allowing you to dismiss these false positives persistently, however, we want to go a step further and not require this manual triaging.
Today we’re releasing the first version of our proprietary static application security testing engine built in-house and maintained by GitLab’s Static Analysis and Vulnerability Research groups. Initially, this tool is focused on Ruby and Rails to help reduce false positives. GitLab’s Next Generation SAST engine takes the learnings we’ve gained from years of running and maintaining the open source security tools that power GitLab SAST today and applying state-of-the-art program analysis techniques. This new engine leverages program representations that include data and control flow analysis and a novel pattern extraction language which can be used for both vulnerability detection and to eliminate vulnerabilities that may have been falsely reported by other integrated security tools. This engine also provides us the framework to start integrating different types of security testing offered within GitLab Ultimate to make them all smarter.
As your source code management, CI/CD, and security scanning provider, GitLab is uniquely positioned to deeply integrate security testing across your software development lifecycle (SDLC) to bring you fast, accurate, and scalable security results. We’re excited about the future of this new proprietary engine, and we look forward to expanding its availability, language coverage, and detection capabilities in future releases.
Include GitLab CI/CD configuration based on conditions
include is one of the most popular keywords to use when writing a full CI/CD pipeline. If you are building larger pipelines, you are probably using the include keyword to bring external YAML configuration into your pipeline.
In this release, we are expanding the power of the keyword so you can use include with rules conditions. Now, you can decide when external CI/CD configuration should or shouldn’t be included. This will help you write a standardized pipeline with the ability to dynamically modify itself based on the conditions you choose.
Use variables in other variables
CI/CD pipeline execution scenarios can depend on expanding variables declared in a pipeline or using GitLab predefined variables within another variable declaration. In 14.3, we are enabling the “variables inside other variables” feature on GitLab SaaS. Now you can define a variable and use it in another variable definition within the same pipeline. You can also use GitLab predefined variables inside of another variable declaration. This feature simplifies your pipeline definition and eliminates pipeline management issues caused by the duplicating of variable data. Note - for GitLab self-managed users the feature is disabled by default. To use this feature, your GitLab administrator will need to enable the feature flag.
