Sep 22, 2021 - Nicole Schwartz  
14.3

GitLab 14.3 releases Project Security Policies & Next Gen SAST

GitLab 14.3 released with project-level security scan execution policies, next generation SAST to reduce Ruby false positives, group-level permissions for protected environments, group access for the GitLab Kubernetes Agent, and much more!

Today, we are excited to announce the release of GitLab 14.3 with project-level security scan execution policies, next generation SAST to reduce Ruby false positives, group-level permissions for protected environments, group access for the GitLab Kubernetes Agent, and much more!

These are just a few highlights from the 40+ improvements in this release. Read on to check out all of the great updates below.

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 14.4 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is feistel

@feistel started contributing to GitLab Pages in September 2020. In the last 4 months, they have made continuous contributions to improve Pages by adding features, fixing bugs, and helping us clear the Pages issues backlog. In 14.3, they took the initiative to work on some of the release group deliverable issues for the milestone, allowing us to focus on reviews and giving us more time to work on other issues.

They have also started contributing to other Go projects like in GitLab Runner, GitLab Shell, the container registry, and more. They also engage in code reviews. They recently created a tool that allows us to check if we can upgrade the Go version of a project using a simple CLI tool, see an example. Here is a full list of their contributions. Thank you!

Key improvements released in GitLab 14.3

Project-level DAST and secret detection scan execution policies

We have completed the first iterative step toward our vision of bringing unified security policies to GitLab. Users can now require DAST and secret detection scans to run on a regular schedule or as part of project CI pipelines, independent of the .gitlab-ci.yml file’s contents. This allows security teams to separately manage these scan requirements without allowing developers to change the configuration. You can get started with these policies by navigating to the Security & Compliance > Policies page in your project.

Project-level DAST and secret detection scan execution policies

Grant group access to the GitLab Kubernetes Agent’s CI/CD Tunnel

The GitLab Kubernetes Agent 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 Kubernetes Agent’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.

Edit a table's structure visually in the new wiki editor

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.

Next Generation SAST to reduce Ruby false positives

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.

`Include` GitLab CI/CD configuration based on conditions

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.


Other improvements in GitLab 14.3

Audit events for changes to protected branch settings

GitLab now records additional audit events when changes are made to protected branches. Specifically, events are now created when changes are made to:

  • Who is allowed to push to the branch.
  • Who is allowed to merge to the branch.
  • Whether or not code owner approval is required.
  • Whether or not force pushing is allowed.

This enables you to have more visibility into what is going on in GitLab and ensure that controls have been put in place and that they have not been changed. This can help to ensure you successfully pass audits that require separation of duties. When controls have been changed, the audit events will help you see when and who made the change to dig deeper and understand why.

Thanks to Adrien Gooris from Michelin for this contribution!

Audit events for changes to protected branch settings

Filtering for project-level Value Stream Analytics

Value Stream Management for projects just got better. Now you can filter the work items in a stage by milestone, label, author, or assignee to view stage times for the issues and merge requests you are most interested in.

Filtering for project-level Value Stream Analytics

OAuth access tokens issued with expiration by default

By default, any OAuth access tokens issued after this release will have a 2 hour expiry window. Previously, OAuth access tokens never expired, which is insecure. You can disable this option by unchecking the Expire Access Token checkbox on the OAuth application UI.

Filter roadmap view by set dates

When you view your team’s progress over a large timeframe, the horizontal nature of the roadmap canvas adds a ton of horizontal scrolling.

With this release, you can reduce the infinite scrolling interactions by using the predetermined date range options in the top left of the roadmap search bar. You can jump to the dates you need and the roadmap quickly zooms in on your area of interest.

Filter roadmap view by set dates

Filter pipelines in Pipeline view by source

The project pipelines list at CI/CD > Pipelines shows all pipelines for a project, but you could not filter the list by pipeline source. Now, in GitLab 14.3, you can easily filter the pipeline list based on sources like api, schedule, merge_request_event, and so on.

GitLab Runner on IBM POWER9 (Linux OS)

If you use IBM POWER9 (ppc64le compute architecture) systems for compute-intensive workloads, you have not had runners available from GitLab. You’ve had to rely on your own runner, or on a runner built and maintained by IBM. While this allowed you to run your GitLab CI/CD jobs on POWER9, it was less than ideal. The binary was not part of the GitLab Runner release and support lifecycle. You can now install and use a runner built and supported by GitLab to execute GitLab CI/CD jobs on IBM POWER9 (Linux OS).

GitLab Runner on IBM POWER9 (Linux OS)

New API available for the Dependency Proxy

To reduce build times, avoid Docker Hub rate limits, and reduce your external dependencies, you can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub.

Previously, you had no way of knowing how the Dependency Proxy was being used. For example, for your GitLab group, maybe you wanted to know how many container images were added to the cache, or you wanted to view details about items already in the cache.

Now you can use the GitLab GraphQL API to quickly find these important details. You can use the new API to uncover details about the images and their underlying components, so that you can know for certain which container images and tags are being used in your group.

Next up, we’ll use the new API to deliver a significant update to the user interface. GitLab issue 250865 proposes an update to the UI to add helpful metadata for quick reference.

License Compliance now supports Java 15

License Compliance now supports Java 15 projects. Set the variable LM_JAVA_VERSION to 15 in order to utilize this Java version for your project.

GitLab Pages support splat (wildcard) and placeholder redirects

GitLab Pages supports a variety of redirect rules, including redirects and rewrites. In this release, you can now also use splats (aka wildcard) and placeholders to redirect your Pages content to specific pages.

Support for Kubernetes 1.20

In GitLab 14.3, we added support to Kubernetes version 1.20. GitLab users can benefit from having recent cluster versions in many features, such as the GitLab Kubernetes Agent, Auto DevOps and Cluster Management Project.

You can find the list of supported versions and related timelines in our documentation.

Geo replicates Pages deployments

With GitLab Pages, you can publish static websites directly from a repository in GitLab. In a disaster recovery scenario, it was already possible to regenerate Pages sites after failing over to the new primary site. However, Geo now also replicates Pages deployments. This provides extra protection against data loss and reduces recovery time by removing the need to regenerate Pages after a failover.

GitLab chart improvements

  • We have removed the extra Ingress path for the Sidekiq administration panel, after addressing the original need. This resolves several complications with external Ingress providers, such as Google’s GCE and Amazon’s ALB.

Audit events for merge request approval setting changes

Audit events are now created if changes are made to the merge request approval settings in a project. You can now see if a change is made to the following policies:

  • Requiring user password for approvals.
  • Allowing modifying merge request approvals in a merge request.
  • Needing to get new approvals when a new commit is added to a merge request.

You can now be confident that once you configure approval settings, you can quickly see if they are changed. This is a great way to show auditors that controls were put in place and have not been removed or modified.

Thanks to Adrien Gooris from Michelin for this contribution!

Audit events for merge request approval setting changes

GPG key displayed on a user’s profile page

In previous versions of GitLab, there was no simple way to view a user’s GPG key. We’ve added a button on profile pages that allows you to see a user’s GPG key with one click.

GPG key displayed on a user's profile page

Show DORA API-based Deployment Frequency metric for Premium customers

This change enables the DORA API-based Deployment Frequency metric in group-level Value Stream Analytics for Premium customers. This can help you understand how often you are delivering increased value to your users. Also, higher deployment frequency means you are able to get feedback and iterate more quickly in delivering improvements and features.

Preview multimedia in the new Wiki editor

Including multimedia in a wiki page is a great way to effectively and efficiently communicate complex content. GitLab Flavored Markdown supports embedding video and audio content for playback. However, when you’re editing the page, the media is represented in code by the path to the file, and that can lead to confusion or uncertainty around whether you uploaded the right version of the file.

In GitLab 14.3, the new WYSIWYG Markdown editor in the Wiki renders and plays back existing video and audio content on the page right in the editor. Now you can be sure that the recording_final.mp3 or walkthrough.mp4 you attached is indeed the right asset without leaving the editor. Currently, this only applies to media already included in the page when it’s loaded into the editor. We will add support for inserting new video and audio content from the editor in an upcoming milestone.

Thanks to Lee Tickett for this helpful contribution!

Preview multimedia in the new Wiki editor

GitLab Runner 14.3

We’re also releasing GitLab Runner 14.3 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

Support merging CI/CD rules arrays with !reference

The YAML !reference tag introduced earlier this year helps you reuse and combine configuration. This is a very flexible way to combine frequently reused configuration with job-specific configuration in one or more jobs. However, using it with the rules keyword was not supported yet. In 14.3, we’ve added !reference support to the rules keyword, so you can now mix and match rules more easily, including with configuration from different files. You can use the CI/CD pipeline editor to view the merged configuration.

