Manage project integrations from a group with the REST API
Previously, you could manage project integrations from a group in the GitLab UI only. With this release, it’s possible to manage these integrations with the REST API too.
Thanks to Van for their initial community contribution, which was subsequently picked up and completed by GitLab.
Control access to GitLab Pages for groups
You can now restrict GitLab Pages access at the group level. Group owners can enable a single setting to make all Pages sites in a group and its subgroups visible only to project members. This centralized control simplifies security management without modifying individual project settings.
Work items GraphQL API - additional query filters
The Work Items GraphQL API now includes additional query filters that let you filter by:
- Created, updated, closed, and due dates
- Health status
- Weight
These new filters give you more control when querying and organizing work items through the API.
Discover and migrate certificate-based Kubernetes clusters
The certificate-based Kubernetes integration will be turned off on GitLab.com for all users between May 6, 2024 9:00 AM UTC and May 8, 2025 22:00 PM UTC, and will be removed from GitLab Self-Managed instances in GitLab 19.0 (expected in May 2026).
To help users migrate, we added a new cluster API endpoint that group Owners can query to discover any certificate-based clusters registered to a group, subgroup, or project. We also updated the migration documentation to provide instructions for different types of use cases.
We encourage all GitLab.com users to check if they are affected, and to plan their migrations as soon as possible.
GitLab-managed Kubernetes resources
Deploy your applications to Kubernetes with more control and automation using GitLab-managed Kubernetes resources. Previously, you had to manually configure Kubernetes resources for each environment. Now, you can use GitLab-managed Kubernetes resources to automatically provision and manage these resources.
With GitLab-managed Kubernetes resources, you can:
- Automatically create namespaces and service accounts for new environments
- Manage access permissions through role bindings
- Configure other required Kubernetes resources
When your developers deploy applications, GitLab automatically creates the necessary Kubernetes resources based on the provided resource templates, streamlining your deployment process and maintaining consistency across environments.
Enable Dependency Scanning using SBOM for Cargo, Conda, Cocoapods and Swift projects
In GitLab 17.9 the Composition Analysis team starts the transition to Dependency Scanning using SBOM with the new Dependency Scanning analyzer. This analyzer will be a replacement for Gemnasium, which will reach end of support in 18.0, remaining available for use through GitLab 19.0.
The Dependency Scanning using SBOM approach will better support customers through expansion of language support, a tighter integration and experience within the GitLab platform, and a shift towards industry standard report types (SBOM-based scanning and reporting). As of GitLab 17.9, the new Dependency Scanning analyzer will be enabled by default in the latest Dependency Scanning CI/CD template (Dependency-Scanning.latest.gitlab-ci.yml) for the following project and file types:
* C/C++/Fortran/Go/Python/R projects using conda with a conda-lock.yml file.
* Objective-C projects using Cocoapods with a podfile.lock file.
* Rust projects using Cargo with a cargo.lock file.
* Swift projects using Swift with a package.resolved file.
With this change we are introducing a new CI/CD variable: DS_ENFORCE_NEW_ANALYZER which is set to false by default.
This approach ensures that all existing customers of the latest template continue to use the Gemnasium analyzer by default and it enables automatically the new Dependency Scanning analyzer for the file types listed above.
Existing customers who wish to migrate to the new Dependency Scanning analyzer can set DS_ENFORCE_NEW_ANALYZER to true (at the project, group, or instance level). You can read more about this change in the deprecation announcement and the associated migration guide.
Customers who want to entirely prevent the use of the new Dependency Scanning analyzer must set the CI/CD variable DS_EXCLUDED_ANALYZERS to dependency-scanning.
Block deletion of active security policy projects
To ensure secure management of security policies and prevent disruption to enabled and enforced policies, we’ve added protection to prevent deletion of security policy projects that are in active use.
If a security policy project is linked to any groups or projects, the links must be removed before the security policy project can be deleted.
Enforce custom stages in pipeline execution policies
We’re excited to introduce a new capability for pipeline execution policies that allows you to enforce custom stages into your CI/CD pipelines in Inject mode. This feature provides greater flexibility and control over your pipeline structure while maintaining security and compliance requirements, supplying you with:
- Enhanced pipeline customization: Define and inject custom stages at specific points in your pipeline, allowing for more granular control over job execution order.
- Improved security and compliance: Ensure that security scans and compliance checks run at the most appropriate times in your pipeline, such as after build but before deployment.
- Flexible policy management: Maintain centralized policy control while allowing development teams to customize their pipelines within defined guardrails.
- Seamless integration: Custom stages work alongside existing project stages and other policy types, providing a non-disruptive way to enhance your CI/CD workflows.
How does it work?
The new and improved inject_policy strategy for pipeline execution policies allows you to define custom stages in your policy configuration. These stages are then intelligently merged with your project’s existing stages using a Directed Acyclic Graph (DAG) algorithm, ensuring proper ordering and preventing conflicts.
For example, you can now easily inject a custom security scanning stage between your build and deploy stages.
The inject_policy stage replaces inject_ci which will be deprecated, allowing you to opt into the inject_policy mode to gain the benefits. The inject_policy mode will become the default when configuring policies with Inject in the policy editor.
Support custom roles in merge request approval policies
We’ve made merge request approval policies more flexible by adding the ability to assign custom roles as approvers.
You can now tailor approval requirements to match your organization’s unique team structures and responsibilities, ensuring the right roles are engaged in the review process based on the policy. For example, require approval from AppSec Engineering roles for security reviews and Compliance roles for license approvals.
Apply a compliance framework by using a project’s compliance center
In GitLab 17.2, we released the ability for group owners to apply and remove compliance frameworks for all projects
in a group by using the group’s compliance center.
We have expanded this to now allow group owners to also apply and remove compliance frameworks at the project level.
This will make it even easier for group owners to apply and monitor compliance frameworks at the project level.
The ability to apply and remove compliance frameworks at the project level is only available for group owners and
not project owners.
Email notifications for service accounts
You can now set a custom email address to receive email notifications for service accounts. When a custom email address is specified when creating a service account, GitLab sends notifications to that address. Each service account must use a unique email address. This can help you monitor processes and events more effectively.
Thank you Gilles Dehaudt, Étienne Girondel, Kevin Caborderie, Geoffrey McQuat, Raphaël Bihore from the SNCF Connect & Tech team for your contribution!
OAuth application authorization audit event
Previously, when a user authorized a OAuth application, no audit event was generated. However, this event is important for security teams to
monitor the OAuth applications authorized by users on a specific GitLab instances.
With this release, GitLab now provides a User authorized an OAuth application audit event to track when users successfully authorize OAuth
applications. This new audit event further improves your ability to audit your GitLab instance.
Search and filter the Credentials Inventory
You can now use search and filter capabilities in the Credentials Inventory. This makes it easier to identify tokens and keys which fall within certain user-defined parameters, including tokens that expire within a certain window. Previously, the entries in the Credentials Inventory were presented as a static list.
Use API to disable 2FA for individual enterprise users
You can now use the API to clear all two-factor authentication (2FA) registrations for an individual enterprise user. Previously, this was only possible in the UI. Using the API allows for automated and bulk operations, saving time when 2FA resets need to be done at scale.
View inactive project and group access tokens
You can now view inactive group and project access tokens in the UI. Previously, GitLab instantly deleted project and group access tokens after they expired or were revoked. This lack of a record of inactive tokens made auditing and security reviews more difficult. GitLab now retains inactive group and project access token records for 30 days, which helps teams track token usage and expiration for compliance and monitoring purposes.
Group sharing visibility enhancement
We’re excited to announce expanded visibility for group sharing across GitLab. Previously, while you could see shared projects on a group’s overview page, you couldn’t see which groups your group had been invited to join. Now you can view both Shared projects and Shared groups tabs on the group overview page, giving you a complete view of how your groups are connected and shared throughout your organization. This makes it easier to audit and manage group access across your organization.
We welcome feedback about this change in epic 16777.
Change work item type to another
You can now easily change the type of your work items, giving you the flexibility to manage your projects more efficiently.
Speed up adding new child items by keeping the form open
We’ve streamlined the process of creating multiple child items by keeping the form open after each submission, making it easier to add multiple entries without extra clicks. This update saves you time and ensures a smoother workflow when managing your tasks.
Workspace extensions now support proposed APIs
Workspace extensions now support enabling proposed APIs, improving compatibility and reliability in production environments. This update allows extensions that depend on proposed APIs to run without errors, including critical development tools like the Python Debugger. The change expands API access while maintaining stability.
Get started with the GitLab integration with Kubernetes
In this release, we added new Kubernetes Getting started guides that show you how to use GitLab to deploy applications to Kubernetes directly and with FluxCD. These easy-to-follow tutorials don’t require in-depth Kubernetes knowledge to complete, so both novice and experienced users can learn how to integrate GitLab and Kubernetes.
To supplement the Kubernetes Getting started guides, we also included a series of recommendations for integrating GitLab into Kubernetes environments.
Implement OCI-based GitOps with the FluxCD CI/CD component
Have you ever wondered how to implement GitOps best practices with GitLab? The new FluxCD component makes it easy. Use the FluxCD component to package Kubernetes manifests into OCI images and store the images in OCI-compatible container registries. You can optionally sign the images and trigger an immediate FluxCD reconciliation.
License scanning support for Swift packages
In GitLab 17.9, we added support for license scanning on Swift packages. This will allow users who use Swift within their projects to better understand the licensing of their Swift packages.
This data is available to composition analysis users through the Dependency List, SBOM reports, and GraphQL API.
Dependency list filter by component in projects
On the Dependencies list in a project, you can now filter by the package name using the Component filter.
Previously, you could not search for packages in the Dependencies list for a project level. Now, setting the Component filter will find a packages that contain the specified string.
Filter by identifier in the Vulnerability Report
In the Vulnerability Report, you can now filter the results by vulnerability identifier so you can find specific vulnerabilities (like CVEs or CWEs) that are in your project or group.
You can use the identifier in conjunction with other filters like the severity, status, or tool filters. The vulnerability identifier filter is limited to reports with 20,000 vulnerabilities or less.
Support merge request variables in pipeline execution policies
Pipeline execution policies now support additional merge request variables, allowing you to create more sophisticated policies that take into account information related to the merge request. This provides more targeted and efficient control over CI/CD enforcement. The following variables are now supported:
CI_MERGE_REQUEST_SOURCE_BRANCH_SHACI_MERGE_REQUEST_TARGET_BRANCH_SHACI_MERGE_REQUEST_DIFF_BASE_SHA
With this enhancement, you can:
- Implement advanced security scans that compare changes between source and target branches, ensuring thorough code review and vulnerability detection.
- Create dynamic pipeline configurations that adapt based on the specifics of each merge request, streamlining your development process.
Custom expiration date for rotated service account tokens
When rotating an access token for a service account, you can now use the expires_at attribute to set a custom expiration date. Previously, tokens automatically expired seven days after rotation. This allows for more granular management of token lifetimes, enhancing your ability to maintain secure access controls.
New permissions for custom roles
You can create custom roles with the Read compliance dashboard permission. Custom roles allow you to grant only the specific permissions users need to complete their tasks. This helps you define roles that are tailored to the needs of your group, and can reduce the number of users who need the Owner or Maintainer role.
Rotate access tokens with self_rotate scope
You can now use the self_rotate scope to rotate access tokens. This scope is available for personal, project, or group access tokens. Previously, this required two requests: One to obtain a new token, then another to perform the token rotation.
Thank you Stéphane Talbot and Anthony Juckel for your contribution!
Support for additional group memberships with multiple OIDC providers
You can now configure additional group memberships when using multiple OIDC providers. Previously, if you configured multiple OIDC providers, you were limited to a single group membership.
View access token IP addresses
Previously, when viewing your personal access tokens, the only usage information you could see was how many minutes ago the token was used. Now, you can also see up to the last seven IP addresses that the tokens were used from. This combined information can help you track where your token is being used.
Thank you Jayce Martin, Avinash Koganti, Austin Dixon, and Rohit Kala for your contribution!
Duo Chat is now resizable
In the GitLab UI, you can now resize the Duo Chat drawer. This makes it easier to view code outputs, or keep Chat open whilst working with GitLab in the background.
Restrict users from making their profile private
Users can choose to make their user profile public or private.
Administrators can now control whether users have the option to make profiles private across their GitLab instance. In the Admin Area, “Allow users to make their profiles private” controls this setting. This setting is enabled by default, allowing users to choose private profiles.
