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.
And much more!
So many great features are available in this release like Auditing for feature flags,
Vulnerability remediation merge request,
and CI/CD templates for security jobs that you’ll want to read on to learn about them all!
Key improvements released in GitLab 11.9
Detect secrets and credentials in the repository
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.
Deprecations
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.
Planned removal date:
Jun. 22, 2019
Hipchat integration
Hipchat is being discontinued.
Therefore, we have
removed the existing GitLab Hipchat integration feature
in 11.9.
Planned removal date:
Mar. 22, 2019
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.
Planned removal date:
Mar. 22, 2019
Deprecate legacy code paths GitLab Runner
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.
In 11.3, GitLab Runner started supporting multiple cache
providers,
this resulted in new settings for S3 specific
configuration.
In the documentation
there is a table of what changed, and how to migrate to the new
configuration. 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.
Planned removal date:
June 22, 2019
Deprecate entrypoint feature flag for GitLab Runner
In 11.4 GitLab Runner introduced a feature flag
FF_K8S_USE_ENTRYPOINT_OVER_COMMAND
in order to fix issues like
#2338 &
#3536.
In GitLab 12.0, we will switch to the correct behavior as if the feature flag was
turned off. Please see this
issue for
additional details.
Planned removal date:
Jun. 22, 2019
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!
Planned removal date:
Jun. 22, 2019
Remove old GitLab Runner Helper commands
As part of our effort to support a Windows Docker
executor, we had to
deprecate some old commands that are used for the helper
image.
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.
Planned removal date:
Jun. 22, 2019
Developers can delete Git tags in GitLab 11.10
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.
Planned removal date:
Apr. 22, 2019
Support for Prometheus 1.x in Omnibus GitLab
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.
Planned removal date:
Jun. 22, 2019
TLS v1.1
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
.
Planned removal date:
Jun. 22, 2019
OpenShift template for installing GitLab
The official gitlab
helm chart
is the recommended method for operating GitLab on Kubernetes, including
deployment on OpenShift.
The OpenShift template
for installing GitLab is deprecated and will no longer be supported in
GitLab 12.0.
Planned removal date:
Jun. 22, 2019
Previous security job definitions
With the introduction of CI/CD templates for security jobs,
any previous job definition is deprecated and can be removed in GitLab 12.0 or later.
Update your job definitions to use the new syntax in order to benefit
from all the new security functionality provided by GitLab.
Planned removal date:
Jun. 22, 2019
System Info section in the admin panel
GitLab presents information about your GitLab instance at admin/system_info
,
but this information can be inaccurate.
We’re removing this section
of the admin panel in GitLab 12.0 and recommend using
other monitoring capabilities.
Planned removal date:
Jun. 22, 2019
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