GitLab 15.1 released with SAML Group Sync and SLSA level 2 build artifact attestation
GitLab 15.1 released with SAML Group Sync, SLSA level 2 build artifact attestation, links to included CI/CD configuration, enhanced visibility into value stream with DORA metrics and much more!
These are just a few highlights from the 30+ improvements in this release. Read on to check out all of the great updates below.
Join us on June 23rd as we celebrate DevOps! GitLab co-founder and CEO, Sid Sijbrandij, will introduce best-selling author and DORA co-founder, Gene Kim. Gene will share his research and expectations for the future of DevOps then GitLab VP of Product, David DeSanto, will share how GitLab is evolving The One DevOps Platform to meet that future. We'll also unveil a new program to support your career aspirations. You won't want to miss this one-hour virtual event. Reserve your seat now!
To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.2 release kickoff video.
MVP
This month's Most Valuable Person (MVP) is awarded to
feistel
In the 15.1 milestone, feistel has helped to reduce documentation technical debt and improve GitLab documentation. Their dedication has helped to ensure GitLab documentation is consistent, clear, and easy to follow.
In addition, feistel proactively tackled seven issues to ensure the Package stage is FIPS compliant, which ensures that GitLab is compliant with the U.S Federal Government standards.
Throughout all of this, feistel worked iteratively and collaboratively. Thank you, feistel! 🙌
You can now map a group in your identity provider to a self-managed GitLab group using SAML group links. Previously, this feature was only available for GitLab.com. Group memberships are updated when a user logs into GitLab through their SAML provider.
This new functionality decreases the workload for GitLab administrators and reduces onboarding time for group members.
With the addition of the four DORA metrics tiles to the Value Stream Analytics dashboard, you can now track team performance and value flow from ideation to customer delivery.
Additionally, we added a new trend chart for the DORA Time to restore service metric to provide insights into software stability and reliability trends. This new chart shows information about how long it takes an organization to recover from a failure in production.
This is the third DORA chart that’s available out of the box in GitLab. We plan to keep improving the visibility into DORA metrics and also add charts for the fourth metric: Change failure rate.
Supply-chain Levels for Software Artifacts (SLSA) is a security framework that helps ensure the security and integrity of your software supply chain. By default, GitLab Runner is now capable of generating and producing SLSA-2 compliant attestation metadata for build artifacts.
If the artifact is stored in a registry, then the attestation metadata is stored alongside the artifact in that registry. Otherwise, the metadata is in rendered in a plain text .json file that’s stored with the artifact.
This new attestation information can help you more easily verify that your build artifacts have not been tampered with. To enable this feature, simply set RUNNER_GENERATE_ARTIFACTS_METADATA = "true" in your .gitlab-ci.yml file.
A typical CI/CD configuration uses the include keyword to import configuration stored in other files or CI/CD templates. When editing or troubleshooting your configuration though, it can be difficult to understand how all the configuration works together because the included configuration is not visible in your .gitlab-ci-yml, you only see the include entry.
In this release, we added links to all included configuration files and templates to the pipeline editor. Now you can easily access and view all the CI/CD configuration your pipeline uses, making it much easier to manage large and complex pipelines.
We’ve made several enhancements to how you view data for each stage of the Value Stream Analytics dashboard. In the stage table, we added the Last event column to show the most recent workflow event, and you can now sort items by duration.
These changes make it easier for you to rearrange the events and discover insights faster. These insights could be in detecting bottlenecks that are slowing down delivery, or finding opportunities to reduce the time spent on each stage of the software supply chain.
Users can now retrieve their personal access tokens (PATs) by the PAT ID.
Previously, users could only list all their personal access tokens using the API.
There was no endpoint to support querying them one by one.
Getting started with GitLab Workflow for VS Code has been challenging: install the extension, only to learn you needed to follow several extra steps to set the extension up properly. The most difficult aspect of getting started was generating a personal access token with the right scope and adding it to the extension.
Release v3.47.0 of GitLab Workflow now supports OAuth for GitLab.com, removing the need to manually generate a token. This is a huge step in making it easier for you to start using GitLab inside of VS Code.
We’re also releasing GitLab Runner 15.1 today! GitLab Runner is the lightweight, highly-scalable agent that runs your CI/CD 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.
Using shared SaaS runners for public projects have the same CI/CD minutes limits as the corresponding tier the project is on. Users managing groups could see the total runner usage for the entire group, but could not see the usage for individual projects in one place. This made it hard to identify which projects within a group were using the most CI/CD minutes.
Now you can see the SaaS runner usage for the group by project, the same as you can in a personal namespace. It is now easier to find the projects that are using the most CI/CD minutes and, if necessary, make their pipelines more efficient.
The first step for using the agent for Kubernetes in self-managed instances is to enable the agent server, a backend service for the agent for Kubernetes. In GitLab 14.8, we enabled the agent server for Omnibus based installations.
The feature has matured in the past few months, so we are now making the agent server enabled by default in the GitLab Helm chart as well to simplify setup for GitLab administrators. Besides being enabled by default, the agent server accepts various configuration options to customize it according to your needs.
Previously, you were only able to create lightweight tags when using the GraphQL API to create a release. With this update, you can now add an optional tagMessage parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.
Previously, to enable deploy keys for a group of projects, administrator access was required to retrieve the id of the deploy key. This release adds a new API endpoint (GET /users/:id_or_username/project_deploy_keys) to retrieve all the keys accessible by a given user, so you can complete this task without waiting for an administrator. In a future iteration, the API will also include public deploy keys.
Many users require a proxy to connect Kubernetes clusters to GitLab. Previously, the default installation method for the GitLab agent for Kubernetes did not support proxied connections. Now, you can use the HTTP_PROXY environment variable in the agentk Helm package to support proxied connections.
Dependency Scanning for Java (gemnasium-maven) is now available on a FIPS-enabled Red Hat UBI image. When FIPS mode is enabled, this image uses the OpenJDK packages for RedHat UBI 8 instead of the non-FIPS-compliant asdf-java package that is used by default. When FIPS mode is enabled, only Java versions 7, 11, and 17 are supported.
To begin scanning using the FIPS-compliant Dependency Scanning image, simply include the Dependency Scanning template in your CI/CD file and set the DS_IMAGE_SUFFIX variable to "-fips".
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.1 release milestone. These updates bring additional coverage, bug fixes, and improvements.
Kics analyzer updated to version 1.5.0. See CHANGELOG for details.
Add 82 new queries (rules) for Ansible, CloudFormation, Docker Compose, Kubernetes, and Terraform
Fix/update existing queries
Fix bugs in scanning and analysis
Improve performance
Secret Detection analyzer updated for better offline support and easier debugging. See CHANGELOG for details.
Improve logging
Use checked-out copy of the repository if git fetch fails
Fall back to scanning the latest commit if automatic diff detection fails
Security Code Scan analyzer updated to improve logging. See CHANGELOG for details.
Semgrep analyzer updated to use the latest version of GitLab-managed rulesets. See CHANGELOG for details.
Remove incorrect mapping to Gosec rule ID G104
Add rule G402 to detect use of TLS versions before 1.2
SpotBugs analyzer updated to SpotBugs version 4.7.0 and find-sec-bugs version 1.12.0. See CHANGELOG for details.
Update gradle and grails to support Java 17
Set Java 17 as the system-wide default version
Use ‘assemble’ task for Gradle projects, instead of ‘build’, to support custom GRADLE_CLI_OPTS (see issue #299872)
Add additional detection rules
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
Geo links directly to the replication views on the secondary site for each data type from the primary site’s admin dashboard. It is now possible to drill down to the list of individual objects for each data type on a secondary using the clickable links on the primary site’s admin dashboard.
This will help troubleshoot replication and verification issues at secondary sites, allowing system administrators to trigger resync and re-verify any objects failing to sync. It also improves overall observability of the replication and verification process by showing details of progress with information such as next sync attempt, last successful sync, and verification times for each object.
With GitLab 15.1, Geo supports replication of OCI container image format. OCI container images have been growing in popularity, and you are now able to replicate those images across Geo sites, similar to Docker manifest V1 and V2 images.
GitLab 15.1 includes Mattermost 6.7, whose newest release includes Playbooks task due dates and more! This version also includes security updates and upgrade from earlier versions is recommended.
Debian 9 (stretch) will reach end of life for long term support in June 2022. Therefore, we will stop building packages for Debian 9 (stretch) in GitLab 15.1.
Previously, GitLab.com group maintainers had to ensure they created group links for all users that would sign in using SAML. Otherwise,
users that aren’t in any linked groups could authenticate successfully but would immediately have their access and SAML identity removed.
Now, instead of being removed, those GitLab.com users are automatically assigned the default role. This alleviates the burden from the group
maintainer to have to make sure there is a group link for every user.
When you attempt to add a new SSH key to your GitLab account, the key is checked against a list of SSH keys that are known to be compromised. Users can’t add keys from this
list to any GitLab account. This helps to secure your GitLab instance.
To improve security, you can now block Git access protocols that you don’t use at the group level. This is similar to the GitLab administrator setting, but can now be set per group. By default, both HTTP(S) and SSH are enabled. In your group’s Settings > General > Permissions, scroll to Enable git access protocols and remove any protocols you don’t use.
Python notebooks are key to data scientists’ and machine learning engineers’ workflows. These files commonly display charts and graphs via static images to help visualize the notebook.
With this release, we now render these images in the merge request and commit view enabling a better user experience when reviewing code changes including Python notebooks with images.
Previously, to retry a downstream pipeline, you had to navigate to the pipeline and select retry. This worked, but was a challenging experience when there were multiple downstream pipelines. You had to go into every individual pipeline you wanted to retry and find the retry option, which was cumbersome.
In this release, we’ve improved the user experience by adding an option to retry downstream pipelines directly from the pipeline graph, without the need to go into each pipeline’s details page.
As the number of installed runners in your organization increases to hundreds or thousands, it becomes more challenging to determine which runners are outdated. Failing to update the version of GitLab Runner that your runners are using doesn’t just mean you aren’t using the latest features–it could also mean that you aren’t taking advantage of security fixes.
In the Admin Area, you can now identify at a glance which runners in your environment are outdated. Badges indicate whether an upgrade is recommended (for patches) and or an upgrade is available (for a minor or major upgrade). This feature makes it easier to maintain your runner fleet and mitigate the risks of using outdated versions.
Previously, the Release links API only accepted a personal access token or a project access token for authentication. With this update, a CI_JOB_TOKEN is now accepted for authentication to use with the API to manipulate GitLab Release links.
Thank you Timo Furrer for your awesome contribution!
Previously, you were only able to create lightweight tags when using the Releases API to create a release. With this update, you can now add an optional tag_message parameter to create an annotated tag when creating a release. This enables you to include relevant information along with the new tag, so downstream users and applications can have additional context.
In 15.1, we added a force option to the stop environment API call. This allows you to delete an active environment without running the specified on_stop jobs in cases where running these defined actions is not desired.
If you use the GitLab agent for Kubernetes with GitLab CI/CD, previously you couldn’t use kubectl exec, attach, cp, or port-forward calls. GitLab now supports these calls on top of the SPDY protocol. If your load balancer or reverse proxy supports SPDY, you can now use kubectl exec, attach, cp, or port-forward in your CI jobs. Both the Helm Chart and Linux (Omnibus) installations of GitLab use NGINX and are configured to support SPDY out of the box.
GitLab’s Dependency Scanner analyzes vulnerabilities in application libraries that are used in a project, regardless of whether those libraries are regular dependencies or development dependencies. Some users would like to focus only on regular dependencies, ignoring any vulnerabilities found in the development dependencies.
Excluding these development dependencies from scanning is now possible for NPM projects by setting the DS_INCLUDE_DEV_DEPENDENCIES variable to "false". Open issues to extend this support to future package managers can be tracked in this epic.
In GitLab 14.6, Geo allowed secondary sites to transparently proxy write requests to the primary site while accelerating most read requests. Until now, this feature required configuring a unified URL.
In GitLab 15.1, Geo’s proxying feature for the web UI works by default with secondary site-specific URLs. Customers who prefer maintaining different URLs for sites can now take advantage of a complete web UI experience.
After extensive testing and fixing a few outstanding issues, native Geo support for object storage replication is now generally available. Geo now natively supports replicating data in object storage such as LFS objects, job artifacts, and uploads. Previously, Geo could be configured to work with object storage, however the replication of the content was always left to the object storage provider. This imposed limitations when users relied on local storage appliances that do not support any replication logic.
You can use Geo to replicate your data across different object storage providers in different regions (for example Amazon in Europe and Microsoft in the United States), as well as use local storage (for example through MinIO) and use Geo to replicate data to secondary sites.
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 15.1.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback