GitLab 11.9 released with secrets detection and multiple MR approval rules
GitLab 11.9 released with secrets detection, multiple MR approval rules, ChatOps in Core, and much more!
Quickly learn if secrets have been leaked
Inadvertently committing credentials to a shared repository can have serious consequences, yet it is a simple
mistake to make. Once an attacker gets your password or API key, they can take over your account, lock you out, and fraudulently spend money.
This can even lead to a domino effect where access to one account grants access to others. With the stakes so high,
it’s of paramount importance to learn as quickly as possible if secrets have been leaked.
With this release, we’re introducing secret detection as
part of our SAST functionality. Each commit is scanned by a CI/CD job to ensure it doesn’t contain secrets.
If the scan detects secrets, the developer is alerted in the merge request, allowing them to take action quickly
to invalidate the leaked credentials and generate new ones.
Enforce proper change management
As an organization grows and becomes more complex, it becomes difficult to keep alignment across different
parts of the organization. At the same time, the consequences of merging improper or insecure code also
increase when an application has more users and generates more revenue. For many organizations, ensuring
proper review process is followed before code is merged is a hard requirement because the risks of not doing so are so great.
With GitLab 11.9, we’re providing greater controls and more structure with Merge request approval rules.
Previously, you could specify either an individual or a group for required approval (where any single member of the group can provide approval). Now, multiple rules can be added to a merge request to require individual approvers specifically,
or even require a number of approvers from a particular group. Additionally, the Code Owners feature is an integrated part of approval rules, making it easy to track down who should approve.
This allows organizations to implement complex approval flows, all
while maintaining the simplicity of GitLab’s single application where issues, code, pipelines, and monitoring
data are visible and accessible to inform decisions and speed approval.
Approval Rules have temporarily been disabled on GitLab.com and are not enabled by default in GitLab 11.9 due to a
regression.
ChatOps is now open source
GitLab ChatOps is a powerful automation tool, allowing you to execute any CI/CD job and receive the status
of the job directly from chat apps like Slack and Mattermost. Originally released in GitLab 10.6, ChatOps
was part of the GitLab Ultimate tier. As part of our product strategy and commitment to open source,
we occasionally move features down in tier and never move them up.
With ChatOps, we felt this was functionality that everyone could benefit from and that the feature itself could benefit from community contributions.
In GitLab 11.9, we’ve open sourced ChatOps so it is available to use in GitLab
self-managed Core and GitLab.com Free, and is open for community contributions.
Marcel has continually helped us to make GitLab’s documentation better. He made
numerous contributions
that improved the quality and usability of our docs. Domo arigato Marcel, we sincerely appreciate it!
A recurring problem when developing applications is that developers may
unintentionally commit secrets and credentials to their remote repositories.
If other people have access to the source, or if the project is public, the
sensitive information is then exposed and can be leveraged by malicious users
to gain access to resources like deployment environments.
GitLab 11.9 includes a new check called Secret Detection. It scans the
content of the repository to find API keys and other information that should
not be there. GitLab displays results in the SAST report in the merge
request widget, pipelines reports, and the security dashboards.
If you already have SAST enabled for your app, you don’t need to take any
action to benefit from this new feature. It is also already included in
Auto DevOps default configuration.
Code review is an essential practice of every successful project, but
who should review the changes is not always clear. It is often
desirable to have a variety of reviewers from different teams like
Engineering, UX, and Product.
Approval Rules allow you to better communicate who should participate
in code reviews by specifying the eligible approvers and the minimum
number of approvals for each. Approval rules are shown in the merge
request widget so the next reviewer can quickly be assigned.
In GitLab 11.8, Approval Rules were disabled by default. From GitLab
11.9, they are available by default.
UPDATE: Approval Rules continue to be
disabled by default due to a
regression
In GitLab 11.3, we introduced
Code Owners
to indicate which team members are responsible for which code in your
project. Code owners are integrated into approval rules so that finding
the right people to review your change is always easy.
Initially introduced in GitLab Ultimate 10.6, ChatOps has now moved to GitLab Core.
GitLab ChatOps provides the ability to trigger GitLab CI jobs from Slack by using the
slash commands
feature.
We are open sourcing this feature in alignment with our buyer-driven tier designation
to encourage its use and contribution by the community.
Operations like adding, removing, or changing Feature Flags are now recorded
in the GitLab audit log, giving you visibility into what is changing and when. If you’re having
an incident and need to see what changed recently, or just need to look back as an auditor on
how your feature flags have been modified, this is now very easy to do.
Remediation should be a simple process to quickly fix vulnerabilities
in your code. It is important to make security patches easy, allowing developers
to focus on what they are supposed to do.
In GitLab 11.7, we provided a remediation patch file,
but users had to download it, apply it locally, and then push changes back to the remote repository.
GitLab 11.9 automates this flow. Now, remediation can be done without leaving
the GitLab web interface. You can create a merge request directly from the vulnerability details window
and this new branch will already contain the fix. You can then check if it solves the problem,
and merge it into your original branch if the pipeline is green.
The group security dashboard allows security engineers to focus on what’s
most important to work on, giving a clear and high-level view of all the
possible security vulnerabilities affecting their apps. That’s why it is
essential that it contains all the relevant information in a single
place, and allows users to drill down to start the remediation process.
With GitLab 11.9, Container Scanning results are added to the dashboard,
along with the already present SAST and Dependency Scanning findings.
You now have a complete view in a single place, no matter
the source of the problem.
GitLab security features are evolving very fast, and they always need to be up to date
to be effective and protect your code. We know that changing the
job definition is difficult if you have to manage multiple projects.
We also know that you don’t want to risk using the latest GitLab version if you don’t have
confidence it is totally compatible with your current GitLab instance.
That’s why with GitLab 11.7, we introduced a new way to include job definitions, using
templates.
Starting with GitLab 11.9, we ship built-in templates for all the security jobs, like
sast and dependency_scanning, that are compatible with the GitLab version
they come with.
You can now include them directly into your configuration, and have them updated with
your system every time you upgrade to a new version of GitLab, without any change to
any pipeline configuration.
This new way to define security jobs is official and deprecates
any other previous job definition or snippet of code. You should update the definition
to use the new template keyword as soon as possible. Support for any other syntax could be removed
in GitLab 12.0 or other future releases.
GitLab has threaded discussions. Up to now, the user writing the
initial comment has to decide at the outset if they want a discussion.
With this release, we’ve relaxed that constraint. You can now take
any comment in GitLab (in issues, merge requests, and epics) and reply
to it, thus starting a threaded discussion. This allows for much more organized
collaboration amongst your teams.
It isn’t always obvious who you should ask to approve your merge request.
GitLab now supports requiring merge request approvals based on which
files a merge request changes using Code Owners.
Code owners are assigned using a file named CODEOWNERS, a format similar to
gitattributes.
Support for automatically assigning Code Owners as merge request
approvers was added in
GitLab 11.5.
GitLab labels are incredibly versatile, with teams always finding new ways
to use them. Consequently, users often add many labels to a given issue,
merge request, or epic.
In GitLab 11.9, we are making consuming those labels a little bit easier.
In issues, merge requests, and epics, the labels showing up in the sidebar
are now ordered alphabetically. This is also the same in the list views
of these objects too.
We recently released Child Epics, which is the ability to have epics of epics (in addition
to child issues of epics).
With this release, you can now reorder the child
epics of an epic simply by dragging and dropping, exactly the same as with child
issues. This allows teams to use ordering to represent priority or to prescribe
an order of implementation of work.
Confidential issues are a useful tool for teams to have private discussions
on sensitive topics in an otherwise public project. In particular, they
are ideal for working on security vulnerabilities. Until now,
it was not particularly easy to manage or surface confidential issues.
In GitLab 11.9, you can now filter by confidential or non-confidential
issues in issue list views of GitLab. You can also do the same when retrieving
issues via the API.
When reviewing the changes in a merge request, the diff for each file
can now be expanded to show the entire file for more context and to leave
comments on unchanged lines.
Grafana is now bundled in our Omnibus package, making it easier than ever
to understand how your instance is performing.
To enable, set grafana['enable'] = true in gitlab.rb, and Grafana will
then be available at https://your.gitlab.instance/-/grafana. In the near future,
we will also be including a GitLab dashboard
out of the box.
In GitLab, you can easily move an issue to another project via the sidebar
or with a quick action. Behind the scenes, the existing issue is closed,
and a new issue is created in the target project, with everything copied
over, including system notes and sidebar attributes. This is a great feature.
While there is a system note indicating the move, users have found it confusing
when viewing the now-closed issue, since they may not understand that the issue is closed due
to being moved.
With this release, we now indicate right in the badge at the top of the issue page
in the closed issue that it has been moved, and also include
a link to the new issue inline, so that anyone arriving at the older issue
can quickly navigate to the new one.
Issue Boards are very powerful and teams are creating many boards per project
and per group. Recently, we added a search bar to quickly filter down to
boards you care about.
In GitLab 11.9, we’ve also introduced a Recent
section in the dropdown, so that you can quickly navigate to boards you’ve
recently interacted with.
Forking allows anyone to contribute to open source projects without
needing to give everyone write permissions, by
copying the entire repository into a new project. Storing full copies
of frequently forked Git repositories is inefficient. Using Git
alternates, forks now share common objects from the upstream project
in an object pool to reduce disk storage requirements.
Object pools for forks are only created for public projects when hashed
storage is enabled. Object pools can be enabled using the
object_pools feature flag.
Building on the include functionality of GitLab CI,
the serverless gitlab-ci.yml template has been greatly simplified, allowing new functionality to be introduced
in future releases without needing to introduce changes to this file.
Deploying JupyterHub via GitLab’s Kubernetes integration is a great way to serve and share
Jupyter notebooks with large groups. It is also beneficial to control access to notebooks
when sensitive or private data is shared.
With GitLab 11.9, login to JupyterHub instances deployed via Kubernetes integration is limited to members with
“Developer” project access (via either group or project).
Auto DevOps’ Auto Build stage creates a build of your application by making
use of the project’s Dockerfile or a Heroku buildpack.
With GitLab 11.9, the resulting Docker image built in the tag pipeline
will be named similarly to traditional image names using the commit tag
instead of the commit SHA.
With GitLab 11.9, we’ve upgraded the engine to the latest release (
0.83.0) to bring the
benefits of additional language and linting support to GitLab Code Quality.
Thank you GitLab Core Team member Takuya Noguchi for the contribution!
With GitLab 11.9, the Static Application Security Testing (SAST) is able to analyze
and detect vulnerabilities in TypeScript code, showing them in the merge request
widget, at the pipeline level, and in the security dashboard. You don’t need to change
your current sast job definition, and it is also automatically included in
Auto DevOps.
We’re also releasing GitLab Runner 11.9 today! GitLab Runner is the open source project
that is used to run your CI/CD jobs and send the results back to GitLab.
The following are some of the changes in GitLab Runner 11.9:
The following improvements have been made to Omnibus in GitLab 11.9:
GitLab 11.9 includes Mattermost 5.8, an open source Slack alternative whose newest release includes MFA for Team Edition, improved image performance, and much more. This version also includes security updates and upgrading is recommended.
A new flag has been added that allows the GitLab Registry to be compatible with versions of Docker prior to 1.10. To enable, set registry['compatibility_schema1_enabled'] = true in gitlab.rb.
The GitLab Registry now exports Prometheus metrics and is automatically monitored by the bundled Prometheus service.
An iOS “hello world” app
ready for you to start customizing in GitLab. Note that since iOS builds require a dedicated
macOS runner, you’ll need to provide your own build server if you want to use this with
GitLab CI/CD.
We recently released a feature to enable users to filter the activity feed
in an issue, merge request, or epic, allowing users to focus on only comments
or system notes. Since this setting is saved per person in the system,
sometimes a user may not realize they are looking at a filtered feed when
they view an issue a few days later and seem to be unable to comment.
In this release, we improved this interaction. Users can now quickly
switch back to a mode that allows them to comment without scrolling back
to the top of the feed. This applies to issues, merge requests, and epics.
Previously, we added a feature to allow a custom header and footer message
to appear on every page in GitLab. This was extremely well received and teams
are using it to communicate critical information such as system-wide messages
relating to their GitLab instance.
In this release, we’re happy to bring
this feature to Core so that even more users can use it. Additionally, we
are allowing users to optionally have the same custom messages appear in
all emails sent by GitLab, bringing the same consistency to another GitLab user touchpoint.
When adding an existing Kubernetes cluster, GitLab will now validate that the CA
certificate being entered is in a valid PEM format to reduce possible errors
when using the Kubernetes integration.
In GitLab 11.6, we added the ability to specify only:
merge_requests
for pipeline jobs to enable users to run certain jobs only when creating a
merge request.
Now, we’re expanding that functionality to include
conjunction logic with only:
changes
so that users can run specific jobs only on merge requests when only
particular files are changed.
We recently released Child Epics, which is the ability to have
epics of epics.
In GitLab 11.9, we’ve made it even easier to see
that relationship. You can now see not only your parent epic in a given
epic, but your entire epic tree, right in the sidebar. You can see whether
those epics are closed or not, and even navigate directly to them.
GitLab integrates with many external issue tracking systems, making it
easier for teams to take advantage of GitLab for other features, while still
maintaining their issue management tool of choice.
With this release, we now also integrate with YouTrack by JetBrains.
Protected Branches prevent unreviewed code from being pushed or merged.
However, when no one is allowed to push to a protected branch, no one
is able to create a new protected branch, like a release branch.
In GitLab 11.9, developers can now create a protected branch from an
already protected branch through GitLab or the API. Using Git to push
a new protected branch is still protected to prevent accidentally
creating new protected branches.
Code review is an essential practice of every successful project but,
as a reviewer, it can be hard to keep track of which merge requests you
have been asked to review.
In GitLab 11.9, the merge request list can now be filtered by the assigned
approver, so that you can find the merge requests you have been added
to as an approver.
When deploying a Kubernetes Ingress controller, some platforms may return
an IP address (for example, Google’s GKE) while others may return a DNS name (for example, AWS’ EKS).
Our Kubernetes integration now supports both types of endpoints for display
in the clusters section of the project.
The group security dashboard includes a vulnerability chart to have an overview
of the recent security status of your groups’ projects. This is very useful to
security directors to tune their processes and understand how the team is performing.
In GitLab 11.9, you can now select the time range of this vulnerability chart.
The default is the last 90 days, but you can set the time window to 60 or 30 days,
based on the level of details you want to reach.
This doesn’t affect data shown in the counters or in the list, but only data points plotted
on the chart.
While investigating a performance anomaly, it is often useful to be able to take a closer
look at select portions of a given metric.
With GitLab 11.9, users can now zoom in on particular time periods on the metrics dashboard,
scroll across the entire time window, as well as easily reset the view back to the original
time span. This makes it quick and easy to investigate these interesting events.
Maven projects are often organized to aggregate
multiple modules
in one single repository. Previously, GitLab was not able to scan those projects correctly,
and vulnerabilities were not reported to developers and security researchers.
GitLab 11.9 introduces improved Static Application Security Testing (SAST) support for
this specific project configuration that can now be tested for vulnerabilities out of
the box. Because of the flexibility of our analyzers, the configuration is automatically
detected and you don’t need to change anything to see results for your multi-module Maven
apps. As usual, the same improvements are also available as part of
Auto DevOps.
A new flag has been added that allows the GitLab Registry to be
compatible with versions of Docker prior to 1.10. To enable, set
registry.compatibility.schema1.enabled: true.
GitLab Geo will enforce Hashed Storage in GitLab 12.0
GitLab Geo requires Hashed
Storage
to mitigate race conditions on secondary nodes. This was noted in
gitlab-ce#40970.
In GitLab 11.5, we added this
requirement to the Geo documentation in gitlab-ee#8053.
With GitLab 11.6,
sudo gitlab-rake gitlab:geo:check checks that Hashed
Storage is enabled and all projects are migrated. See
gitlab-ee#8289. If
you are using Geo, please run this check and migrate as soon as possible.
In GitLab 11.8, a
permanently dismissable warning is displayed on the
Admin Area › Geo › Nodes page if the above checks are not resolved:
gitlab-ee!8433.
In GitLab 12.0, Geo will
enforce the Hashed Storage requirement. See
gitlab-ee#8690.
CentOS 6 support for GitLab Runner using the Docker executor
GitLab Runner is removing support for CentOS 6 when using the Docker
executor in GitLab 11.9. This is a result of an upgrade to the underlying
Docker library that no longer supports CentOS 6. Please see this
issue for
additional details.
Since Gitlab 11.9, GitLab Runner is using a new
method
for cloning/fetching the repository. Currently, GitLab
Runner will use the old method if the new one is not supported.
In GitLab 11.0 we changed how the metrics server is configured for GitLab
Runner. metrics_server will be removed in favor of listen_address
in GitLab 12.0. Please see this issue for
additional details. Please see this
issue for
additional details.
These paths will no longer be available in GitLab 12.0. As a user, you don’t have to change
anything apart from making sure the GitLab instance is running 11.9+
when upgrading to GitLab Runner 12.0.
Deprecate support of Linux distribution that reached EOL for GitLab Runner
Some Linux distributions in which you could install GitLab Runner have reached
End of Life support.
In GitLab 12.0, GitLab Runner will no longer distribute packages to those
Linux distributions. A full list of distributions which are no longer supported can be found in our
documentation.
Thanks Javier Jardón for your
contribution!
In GitLab 12.0, GitLab Runner will start using the new commands. This only
affects users who are overriding the helper
image.
Please see this
issue for
additional details.
Removing or modifying release notes for Git tags on non-protected branches has historically been
restricted to Maintainers and Owners.
Since Developers can add tags as well as modify and remove non-protected
branches, Developers should be able to remove Git tags as well.
In GitLab 11.10, we’re making this change
to our permissions model to improve workflow and help developers make better and more
effective use of tags.
If you’d like to continue to restrict this permission to Maintainers and Owners,
you can make use of protected tags.
With GitLab 11.4,
the bundled Prometheus 1.0 version is deprecated in Omnibus GitLab.
Prometheus 2.0 is now included.
However, the metrics format is incompatible with 1.0. Existing installations
can upgrade to 2.0 and optionally migrate their data
using an included tool.
With GitLab 12.0, any
installation not yet running Prometheus 2.0 will be automatically upgraded. Metric
data from Prometheus 1.0 will not be migrated and will be lost.
Beginning with GitLab 12.0,
TLS v1.1 will be disabled by default
to improve security. This mitigates numerous issues, including Heartbleed,
and makes GitLab compliant out of the box with the PCI DSS 3.1 standard.
To disable TLS v1.1 immediately, set nginx['ssl_protocols'] = "TLSv1.2" in
gitlab.rb and run gitlab-ctl reconfigure.
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