Support merging CI/CD rules arrays with `!reference`

Search PyPI.org for packages not found in GitLab

You can use the GitLab Package Registry as a private PyPI index alongside your source code and pipelines. It’s common for teams to rely on a combination of private and public indexes. PyPI supports this by offering an -index and extra-index-url arguments that allow you to specify multiple indexes to download from. When installing a package pip will download the best match it can find, between all available indexes, not in priority order. For example, the latest version of a package will be chosen regardless of any priorities between indexes, simply because it’s the latest version. This presents a security concern for some organizations as it can make you vulnerable to dependency confusion attacks. For example, a developer may install a package thinking it was being sourced from a private GitLab project, but it is actually downloaded from the public repository instead.

You can use the GitLab Package Registry as a private PyPI index alongside your source code and pipelines. Moving forward, when you attempt to install a PyPI package from your GitLab project and the package isn’t found, the request is forwarded to PyPI.org. In other words, if the package name exists in your private registry, it’s excluded from the lookup from the public repository. This is done so that an attacker can’t inject code by uploading a package to PyPI with the same name and higher version.

This new feature is auto-enabled for GitLab.com and can be turned off by self-managed customers by using their Continuous Integration and Deployment Admin Area settings. This feature is currently limited to Premium customers, but GitLab-#337862 will move the feature to Core.

Static Analysis analyzer updates

GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.3. These updates bring additional coverage, bug fixes, and improvements.

  • Brakeman updated to version 5.1.1 - MR, Changelog
    • Enhanced performance
  • Eslint updated to version 7.30.0 - MR, Changelog
  • PMD Apex updated to version 3.38.0 - MR, Changelog
  • Spotbugs updated to version 2.28.6 - MR, Changelog
  • Semgrep updated to version 0.65.0 - MR, Changelog
    • Performance improvements, ignore minified files, improved error messaging

If you are including the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI template, you will need to update your CI configurations. If you want to remain on a specific version of any analyzer, you can now pin to a minor version of an analyzer. Pinning to a previous version will prevent you from receiving automatic analyzer updates and require you to manually bump your analyzer version in your CI template.

Remove deploy freeze period via the UI

To prevent unintentional deployments of your CI/CD jobs, you can set deploy freeze periods. Up until recently, it was possible to remove a deploy freeze period only by using the API. This release improves the ease of use by allowing you to remove a deploy freeze period directly from the GitLab interface. This feature is a community contribution. Thank you @jayaddison for adding this useful feature to GitLab!

Remove deploy freeze period via the UI

API endpoint to retrieve on-call user

Identifying who is on-call should be quick and easy, especially if there’s an active incident. This release adds an API call that returns the on-call users for each Escalation Policy of a project. Responders can use their preferred workflow, the GitLab UI or API, to find out who is on call.

GitLab Environment Toolkit (GET) 1.2 now available

The GitLab Environment Toolkit, a tool to deploy and operate production GitLab instances based on our Reference Architectures, has now reached version 1.2.

Highlights of 1.2 include support for AWS RDS, Elasticache, Geo on cloud native hybrid deployments, as well as all settings in Omnibus and Helm. To learn more about GET, the complete list of all changes, as well as upcoming breaking changes, please read the release notes.

Omnibus improvements

  • GitLab 14.3 bundles Mattermost 5.38, an open source Slack-alternative. The newest release comes with many features and fixes, including a database migration that may take several minutes to complete. Refer to the Mattermost blog post for more details.

Bug fixes

Some of the notable bug fixes in 14.3 are:

Performance improvements

In every release, we continue to make great strides improving the performance of GitLab. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million users!

In GitLab 14.3, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.3 are:

Usability improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI polish gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 14.3, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.3:

Deprecations

Audit events for repository push events

Audit events for repository events are now deprecated and will be removed in GitLab 15.0.

These events have always been disabled by default and had to be manually enabled with a feature flag. Enabling them can cause too many events to be generated which can dramatically slow down GitLab instances. For this reason, they are being removed.

Planned removal date: May 22, 2022

GitLab Serverless

GitLab Serverless is a feature set to support Knative-based serverless development with automatic deployments and monitoring.

We decided to remove the GitLab Serverless features as they never really resonated with our users. Besides, given the continuous development of Kubernetes and Knative, our current implementations do not even work with recent versions.

Planned removal date: May 22, 2022

Legacy database configuration

