GitLab 13.9 released with a Security Alert Dashboard and Maintenance Mode | GitLab

0
13

GitLab 13.9 is now available to strengthen DevSecOps at scale, with a Security Alert Dashboard to triage high priority alerts, Maintenance Mode for unfailing support of distributed teams, better visibility including additional support for DORA metrics, and advanced automation capabilities that will help you deliver “better products, faster.” These are just a few of the 60+ significant new features and improvements in this release.

Keeping a production environment both secure and available are top priorities, but they can be difficult to balance. Our new Security Alert Dashboard will help you balance security and reliability, by discerning between suspicious network activity that needs to be blocked immediately or that only needs further attention, minimizing disruption to users. We’re also excited to add JavaScript and Python support for coverage-guided fuzz testing, making it easier to build secure and reliable software, with results piped into your Security Dashboard.

GitLab is built for distributed teams. Our new Maintenance Mode enables read-only availability of your instance during more admin tasks, further reducing downtime. Scale and redundancy in data storage are improved with variable Gitaly replication factors, so you can tune your cluster to your own storage and budget constraints, while also enabling horizontal scaling.

Visibility is another core requirement in scaling DevOps, and Release Analytics at the group level continues to grow our support of DORA metrics, now aggregated for projects in a group. The new failed-test counter in Unit Test Reports and a new merge request metric, mean time to merge help you achieve and understand underlying efficiencies.

Automate your way to better products, faster

If you’re new to DevOps or renewing stalled efforts, an edict to deliver “better products, faster” can sound a little like “doing more, with less;” it may feel counterintuitive. But DevOps is the answer and automation is the key to doing both well.

One sure way to build and test faster is to look for redundancies in configuration. A new function in 13.9 saves you time by enabling reuse in your pipeline of a CI/CD configuration from any job, even if it’s in another file.

Automating at scale often requires mitigating complexity. When you’ve broken down your pipeline configuration into many files, you’ll like that you can now view an expanded version of the configuration. Deployment processes using parent-child or multi-project pipelines can also now use resource groups to manage concurrency across stages, jobs, and even projects.

We’re thrilled to introduce GPU and smart scheduling support for GitLab Runner, supporting specialized compute workloads like those in machine learning, and contributed by this month’s MVP, Andreas Gravgaard Andersen! Andreas showed awesome perseverance through reviews that spanned 10 months.

Thanks to another brilliant contribution, you can now follow other GitLab users’ activity! You might start by following its contributor, Roger Meier @bufferoverflow from Siemens, himself a GitLab Hall of Famer and sage of Open Source and InnerSource.

Thank you to Marshall Cottrell @marshall007 from NASA for creating a 1-liner installer for the GitLab Kubernetes Agent and simplifying its configuration, enabling users to get started with the Agent much more easily. Marshall’s feedback, ideas, and collaboration beyond merged contributions were also called “invaluable.”

Thank you to Kev @KevSlashNull of SiegeGG, who added an Activity filter to Vulnerability Reports, helping you drill into precisely the vulnerability list view you need. GitLab’s own AppSec team are grateful as are many others, for this and Kev’s many contributions.

GitLab isn’t only a DevOps platform, or a company, we’re also a community, and in 13.9 alone we enjoyed an incredible 299 merged wider community contributions. Selecting one MVP wasn’t easy; thank you all for your professionalism and hard work.

And so much more!

Some of our favorite quality of life improvements in 13.9 include:

Read on for more, and to preview what’s coming in next month’s release, check out our Upcoming Releases page and our 13.10 release kickoff video.

Key features released in GitLab 13.9

Security Alert Dashboard for Container Network Policy Alerts

We’re pleased to announce the first release of a dashboard for security
alerts! Users can now configure Container Network Policies to send alerts
to the security alert dashboard. This is especially useful when traffic
must be closely monitored but cannot be blocked entirely without negatively
impacting the business. You can configure the alerts at
Security & Compliance > Threat Management > Policies, and view them at
Security & Compliance > Threat Management > Alerts.

Deprecations

Container Scanning Engine Clair

GitLab 14.0 will replace its container scanning engine with Trivy. Currently, GitLab uses the open source Clair engine for container scanning. GitLab 13.9 deprecates Clair. This is not a hard breaking change, as customers who wish to continue to use Clair can do so by setting the CS_MAJOR_VERSION variable to version 3 (or earlier) in their gitlab-ci.yaml file. Since Clair is deprecated, however, note that GitLab will no longer update or maintain that scanning engine beginning in the 14.0 release. We advise customers to use the new default of Trivy beginning in GitLab 14.0 for regular updates and the latest features. Customers can provide feedback and get additional details on our open deprecation issue.

