Elevate your coding: Duo Chat now in Visual Studio for Windows
Empower your development workflow with Duo Chat, now seamlessly integrated into Visual Studio for Windows. Duo Chat enhances your coding experience by providing AI-powered capabilities to explain, refine, debug code, or write tests all in real-time. This integration allows you to leverage Duo Chat’s advanced AI tools directly within your familiar development environment, improving productivity and enabling faster, more efficient problem-solving.
Enhance API performance when working with container registry tags
We’re excited to announce a significant improvement to our Container Registry API for self-managed GitLab instances. With the release of GitLab 17.5, we’ve implemented keyset pagination for the :id/registry/repositories/:repository_id/tags endpoint, bringing it in line with the functionality already available on GitLab.com. This enhancement is part of our ongoing efforts to improve API performance and provide a consistent experience across all GitLab deployments.
Keyset pagination offers a more efficient method for handling large datasets, resulting in improved performance and a better user experience. This update is particularly useful when managing large container registries, as it allows for smoother navigation through repository tags. In order to use this feature, self-managed instances must upgrade to the next-generation container registry.
Configure agent and GitOps environment settings with the REST API
You can check the status of your pods and Flux reconciliation from the GitLab environments UI.
However, this approach is hard to scale because the required settings are exposed only through GraphQL or the UI.
Now, GitLab ships with REST API support for configuring an agent for Kubernetes, as well as setting the namespace and Flux resource per environment.
To further improve support for dynamic environments, issue 467912 proposes adding support for configuring these settings in CI/CD pipelines.
Kubernetes integration support for firewalled GitLab installations
Until now, the agent for Kubernetes could be used only if the Kubernetes cluster could connect to the GitLab instance.
This issue meant that some customers couldn’t use the agent if, for example, they ran GitLab on a private network or behind a firewall.
From GitLab 17.5, you can initiate the cluster-GitLab connection from GitLab, assuming that a properly configured agentk instance is already waiting for a connection initialization.
Once the initial connection is established, all the features of the agent are available. Initializing from a cluster is not changed with this development.
Suspend or resume GitOps reconciliation from the GitLab UI
As a Flux user, have you ever needed to quickly stop an automatic reconciliation or drift remediation? Have you wanted to trigger a HelmRelease to synchronize manually removed resources? These actions are best achieved with the Flux suspend and resume functions. Until now, your best option was to use the Flux CLI, which required a context switch and several commands to ensure the right resource was affected. In GitLab 17.5, you can suspend or resume a reconciliation from the built-in dashboard for Kubernetes.
GitLab chart improvements
GitLab 17.5 includes an update to our version of the NGINX Ingress Controller. The nginx-controller container image is now version 1.11.2. Please
note this includes new RBAC requirements because the new controller now uses endpointslices and requires an RBAC rule to access them.
Omnibus improvements
GitLab 17.5 includes support for upgrading PostgreSQL from version 14.x to 16.x for single node installations. Automatic upgrades are not enabled and
so PostgreSQL upgrades must be triggered manually.
Add groups to security policy scope
You can now target groups/subgroups in security policy scopes. This extends the existing options allowing you to target all projects in a group/subgroup, projects based on a defined project list, and projects matching a list of compliance framework labels.
This gives you further flexibility in enabling policies across your groups, while also being able to apply exceptions to scope projects out of enforcement where necessary.
This improvement also precedes a number of enhancements that will simplify the process of linking security policy projects and granularly scoping enforcement of policies.
Improved user management summary
Administrators now have an enhanced, summarized view of the following critical pieces of information about the users on their instance:
- Pending approval.
- Without two-factor authentication.
- Administrators.
This increases user management efficiency, because administrators can quickly see how many users are in these states from the summary view, and filter on them.
Ruby support and rule updates for Advanced SAST
We’ve added Ruby support to GitLab Advanced SAST.
To use this new cross-file, cross-function scanning support, enable Advanced SAST.
If you’ve already enabled Advanced SAST, Ruby support is automatically activated.
In the last month, we’ve also released updates to improve the detection rules for the other languages Advanced SAST supports by:
- Detecting additional Java path traversal, Java command injection, and JavaScript path traversal vulnerabilities.
- Updating CWE mappings to more specifically and consistently identify vulnerability types.
- Increasing the severity of path traversal vulnerabilities.
To see which types of vulnerabilities Advanced SAST detects in each language, see the new Advanced SAST coverage page.
To learn more about Advanced SAST, see last month’s announcement blog.
View token associations using API
You can now view which groups, subgroups, and projects a token is associated with. This makes it easier to determine the impact of token expirations or revocations, and to understand where a token is able to be used.
GitLab Runner 17.5
We’re also releasing GitLab Runner 17.5 today! GitLab Runner is the highly-scalable build 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.
What’s new:
Bug Fixes:
Safeguard your dependencies with protected packages
We’re thrilled to introduce support for protected npm packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.
From GitLab 17.5, you can protect npm packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.
Easy bootstrapping of GitLab Kubernetes integration
GitLab offers flexible, reliable, and secure GitOps support with the agent for Kubernetes and its Flux integration.
Still, bootstrapping Flux with GitLab and setting up the agent for Kubernetes used to require a lot of documentation reading and switching between the GitLab UI and the terminal.
The GitLab CLI now offers the glab cluster agent bootstrap command to simplify installing the agent on top of an existing Flux installation.
Now, you can configure Flux and the agent with just two simple commands.
Stream Kubernetes resource events
GitLab provides a real-time view of your pods, as well as pod log streaming, all through the dashboard for Kubernetes.
In GitLab 17.4, we offered a static listing of resource-specific event information from the UI.
This release further improves the dashboard for Kubernetes by letting you stream incoming events as they emerge in the cluster.
Access compliance center on projects
Previously, the compliance center was available only for top-level groups and subgroups.
With this release, we’ve added the compliance center to projects. At this level, compliance center provides
view-only capabilities for checks and violations that pertain to a particular project.
To add or edit a framework, you should access the compliance center on top-level groups instead.
Disable password authentication for enterprise users
Enterprise users can authenticate using a local account with username and password. Now, group Owners can disable password authentication for the group’s enterprise users. If password authentication is disabled, enterprise users can use either the group’s SAML identity provider to authenticate with GitLab web UI, or a personal access token to authenticate with GitLab API and Git using HTTP Basic Authentication.
Migration process for compliance pipelines to security policies
In GitLab 17.3, we announced the deprecation of compliance pipelines and its eventual removal by the 18.0 release.
Instead of compliance pipelines, you should use the pipeline execution policy type instead, which was released in GitLab 17.2.
To help you migrate your existing compliance pipelines over to the pipeline execution policy type, this release includes a
warning banner that:
- Notifies users about the deprecation of compliance pipelines.
- Provides a prompted and guided workflow to migrate existing compliance pipelines to the pipeline execution policy type.
Selective SAML single sign-on enforcement
Previously, when SAML SSO was enabled, groups could choose to enforce SSO, which required all members to use SSO
authentication to access the group. However, some groups want the security of SSO enforcement for employees or
group members, while still allowing outside collaborators or contractors to access their groups without SSO.
Now, groups with SAML SSO enabled have SSO automatically enforced for all members
who have a SAML identity. Group members without SAML identities are not required to
use SSO unless SSO enforcement is explicitly enabled.
A member has a SAML identity if one or both of the following are true:
- They signed in to GitLab using their GitLab group’s single sign-on URL.
- They were provisioned by SCIM.
To ensure smooth operation of the selective SSO enforcement feature, ensure your SAML configuration is
working properly before selecting the Enable SAML authentication for this group checkbox.
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