The syntax of GitLabs database configuration located in database.yml is changing and the legacy format is deprecated. The legacy format supported using a single PostgreSQL adapter, whereas the new format is changing to support multiple databases. The main: database needs to be defined as a first configuration item.

This deprecation mainly impacts users compiling GitLab from source because Omnibus will handle this configuration automatically.

Planned removal date: May 22, 2022

NFS for Git repository storage deprecated

With the general availability of Gitaly Cluster (introduced in GitLab 13.0), we have deprecated development (bugfixes, performance improvements, etc) for NFS for Git repository storage in GitLab 14.0. We will continue to provide technical support for NFS for Git repositories throughout 14.x, but we will remove all support for NFS in GitLab 15.0. Please see our official Statement of Support for further information.

Gitaly Cluster offers tremendous benefits for our users such as:

We encourage users currently using NFS for Git repositories to plan their migration by reviewing our documentation on migrating to Gitaly Cluster.

Planned removal date: Jun 22, 2022

OmniAuth Kerberos gem

The omniauth-kerberos gem will be removed in our next major release, GitLab 15.0.

This gem has not been maintained and has very little usage. We therefore plan to remove support for this authentication method and recommend using the Kerberos SPNEGO integration instead. You can follow the upgrade instructions to upgrade from the omniauth-kerberos integration to the supported one.

Note that we are not deprecating the Kerberos SPNEGO integration, only the old password-based Kerberos integration.

Planned removal date: May 22, 2022

Release CLI be distributed as a generic package

The release-cli will be released as a generic package starting in GitLab 14.2. We will continue to deploy it as a binary to S3 until GitLab 14.5 and stop distributing it in S3 in GitLab 14.6.

Planned removal date: Dec 22, 2021

Rename Task Runner pod to Toolbox

The Task Runner pod is used to execute periodic housekeeping tasks within the GitLab application and is often confused with the GitLab Runner. Thus, Task Runner will be renamed to Toolbox.

This will result in the rename of the sub-chart: gitlab/task-runner to gitlab/toolbox. Resulting pods will be named along the lines of {{ .Release.Name }}-toolbox, which will often be gitlab-toolbox. They will be locatable with the label app=toolbox.

Planned removal date: October 22, 2021

Removals

Introduced limit of 50 tags for jobs

GitLab values efficiency and is prioritizing reliability for GitLab.com in FY22. In 14.3, GitLab CI/CD jobs must have less than 50 tags. If a pipeline contains a job with 50 or more tags, you will receive an error and the pipeline will not be created.

Removal date: September 22nd, 2021

List project pipelines API endpoint removes name support in 14.3

In GitLab 14.3, we will remove the ability to filter by name in the list project pipelines API endpoint to improve performance. If you currently use this parameter with this endpoint, you must switch to username.

Removal date: September 22, 2021

Use of legacy storage setting

The support for gitlab_pages['use_legacy_storage'] setting in Omnibus installations has been removed.

In 14.0 we removed domain_config_source which had been previously deprecated, and allowed users to specify disk storage. In 14.0 we added use_legacy_storage as a temporary flag to unblock upgrades, and allow us to debug issues with our users and it was deprecated and communicated for removal in 14.3.

Removal date: September 22nd, 2021

Important notes on upgrading to GitLab 14.3

  • When there is a Horizontal Pod Autoscaler (HPA) controlling the desired number of Pods, we will not provide the .spec.replicas value. We expect from rolling out this change, there will be a 1-time behavior regression, where during the first upgrade on an existing chart install the Replicaset will reduce itself down to a single Pod temporarily, rather than the count of currently running Pods. This will fix itself after the HPA kicks in and rescales the deployment. The reason this change is being implemented is to ensure that Pod capacity is not reduced unnecessarily during chart upgrades, but instead Pods will continue to remain properly scaled during deployments.
  • GitLab 14.3 contains post-deployment migrations that swap columns on tables potentially affected by primary key overflows. Read the GitLab 14.3 update instructions for further guidance and to learn what tables are affected.

Changelog

Please check out the changelog to see all the named changes:

Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating

Check out our update page.

Questions?

We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Free: For small teams, personal projects, or GitLab trials with unlimited time.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project.
  • Premium: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Ultimate: Great with many CI/CD jobs. Every public project gets the features of Ultimate for free irrespective of their plan.

Cover image licensed under CC0

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license

Try GitLab risk-free for 30 days.

No credit card required. Have questions? Contact us.

Gitlab x icon svg