Deprecation date:
May 22, 2021

Deprecate Container Registry log formatters

Currently, GitLab supports:

Text, JSON, and logstash log formatting for app logs.
Text, JSON, and combined log formatting for access logs.

We will deprecate both logstash and combined, unifying the formatters for both app and access logs with only two options text (for development) and JSON.

Deprecation date:
February 22, 2021

Deprecate Container Registry logging hooks

The Container Registry currently supports logging hooks that can only be used for email notifications.

These days, alerts based on log entries are commonly handled by separate tools. As far as we know, none of our users rely on this functionality and it is not used at GitLab either. The implementation of this feature is tightly coupled with the underlying logging library, which is a limitation for our ability to switch dependencies without affecting the available features.

In an effort to simplify the registry features and configurations, we will drop support for logging hooks.

Deprecation date:
February 22, 2021

Deprecate Container Registry maxidle and maxactive Redis pool settings

Some of the configuration settings that we currently expose for the Redis connection pool are tied to the underlying Redis client and do not have an equivalent in alternative libraries. As we start working on improving the Redis integration, such as adding support for Sentinel, we decided to start working towards replacing the current Redis client dependency with a more feature-rich alternative that can be better supported. To do this, we need to replace the current Redis pool configuration settings that are tied to the current client library.

We intend to:

Remove the redis.pool.maxidle and redis.pool.maxactive settings.
Add redis.pool.size (maximum number of connections), redis.pool.minidle (minimum number of idle connections), and redis.pool.maxlifetime (maximum amount of time a connection may be reused) settings.

Deprecation date:
February 22, 2021

Deprecate Container Registry support for Bugsnag

Bugsnag is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for Bugsnag.

Deprecation date:
February 22, 2021

Deprecate Container Registry support for NewRelic

NewRelic is one of the error reporting services supported by the Container Registry. As far as we know, none of our users rely on this service, and at GitLab we use Sentry. In an effort to simplify and consolidate the supported error reporting services, we intend to add support for Sentry and remove support for NewRelic.

Deprecation date:
February 22, 2021

Deprecate Container Registry support for TLS 1.0 and 1.1

Support for TLS 1.0 and TLS 1.1 has been deprecated and removed for GitLab for security reasons. We will do the same for the GitLab Container Registry, which currently supports 1.0 (default), 1.1, 1.2, and 1.3. and defaults to 1.0.

We will deprecate support for TLS 1.0 and TLS 1.1, showing a warning log message when these are used. Support for these versions will be removed and TLS 1.2 will become the default.

Deprecation date:
February 22, 2021

Deprecate and remove secret_detection_default_branch job

To ensure Secret Detection was scanning both default branches and feature branches we introduced two separate secret detection CI jobs in our managed Secret-Detection.gitlab-ci.yml template. These two CI jobs, secret_detection_default_branch and secret_detection, created confusion and complexity in the CI rules logic. As part of this deprecation, we are moving the rule logic into script which will determine how the secret_detection job is run (historic, on a branch, commits, etc).
If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml, you must update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will stop supporting the old secret_detection_default_branch job with GitLab 14.0, releasing May 22, 2021.

Deprecation date:
March 17, 2021

Deprecate disk source configuration for GitLab Pages

GitLab Pages API-based configuration has been available since GitLab 13.0 and will replace the disk source configuration, which will be removed in GitLab 14.0. We recommend that you move away from using disk source configuration and move to gitlab for an API-based configuration, since disk will no longer be supported and cannot be chosen. You can migrate away from the ‘disk’ source configuration by setting gitlab_pages[‘domain_config_source’] = “gitlab” in your gitlab.rb/etc/gitlab/gitlab.rb file. We recommend that you do this before GitLab 14.0 so you can find and troubleshoot any potential problems ahead of time.

Deprecation date:
May 22, 2021

Deprecate pulls that use v1 of the Docker registry API

GitLab disabled pulls via the Docker registry v1 APIs on January 22, 2021. Deprecated by Docker in June, 2019, deprecating this feature allows the GitLab team to focus on features and fixes that provide you with more value and target current registry use cases.

Existing users of the v1 registry API on GitLab can move to the v2 registry API by completing the following steps:

Update your Docker Engine to 17.12 or later so it is compatible with the v2 registry API.
If you have content in GitLab that is in the v1 format, you can move it to the v2 format by using a newer Docker client (more recent than 1.12) to rebuild the image and push it to GitLab.

Deprecation date:
February 22, 2021

Deprecating SAST analyzer SAST_GOSEC_CONFIG variable in favor of custom rulesets

With the release of SAST Custom Rulesets in GitLab 13.5 we allow greater flexibility in configuration options for our Go analyzer (GoSec). As a result we no longer plan to support our less flexible SAST_GOSEC_CONFIG analyzer setting. This variable will be deprecated in GitLab 13.10, and removed in GitLab 14.0.
If you override or leverage SAST_GOSEC_CONFIG in your CI file, you will need to update your SAST CI configuration or pin to an older version of the GoSec analyzer . We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. We will remove the old SAST_GOSEC_CONFIG variable in GitLab 14.0, releasing May 22, 2021.

Deprecation date:
March 22, 2021

Deprecation of release description in the Tags API

GitLab 14.0 will remove support for the release description in the Tags API. You’ll no longer be able to add a release description when creating a new tag. You’ll also no longer be able to create or update a release through the Tags API. Please migrate to use the Releases API instead.

Deprecation date:
May 22, 2021

Deprecations for Dependency Scanning

Previously to exclude a DS analyzer, you needed to remove it from the default list of analyzers and use that to set the DS_DEFAULT_ANALYZERS variable in your project’s CI template. We determined it should be easier to avoid running a particular analyzer without losing the benefit of newly added analyzers. As a result we ask you to migrate from DS_DEFAULT_ANALYZERS to DS_EXCLUDED_ANALYZERS when it is available. Read about it in issue #287691 or this blog post.

Previously to prevent the Gemnasium analyzers to fetch the advisory database at runtime, you needed to set the GEMNASIUM_DB_UPDATE env variable. Though, this is not documented properly and its naming is inconsistent with the equivalent BUNDLER_AUDIT_UPDATE_DISABLED variable. As a result we ask you to migrate from GEMNASIUM_DB_UPDATE to GEMNASIUM_UPDATE_DISABLED when it is available. Read about it in issue #215483 or this blog post.

Deprecation date:
May 22nd, 2021

Fuzz test jobs will fail with allow_failure if vulnerabilities are found

To make sure our fuzz testing jobs behave consistently with each other, as part of
14.0, all fuzz testing jobs will start failing if a job finds vulnerabilities. These
jobs will have allow_failure=true set in them so you will get a warning but
your pipeline as a whole will not fail if a vulnerability is found.

This is the current behavior for several of the fuzz scanners, such as the Go and
C++ fuzz engines.

No action is required on your part to use this new behavior. If you are checking the
results of a pipeline fuzz testing job as part of a script, consider if those scripts
will need any updates.

Deprecation date:
May 22, 2021

Git default branch name change

Every Git repository has an initial branch. It’s the first branch to be created automatically when you create a new repository. By default, this initial branch is named master. Git version 2.31.0 (scheduled for release March 15, 2021) will change the default branch name in Git from master to main. In coordination with the Git project and the broader community, GitLab will be changing the default branch name for new projects on both our SaaS (GitLab.com) and self-managed offerings starting with GitLab 14.0. This will not affect existing projects.

For more information, see the related epic and the Git mailing list discussion.

Deprecation date:
Apr 22, 2021

GitLab OAuth implicit grant deprecation

As OAuth 2.1 omits the implicit grant, GitLab will deprecate the OAuth 2 implicit grant flow. Beginning in 14.0, new applications will not be able to be created with the OAuth 2 implicit grant flow. Existing OAuth implicit grant flows will no longer be supported in 14.4. Please migrate existing applications to other supported OAuth2 flows before release 14.4.

Deprecation date:
May 22, 2021

GitLab Runner installation to ignore the skel directory

In GitLab Runner 14.0, the installation process will ignore the skel directory by default when creating the user home directory. Refer to issue #4845 for details.

Deprecation date:
Jun 22, 2021

Helm v2 support

Helm v2 was officially deprecated in November of 2020, with the stable repository being de-listed from the Helm Hub shortly thereafter. With the release of GitLab 14.0, which will include the 5.0 release of the GitLab Helm chart, Helm v2 will no longer be supported.

The Cloud Native GitLab Helm chart will not immediately be altered to Helm v3’s new schema, but moving forward there are opportunities for improved maintainability we would like to be able to leverage. Deprecating the constraint that functionality be limited to that within Helm v2 allows us to better the experience for our users.

Deprecation date:
May 22, 2021

Legacy Feature Flags Deprecation

Legacy Feature Flags became read-only in GitLab 13.4. Support for legacy Feature Flags will be removed in GitLab 14.0. You must migrate your legacy Feature Flags to the new version. You can do this by first taking a screenshot of the legacy flag for tracking. Then delete the flag through the API or UI (you don’t need to alter the code) and create a new Feature Flag with the same name as the legacy flag you deleted. Also, make sure the strategies and environments match the deleted flag. We created a video tutorial to help with this migration.

Deprecation date:
May 22, 2021

Limit projects returned in GET /groups/:id/

To improve performance, we will be limiting the number of projects returned from the GET /groups/:id/ API call to 100. To get a complete list of projects, please use the GET /groups/:id/projects API call.

Deprecation date:
May 22, 2021

Make pwsh the default shell for newly-registered Windows Runners

In GitLab Runner 13.2, PowerShell Core support was added to the Shell executor. In 14.0, pwsh will be the default shell for newly-registered Windows runners. Windows CMD will still be available as a shell option for Windows runners. Refer to issue #26419 for details.

Deprecation date:
Jun 22, 2021

Migrate from SAST_DEFAULT_ANALYZERS to SAST_EXCLUDED_ANALYZERS

Until 13.9, if you wanted to avoid running one particular GitLab SAST analyzer, you needed to remove it from the long string of analyzers in the SAST.gitlab-ci.yml file and use that to set the SAST_DEFAULT_ANALYZERS in your project’s CI file. If you did this, it would exclude you from future new analyzers because this string hard codes the list of analyzers to execute. We avoid this problem by inverting this variable’s logic to exclude, rather than choose default analyzers.
Beginning with 13.9, we are migrating to SAST_EXCLUDED_ANALYZERS in our SAST.gitlab-ci.yml file. We encourage anyone who uses a customized SAST configuration in their project CI file to migrate to this new variable. If you have not overridden SAST_DEFAULT_ANALYZERS, no action is needed. SAST_DEFAULT_ANALYZERS will be removed in GitLab 14.0, which will release on April 22, 2021.

Deprecation date:
February 22, 2021

Pin Static Analysis analyzers and tools to minor versions

With the maturity of GitLab Secure scanning tools, we’ve needed to add more granularity into the versioning of our SAST analyzers. This change will make it easier for customers to set specifically which version of analyzers they want to run, introducing more control into how customers choose to upgrade their SAST scanning. Prior to 13.10, GitLab shared a major version number for all our SAST analyzers and tools and prevented the use of semantic version numbering for updates.

Beginning in 13.10 GitLab SAST and Secret Detection will start using major.minor version pinning in our .gitlab-ci.yml files and will ship major.minor tags on analyzer containers. We will also deprecate the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml CI template in favor of major.minor tags for each analyzer. If you override or maintain custom versions of SAST.gitlab-ci.yml, Secret-Detection.gitlab-ci.yml or rely on analyzer x-y-stable tags, you will want to update your CI templates. We strongly encourage inheriting and overriding our managed CI templates to future proof your CI templates. This change will allow you to instead override with a pinned major.minor version to gain more granular control of future feature updates. We will remove shared major version pinning and the SAST_ANALYZER_IMAGE_TAG variable in our managed SAST.gitlab-ci.yml with GitLab 14.0, releasing May 22, 2021.

Deprecation date:
March 22, 2021

PostgreSQL 11 support

PostgreSQL 12 will be the minimum required version in GitLab 14.0. It offers significant improvements to indexing, partitioning, and general performance benefits.

Starting in GitLab 13.7, all new installations default to version 12. From GitLab 13.8, single-node instances are automatically upgraded as well. If you aren’t ready to upgrade, you can opt-out of automatic upgrades.

Multi-node database instances will need to switch from repmgr to Patroni, prior to upgrading with Patroni. Geo secondaries can then be updated and re-synchronized.

Deprecation date:
May 22, 2021

Removals for License Compliance

In 13.0, we deprecated the License-Management CI template and renamed it License-Scanning. We have been providing backward compatibility by warning users of the old template to switch. Now in 14.0, we are completely removing the License-Management CI template. Read about it in issue #216261 or this blog post.

Deprecation date:
May 22nd, 2021

In GitLab Runner 13.3, a symlink was added from /user/lib/gitlab-runner/gitlab-runner to /usr/bin/gitlab-runner. In 14.0, we will remove this symlink and the runner will be installed in /usr/bin/gitlab-runner. Refer to issue #26651 for details.

Deprecation date:
Jun 22, 2021

Remove FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL feature flag

In GitLab Runner 13.1, issue #3376, we introduced sigterm and then sigkill to a process in the Shell executor. We also introduced a new feature flag, FF_SHELL_EXECUTOR_USE_LEGACY_PROCESS_KILL, so you can use the previous process termination sequence. In GitLab Runner 14.0, issue #6413, we will remove the feature flag.

Deprecation date:
Jun 22, 2021

Remove FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag

In GitLab Runner 14.0, we will remove the FF_USE_GO_CLOUD_WITH_CACHE_ARCHIVER feature flag. Refer to issue #27175 for details.

Deprecation date:
Jun 22, 2021

Remove Ubuntu 19.10 (Eoan Ermine) package

Ubuntu 19.10 (Eoan Ermine) reached end of life on Friday, July 17, 2020. In GitLab Runner 14.0, we will remove the Ubuntu 19.10 (Eoan Ermine) from our package distribution. Refer to issue #26036 for details.

Deprecation date:
Jun 22, 2021

Remove off peak time mode configuration for Docker Machine autoscaling

In GitLab Runner 13.0, issue #5069, we introduced new timing options for the GitLab Docker Machine executor. In GitLab Runner 14.0, we plan to remove the old configuration option, off peak time mode.

Deprecation date:
Jun 22, 2021

Remove success and failure for finished build metric conversion

In GitLab Runner 13.5, we introduced failed and success states for a job. To support Prometheus rules, we chose to convert success/failure to finished for the metric. In 14.0, we will remove the conversion. Refer to issue #26900 for details.

Deprecation date:
Jun 22, 2021

Remove support for Windows Server 1903 image

In 14.0, we will remove support for Windows Server 1903 as Microsoft ended support for this version on 2020-08-12. Refer to issue #27551 for details.

Deprecation date:
Jun 22, 2021

Remove translation from step_script to build_script in custom executor

In GitLab Runner 13.2 a translation for step_script to build_script was added to the custom executor. In 14.0 the ‘build_script’ stage will be replaced with ‘step_script`. Refer to issue #26426 for details.

Deprecation date:
Jun 22, 2021

Renewal of the stable Auto Deploy template in Auto DevOps

In GitLab 14.0, we will renew the Auto Deploy CI template to the latest version. This includes new features, bug fixes, and performance improvements with a dependency on the v2 auto-deploy-image. This latest template is opt-in. Unless you specifically customize Auto DevOps in your project, it uses the stable template with a dependency on the v1 auto-deploy-image.

Since the v1 and v2 versions are not backwards compatible, your project might encounter an unexpected failure if you already have a deployed application. Please follow the upgrade guide to upgrade your environments. You can also start using the latest template today by following the early adoption guide.

Deprecation date:
May 22, 2021

Unicorn will be removed in favor of Puma for GitLab self-managed

Unicorn support is deprecated and will be removed in GitLab 14.0. You must migrate to Puma before upgrading to GitLab 14.0.

Deprecation date:
May 22, 2021

WIP (work in progress) merge requests term deprecated

We renamed the WIP (work in progress) term for merge requests to “draft”,
because it’s more inclusive and self-explanatory.
The WIP term is now deprecated. We will support its use through the next major
GitLab release (14.0), after which it will be removed.

Deprecation date:
May 22, 2021

Removals

Geo Foreign Data Wrapper settings removal in 14.0

As announced in GitLab 13.3, the following configuration settings in /etc/gitlab/gitlab.rb are deprecated and will be removed in 14.0:

geo_secondary[‘db_fdw’]
geo_postgresql[‘fdw_external_user’]
geo_postgresql[‘fdw_external_password’]
gitlab-_rails[‘geo_migrated_local_files_clean_up_worker_cron’]

Removal date:
May 22, 2021

Legacy storage removal in 14.0

As announced in GitLab 13.0 legacy storage is deprecated and will be removed in GitLab 14.0.

Before upgrading to GitLab 14.0 you must migrate fully to hashed storage.

Removal date:
May 22, 2021

CEVAP VER

Lütfen yorumunuzu giriniz!
Lütfen isminizi buraya giriniz