GitLab 14.10 released with individual compliance violation reporting and a UI for streaming audit events
GitLab 14.10 released with individual compliance violation reporting, a UI for streaming audit events, GitLab Runner Operator for Kubernetes, and much more!
Jeremy added a user interface for
streaming audit events to GitLab
that provides an easy way for users, including non-technical users, to get
started with streaming audit events, rather than needing to use the API.
Thanks to this contribution, users can now easily add and remove streaming audit
event destinations as well as see the list of existing streaming audit event
destinations.
The compliance report now reports every individual merge request violation for the projects within a group. This is a huge improvement over the previous version, which only showed the latest MR that had one or more violations. The new version allows you to see history and patterns of violations over time.
These violations are individually listed so you can see what caused a violation, who was involved, and when it happened. You can
select a violation to show even more information about the merge request that caused it. For more information, see the
list of violation types.
We are happy to have also added several quality of life features, including both filtering and sorting, to help you find what you are looking for quickly.
In GitLab 13.10, we released the GitLab Runner Operator for the Red Hat OpenShift container platform for Kubernetes. That release provided OpenShift users with the automation and management capabilities of the Operator Framework and simplified the ongoing management of runners in an OpenShift Kubernetes cluster. Available starting in 14.10 is a GitLab Runner Operator v1.7.0 that you can use in non-OpenShift Kubernetes clusters. This GitLab Runner Operator is available on OperatorHub.io.
Incident Management is set up to trigger escalation policies for new alerts. In this scenario, the on-call responder who is paged can end the paging by acknowledging the alert. If the responder changes the status back to triggered, we restart the escalation policy and begin paging again. When a user creates an incident manually, there is no associated alert and therefore no way to page on-call responders.
This release enables paging on manually created incidents. Responders now have the ability to acknowledge the page on incidents, or restart paging by resetting the status to triggered, just as you can for alerts.
In this release, we have added the fourth DORA metric API, change failure rate. GitLab measures the change failure rate as the number of incidents divided by the number of deployments to a production environment in the given time period.
The DORA metrics enable executives who are investing in DevOps transformation to understand ROI on processes they are implementing and tools they have purchased. Changes in these metrics easily become KPIs for those teams.
When importing from GitHub, this milestone changes the default destination for imported projects to the contextual namespace of the GitLab group from which you started the import. Previously, GitHub projects imported to your personal namespace. This usability enhancement helps users import projects in a more intuitive way and doesn’t place imported projects in confusing locations.
We are pleased to offer our self-managed customers an opportunity to use our preliminary
incremental backup offering. After you take at least one full backup, you can run subsequent
incremental backups that only pack repository changes since the last backup into the backup
bundle. This dramatically reduces backup time.
While this is available now, we want to clarify that each incremental backup overwrites
the last incremental backup, and remind you that this is our
MVC.
Please feel free to try out this exciting new feature and don’t hesitate to
provide feedback!
Previously, if you wanted to create a pipeline schedule for tags, you had to use the API. The simpler method of using the pipeline schedules UI could only be used for branches.
Now, when you use the pipeline schedules UI, you can choose from either branches or tags as needed, and no longer need to use the API! Thanks @KevSlashNull for this contribution!
We’re also releasing GitLab Runner 14.10 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.
The GitLab agent for Kubernetes has a component
that needs to be installed into the user cluster. Previously, we provided a
Docker-based one-liner installer and a Kpt-based advanced installation
method. As Helm is an often requested method for installing Kubernetes applications,
we are replacing the Docker-based installer with a Helm package.
Thanks to Eamonn McCudden’s (@emctl) contribution, the GitLab agent for Kubernetes can
be installed into a user cluster from a Helm package. This facilitates the installation
of the agent into the cluster as well as automating with Terraform.
We have replaced the Docker-based
installation method with the new Helm package as we expect users to have
helm installed on the local machines.
GitLab 13.2 introduced the metrics tab in GitLab alerts. However, with the deprecation of GitLab Managed Apps and alerts on the Metrics page, metrics no longer automatically populate on new alerts and are difficult to support on old ones. This release completes the deprecation of the old metrics functionality, and introduces the ability to add a screenshot to alerts, similar to how screenshots can be added to incidents. Having a screenshot of the metric that triggered the alert helps responders triage alerts more efficiently.
The Semgrep-based analyzer runs significantly faster—up to 7 times faster in our testing than the existing analyzer that’s based on SpotBugs.
It also doesn’t need to compile your code before scanning, so it’s much simpler to use than SpotBugs.
The Static Analysis and Vulnerability Research teams worked together to translate rules to the Semgrep format, preserving most existing rules.
We also updated, refined, and tested the rules as we converted them.
If you use the GitLab-managed SAST template (SAST.gitlab-ci.yml), both Semgrep and SpotBugs now run whenever Java code is found.
In GitLab Ultimate, the Security Dashboard combines findings from the two analyzers, so you won’t see duplicate vulnerability reports.
In a future release, as we announced, we’ll change the GitLab-managed SAST template (SAST.gitlab-ci.yml) to only run the Semgrep-based analyzer for Java code.
The SpotBugs-based analyzer will still scan other JVM languages like Groovy, Kotlin, and Scala.
If you have any questions, feedback, or issues with the new Semgrep-based Java scanning, please file an issue, we’ll be glad to help.
Several initiatives to improve the user experience for managing security policies were completed in GitLab 14.10:
A new workflow for selecting the policy type when creating a new policy.
Validation of the YAML syntax when saving changes, including specific details when errors are encountered.
A more consistent experience for the policy details drawer across policy types, including a text description of the policy.
Previously, only project Owners were able to see information about the policy management project. Other roles can now see a button on the Policy page indicating the policy management project’s location.
Various other improvements to performance, design, and handling of error states.
To get started with GitLab Security Policies, navigate to a project > Security & Compliance > Policies.
The new Project import history page lists all project imports, regardless of where they were imported from. This view consolidates information that was previously scattered on the import pages of each individual importer.
Having all the details about previous imports in one view gives you a single place to find and review the status of all previous imports. This includes details on imports that failed, so that you can verify that you successfully imported all the intended projects.
To contain resource usage in support of instance stability, GitLab administrators of instances with high CI/CD usage might want to add limits for specific CI/CD events. This could be to set the maximum number of jobs in a single pipeline, the maximum number of concurrent jobs in active pipelines, or the maximum number of scheduled pipelines per project.
GitLab instance administrators can now set these limits (and others) directly in the instance’s Admin Area panel.
Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace. To view the new UI, on the left sidebar, select CI/CD. This view includes the number of online, offline, and stale runners associated with the group and subgroups.
Previously, it was possible to pass some CI/CD variables to a downstream pipeline through a trigger job, but variables added in manual pipeline runs or by using the API could not be forwarded.
In this release we’ve added a new trigger:forward keyword to control what things you forward to downstream parent-child pipelines or multi-project pipelines, which provides a flexible way to handle variable inheritance in downstream pipelines.
Previously, deployment approvals supported a simple model where the ability to execute a deployment and approve a deployment were both controlled with a single list of users. With this update, you have more flexibility and granularity with these rules and can specify multiple levels of control using the API. One type of model that can now be supported is where there is separation of duties between deployment executors and approvers in your organization. Another supported model is where approval is needed separately from multiple levels, such as a QA tester group and a security group.
Geo automatically verifies the data integrity of replicated CI job artifacts. This ensures that artifacts are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.
GitLab 14.10 includes Mattermost 6.5, whose newest release includes custom groups, cross-team channel navigation, playbook import, export, and duplication, improved board sharing, Bitbucket integration, workplace optimization, improved onboarding experiences, Persian language support, plus more! This version also includes security updates and upgrade from earlier versions is recommended.
Vulnerability Management in GitLab processes and aggregates security findings from our many Secure scanners, and can seamlessly incorporate results from integrated 3rd-party scanners. While this provides valuable security information in a unified experience, it limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools.
We’re introducing the ability to manually create vulnerability records to greatly expand the use cases Vulnerability Management can handle. Leveraging our recently-released ability to create vulnerability records through the API, making a new vulnerability record is as simple as entering a few required pieces of information. With manually created vulnerability records you can provide additional details supported by vulnerability records, including the severity, identifiers and suggested solution. You can view manually created records in the Group, Project, and Security Center Vulnerability Reports. And you can move records through your triage and remediation workflows like you would any scanner-detected vulnerability.
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 14.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.
Gosec analyzer updated to version 2.11.0. See CHANGELOG for details.
Add rule for potential directory traversal through http.Dir("/")
Detect minimum TLS version even when declared in a different file within the package
Kics analyzer updated to version 1.5.5. See CHANGELOG for details.
Add new rules
Fix existing rules
Delete redundant rules
PMD analyzer updated to version 6.44.0. See CHANGELOG for details.
Add Java 18 support
Fix rules
Secrets analyzer updated to version 8.6.1. See CHANGELOG for details.
Add entropy values to all findings
Skip content checks for rules that are only based on file paths
Add ability to skip a finding if gitleaks:allow is included in the same line as a detected secret
Semgrep analyzer updated to version 0.86.5. See CHANGELOG for details.
Support Go 1.18 generics
Additional bug fixes and performance improvements
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.
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 14.10.
NFS for Git repository storage support extended to November 22, 2022
We announced during the release of GitLab 14.0 our intention to stop supporting NFS for Git repository storage in GitLab 15.0. After consulting with both customers and internal teams, we have decided to extend customer support until November 22, 2022.
The upgrade to GitLab 14.10 executes a concurrent index drop of unneeded entries from the ci_job_artifacts database table. This could potentially run for multiple minutes, especially if the table has a lot of traffic and the migration is unable to acquire a lock. It is advised to let this process finish as restarting may result in data loss.
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