Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
9fe6f84c1f
commit
db5097a28b
|
|
@ -60,6 +60,7 @@ class Member < ApplicationRecord
|
|||
if: :project_bot?
|
||||
validate :access_level_inclusion
|
||||
validate :validate_member_role_access_level
|
||||
validate :validate_access_level_locked_for_member_role, on: :update
|
||||
|
||||
scope :with_invited_user_state, -> do
|
||||
joins('LEFT JOIN users as invited_user ON invited_user.email = members.invite_email')
|
||||
|
|
@ -438,6 +439,14 @@ class Member < ApplicationRecord
|
|||
end
|
||||
end
|
||||
|
||||
def validate_access_level_locked_for_member_role
|
||||
return unless member_role_id
|
||||
|
||||
if access_level_changed?
|
||||
errors.add(:access_level, _("cannot be changed since member is associated with a custom role"))
|
||||
end
|
||||
end
|
||||
|
||||
def send_invite
|
||||
# override in subclass
|
||||
end
|
||||
|
|
|
|||
|
|
@ -0,0 +1,8 @@
|
|||
---
|
||||
name: increase_branch_cache_expiry
|
||||
introduced_by_url: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/96739
|
||||
rollout_issue_url: https://gitlab.com/gitlab-org/gitlab/-/issues/372331
|
||||
milestone: '15.4'
|
||||
type: ops
|
||||
group: group::code review
|
||||
default_enabled: false
|
||||
|
|
@ -6093,6 +6093,7 @@ The connection type for [`BoardEpic`](#boardepic).
|
|||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="boardepicconnectioncount"></a>`count` | [`Int!`](#int) | Total count of collection. |
|
||||
| <a id="boardepicconnectionedges"></a>`edges` | [`[BoardEpicEdge]`](#boardepicedge) | A list of edges. |
|
||||
| <a id="boardepicconnectionnodes"></a>`nodes` | [`[BoardEpic]`](#boardepic) | A list of nodes. |
|
||||
| <a id="boardepicconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
|
||||
|
|
@ -7265,6 +7266,7 @@ The connection type for [`Epic`](#epic).
|
|||
|
||||
| Name | Type | Description |
|
||||
| ---- | ---- | ----------- |
|
||||
| <a id="epicconnectioncount"></a>`count` | [`Int!`](#int) | Total count of collection. |
|
||||
| <a id="epicconnectionedges"></a>`edges` | [`[EpicEdge]`](#epicedge) | A list of edges. |
|
||||
| <a id="epicconnectionnodes"></a>`nodes` | [`[Epic]`](#epic) | A list of nodes. |
|
||||
| <a id="epicconnectionpageinfo"></a>`pageInfo` | [`PageInfo!`](#pageinfo) | Information to aid in pagination. |
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ After the integration is [set up on GitLab and Jira](#configure-the-integration)
|
|||
- Refer to any Jira issue by its ID (in uppercase) in GitLab branch names,
|
||||
commit messages, and merge request titles.
|
||||
- See the linked branches, commits, and merge requests in Jira issues.
|
||||
- Create GitLab branches from Jira Cloud issues ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66032) in GitLab 14.2).
|
||||
- Create GitLab branches from Jira Cloud issues ([introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/66032) in GitLab 14.2 for the GitLab for Jira app).
|
||||
|
||||
At this time, merge requests are called "pull requests" in Jira issues.
|
||||
This name may change in a future Jira release.
|
||||
|
|
@ -85,9 +85,10 @@ documentation for [central administration of project integrations](../../user/ad
|
|||
|
||||
## Limitations
|
||||
|
||||
This integration is not supported on GitLab instances under a
|
||||
[relative URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab).
|
||||
For example, `http://example.com/gitlab`.
|
||||
- This integration is not supported on GitLab instances under a
|
||||
[relative URL](https://docs.gitlab.com/omnibus/settings/configuration.html#configure-a-relative-url-for-gitlab)
|
||||
(for example, `http://example.com/gitlab`).
|
||||
- [Creating a branch](https://gitlab.com/gitlab-org/gitlab/-/issues/2647) is only supported by the GitLab for Jira app and is not available within the DVCS integration. See [officially supported DVCS features](https://confluence.atlassian.com/adminjiraserver/integrating-with-development-tools-938846890.html) for more information.
|
||||
|
||||
## Troubleshoot the development panel
|
||||
|
||||
|
|
|
|||
|
|
@ -12,15 +12,14 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
GitLab Auto DevOps is a collection of pre-configured features and integrations
|
||||
that work together to support your software delivery process.
|
||||
|
||||
Auto DevOps features and integrations:
|
||||
Auto DevOps detects your programming language and uses [CI/CD templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates)
|
||||
to create and run default pipelines to build and test your application. Then, you can [configure deployments](requirements.md) to deploy your apps to staging
|
||||
and production, and set up [Review Apps](stages.md#auto-review-apps)
|
||||
to preview your changes per branch.
|
||||
|
||||
- Detect your code's language.
|
||||
- Build and test your application.
|
||||
- Measure code quality.
|
||||
- Scan for vulnerabilities and security flaws.
|
||||
- Check for licensing issues.
|
||||
- Monitor in real time.
|
||||
- Deploy your application.
|
||||
You can use default settings to quickly ship your apps, and iterate and [customize](customize.md) later.
|
||||
|
||||
You can also [manage Auto DevOps with APIs](customize.md#extend-auto-devops-with-the-api).
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an introduction to Auto DevOps, watch [Auto DevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
|
||||
|
|
@ -58,33 +57,6 @@ Based on the DevOps [stages](stages.md), use Auto DevOps to:
|
|||
- [Auto Static Application Security Testing (SAST)](stages.md#auto-sast)
|
||||
- [Auto Secret Detection](stages.md#auto-secret-detection)
|
||||
|
||||
### How it works
|
||||
|
||||
Auto DevOps detects your code language and uses [CI/CD templates](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates)
|
||||
to create and run default pipelines. All you need to kick it off is to
|
||||
[enable](#enable-or-disable-auto-devops) it.
|
||||
|
||||
Auto DevOps starts by building and testing your application. Then, based on your
|
||||
[predefined deployment configuration](requirements.md),
|
||||
creates the necessary jobs to deploy your apps to staging
|
||||
and/or production. It also sets up [Review Apps](stages.md#auto-review-apps)
|
||||
so that you can preview your changes in a per-branch basis.
|
||||
|
||||
Note that you don't need to set up the deployment upfront. Auto DevOps
|
||||
still builds and tests your application. You can define the deployment later.
|
||||
|
||||
Auto DevOps avoids the hassle of having to create entire pipelines manually.
|
||||
Keep it simple and facilitate an iterative approach: ship your app first,
|
||||
then explore the [customizations](customize.md) later.
|
||||
You can also [manage Auto DevOps with APIs](customize.md#extend-auto-devops-with-the-api).
|
||||
|
||||
Some of the benefits of using Auto DevOps as part of your workflow are:
|
||||
|
||||
- Consistency: always start from default templates.
|
||||
- Simplicity: create your pipeline with the default settings first, iterate later.
|
||||
- Productivity: deploy multiple apps in a short period of time.
|
||||
- Efficiency: get things done fast.
|
||||
|
||||
### Comparison to application platforms and PaaS
|
||||
|
||||
Auto DevOps provides features often included in an application
|
||||
|
|
@ -146,11 +118,11 @@ you can enable it for a [group](#at-the-group-level) or an
|
|||
[instance](#at-the-instance-level). This can save you the time of
|
||||
enabling it one by one.
|
||||
|
||||
Only project Maintainers can enable or disable Auto DevOps at the project level.
|
||||
Prerequisites:
|
||||
|
||||
Before enabling Auto DevOps, ensure that your project does not have a
|
||||
`.gitlab-ci.yml` present. If present, your CI/CD configuration takes
|
||||
precedence over the Auto DevOps pipeline.
|
||||
- You must have at least the Maintainer role for the project.
|
||||
- Ensure your project does not have a `.gitlab-ci.yml` present. If present, your CI/CD configuration takes
|
||||
precedence over the Auto DevOps pipeline.
|
||||
|
||||
To enable Auto DevOps for a project:
|
||||
|
||||
|
|
@ -178,8 +150,9 @@ rather than enabling individually for each subgroup or project.
|
|||
When enabled for a group, you can still disable Auto DevOps
|
||||
for the subgroups and projects where you don't want to use it.
|
||||
|
||||
Only GitLab administrators and group owners can enable or disable Auto DevOps
|
||||
at the group level.
|
||||
Prerequisites:
|
||||
|
||||
- You must have at least the Owner role for the group.
|
||||
|
||||
To enable Auto DevOps for a group:
|
||||
|
||||
|
|
@ -193,7 +166,7 @@ To disable Auto DevOps on the group level, follow the same process and
|
|||
clear the **Default to Auto DevOps pipeline** checkbox.
|
||||
|
||||
After enabling Auto DevOps at the group level, you can trigger the
|
||||
Auto DevOps pipeline for any project that belongs to that group. To do so:
|
||||
Auto DevOps pipeline for any project that belongs to that group:
|
||||
|
||||
1. On the top bar, select **Menu > Projects** and find your project.
|
||||
1. Make sure the project doesn't contain a `.gitlab-ci.yml` file.
|
||||
|
|
@ -207,12 +180,13 @@ instance become enabled. This is convenient when you want to run Auto DevOps by
|
|||
default for all projects. You can still disable Auto DevOps individually for
|
||||
the groups and projects where you don't want to run it.
|
||||
|
||||
Only GitLab administrators can enable or disable Auto DevOps at the instance
|
||||
level.
|
||||
|
||||
Even when disabled for an instance, group owners and project maintainers
|
||||
Even when disabled for an instance, group Owners and project Maintainers
|
||||
can still enable Auto DevOps at the group and project levels.
|
||||
|
||||
Prerequisites:
|
||||
|
||||
- You must be an administrator for the instance.
|
||||
|
||||
To enable Auto DevOps for your instance:
|
||||
|
||||
1. On the top bar, select **Menu > Admin**.
|
||||
|
|
@ -232,6 +206,13 @@ it remains unchanged and Auto DevOps doesn't affect it.
|
|||
To disable Auto DevOps in the instance level, follow the same process
|
||||
and clear the **Default to Auto DevOps pipeline** checkbox.
|
||||
|
||||
### Private registry support
|
||||
|
||||
There is no guarantee that you can use a private container registry with Auto DevOps.
|
||||
|
||||
Instead, use the [GitLab Container Registry](../../user/packages/container_registry/index.md) with Auto DevOps to
|
||||
simplify configuration and prevent any unforeseen issues.
|
||||
|
||||
### Quick start
|
||||
|
||||
- [Use Auto DevOps to deploy to a Kubernetes cluster on Google Kubernetes Engine (GKE)](cloud_deployments/auto_devops_with_gke.md)
|
||||
|
|
@ -252,16 +233,7 @@ match your new GitLab version:
|
|||
- Environment variables.
|
||||
- [Upgrading PostgreSQL](upgrading_postgresql.md).
|
||||
|
||||
## Limitations
|
||||
|
||||
### Private registry support
|
||||
|
||||
We cannot guarantee that you can use a private container registry with Auto DevOps.
|
||||
|
||||
We strongly advise you to use GitLab Container Registry with Auto DevOps to
|
||||
simplify configuration and prevent any unforeseen issues.
|
||||
|
||||
### Install applications behind a proxy
|
||||
## Install applications behind a proxy
|
||||
|
||||
The GitLab integration with Helm does not support installing applications when
|
||||
behind a proxy.
|
||||
|
|
|
|||
|
|
@ -199,7 +199,7 @@ see the documentation.
|
|||
## Auto Secret Detection
|
||||
|
||||
> - Introduced in GitLab 13.1.
|
||||
> - Select functionality [made available](../../user/application_security/secret_detection/index.md#making-secret-detection-available-to-all-gitlab-tiers) in all tiers in GitLab 13.3
|
||||
> - Select functionality [made available](../../user/application_security/secret_detection/index.md#features-per-tier) in all tiers in GitLab 13.3
|
||||
|
||||
Secret Detection uses the
|
||||
[Secret Detection Docker image](https://gitlab.com/gitlab-org/security-products/analyzers/secrets) to run Secret Detection on the current code, and checks for leaked secrets. Auto Secret Detection requires [GitLab Runner](https://docs.gitlab.com/runner/) 11.5 or above.
|
||||
|
|
|
|||
|
|
@ -56,7 +56,7 @@ You can configure the following security controls:
|
|||
- Can be configured by adding a configuration block to your agent configuration. For more details, read [Operational Container Scanning](../../clusters/agent/vulnerabilities.md#enable-operational-container-scanning).
|
||||
- [Secret Detection](../secret_detection/index.md)
|
||||
- Select **Configure with a merge request** to create a merge request with the changes required to
|
||||
enable Secret Detection. For more details, read [Enable Secret Detection via an automatic merge request](../secret_detection/index.md#enable-secret-detection-via-an-automatic-merge-request).
|
||||
enable Secret Detection. For more details, read [Enable Secret Detection using a merge request](../secret_detection/index.md#enable-secret-detection-using-a-merge-request).
|
||||
- [API Fuzzing](../api_fuzzing/index.md)
|
||||
- Select **Enable API Fuzzing** to use API Fuzzing for the current project. For more details, read [API Fuzzing](../../../user/application_security/api_fuzzing/index.md#enable-web-api-fuzzing).
|
||||
- [Coverage Fuzzing](../coverage_fuzzing/index.md)
|
||||
|
|
|
|||
|
|
@ -361,7 +361,7 @@ Learn more on overriding security jobs:
|
|||
- [Overriding SAST jobs](sast/index.md#overriding-sast-jobs).
|
||||
- [Overriding Dependency Scanning jobs](dependency_scanning/index.md#overriding-dependency-scanning-jobs).
|
||||
- [Overriding Container Scanning jobs](container_scanning/index.md#overriding-the-container-scanning-template).
|
||||
- [Overriding Secret Detection jobs](secret_detection/index.md#customizing-settings).
|
||||
- [Overriding Secret Detection jobs](secret_detection/index.md#configure-scan-settings).
|
||||
- [Overriding DAST jobs](dast/index.md#customize-dast-settings).
|
||||
- [Overriding License Compliance jobs](../compliance/license_compliance/index.md#overriding-the-template).
|
||||
|
||||
|
|
|
|||
|
|
@ -6,16 +6,35 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
# Secret Detection **(FREE)**
|
||||
|
||||
> [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/222788) from GitLab Ultimate to GitLab Free in 13.3.
|
||||
> - In GitLab 13.1, Secret Detection was split from the [SAST configuration](../sast/index.md#configuration)
|
||||
> into its own CI/CD template. If you're using GitLab 13.0 or earlier and SAST is enabled, then
|
||||
> Secret Detection is already enabled.
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/issues/222788) from GitLab Ultimate to GitLab
|
||||
> Free in 13.3.
|
||||
> - [In GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/297269), Secret Detection jobs
|
||||
> `secret_detection_default_branch` and `secret_detection` were consolidated into one job,
|
||||
> `secret_detection`.
|
||||
|
||||
A recurring problem when developing applications is that people may accidentally commit secrets to
|
||||
their remote Git repositories. Secrets include keys, passwords, API tokens, and other sensitive
|
||||
People may accidentally commit secrets to
|
||||
remote Git repositories. Secrets include keys, passwords, API tokens, and other sensitive
|
||||
information. Anyone with access to the repository could use the secrets for malicious purposes.
|
||||
Secrets exposed in this way must be treated as compromised, and be replaced, which can be costly.
|
||||
It's important to prevent secrets from being committed to a Git repository.
|
||||
Exposed secrets are compromised and must be replaced, which can be costly.
|
||||
|
||||
Secret Detection uses the [Gitleaks](https://github.com/zricethezav/gitleaks) tool to scan the
|
||||
repository for secrets. All identified secrets are reported in the:
|
||||
To help prevent secrets from being committed to a Git repository, you can use Secret Detection
|
||||
to scan your repository for secrets. Scanning is language
|
||||
and framework agnostic, but does not support scanning binary files.
|
||||
|
||||
Secret Detection uses a specific analyzer containing the
|
||||
[Gitleaks](https://github.com/zricethezav/gitleaks) tool to scan the repository for secrets, in a
|
||||
`secret-detection` job. The results are saved as a
|
||||
[Secret Detection report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportssecret_detection)
|
||||
that you can later download and analyze. Due to implementation limitations, we always take the
|
||||
latest Secret Detection artifact available.
|
||||
|
||||
GitLab SaaS supports post-processing hooks, so you can take action when a secret is found. For
|
||||
more information, see [Post-processing and revocation](post_processing.md).
|
||||
|
||||
All identified secrets are reported in the:
|
||||
|
||||
- Merge request widget
|
||||
- Pipelines' **Security** tab
|
||||
|
|
@ -23,9 +42,6 @@ repository for secrets. All identified secrets are reported in the:
|
|||
|
||||
|
||||
|
||||
WARNING:
|
||||
Secret Detection does not support scanning binary files.
|
||||
|
||||
## Detected secrets
|
||||
|
||||
Secret Detection uses a [default ruleset](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/gitleaks.toml)
|
||||
|
|
@ -34,92 +50,136 @@ patterns using [custom rulesets](#custom-rulesets). If you want to contribute ru
|
|||
"well-identifiable" secrets, follow the steps detailed in the
|
||||
[community contributions guidelines](https://gitlab.com/gitlab-org/gitlab/-/issues/345453).
|
||||
|
||||
## Requirements
|
||||
## Features per tier
|
||||
|
||||
To run Secret Detection jobs, by default, you need GitLab Runner with the
|
||||
[`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
|
||||
[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
|
||||
If you're using the shared runners on GitLab.com, this is enabled by default.
|
||||
Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/).
|
||||
|
||||
WARNING:
|
||||
Our Secret Detection jobs expect a Linux/amd64 container type. Windows containers are not supported.
|
||||
| Capability | In Free & Premium | In Ultimate |
|
||||
|:---------------------------------------------------------------- |:-----------------------|:-----------------------|
|
||||
| [Configure Secret Detection scanner](#enable-secret-detection) | **{check-circle}** Yes | **{check-circle}** Yes |
|
||||
| [Customize Secret Detection settings](#configure-scan-settings) | **{check-circle}** Yes | **{check-circle}** Yes |
|
||||
| Download [JSON Report](../sast/index.md#reports-json-format) | **{check-circle}** Yes | **{check-circle}** Yes |
|
||||
| See new findings in the merge request widget | **{dotted-circle}** No | **{check-circle}** Yes |
|
||||
| View identified secrets in the pipelines' **Security** tab | **{dotted-circle}** No | **{check-circle}** Yes |
|
||||
| [Manage vulnerabilities](../vulnerabilities/index.md) | **{dotted-circle}** No | **{check-circle}** Yes |
|
||||
| [Access the Security Dashboard](../security_dashboard/index.md) | **{dotted-circle}** No | **{check-circle}** Yes |
|
||||
| [Customize Secret Detection rulesets](#custom-rulesets) | **{dotted-circle}** No | **{check-circle}** Yes |
|
||||
|
||||
WARNING:
|
||||
If you use your own runners, make sure the Docker version installed
|
||||
is **not** `19.03.0`. See [troubleshooting information](../sast#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
|
||||
## Enable Secret Detection
|
||||
|
||||
### Making Secret Detection available to all GitLab tiers
|
||||
Prerequisites:
|
||||
|
||||
To make Secret Detection available to as many customers as possible, we have enabled it for all GitLab tiers.
|
||||
However not all features are available on every tier. See the breakdown below for more details.
|
||||
- GitLab Runner with the [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
|
||||
[`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html) executor. If you're using the
|
||||
shared runners on GitLab.com, this is enabled by default.
|
||||
- If you use your own runners, make sure the Docker version installed is **not** `19.03.0`. See
|
||||
[troubleshooting information](../sast#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error)
|
||||
for details.
|
||||
- Linux/amd64 container type. Windows containers are not supported.
|
||||
- GitLab CI/CD configuration (`.gitlab-ci.yml`) must include the `test` stage.
|
||||
|
||||
#### Summary of features per tier
|
||||
To enable Secret Detection, either:
|
||||
|
||||
Different features are available in different [GitLab tiers](https://about.gitlab.com/pricing/),
|
||||
as shown in the following table:
|
||||
- Enable [Auto DevOps](../../../topics/autodevops/index.md), which includes [Auto Secret Detection](../../../topics/autodevops/stages.md#auto-secret-detection).
|
||||
|
||||
| Capability | In Free & Premium | In Ultimate |
|
||||
|:----------------------------------------------------------------|:--------------------|:-------------------|
|
||||
| [Configure Secret Detection scanner](#configuration) | **{check-circle}** | **{check-circle}** |
|
||||
| [Customize Secret Detection settings](#customizing-settings) | **{check-circle}** | **{check-circle}** |
|
||||
| Download [JSON Report](../sast/index.md#reports-json-format) | **{check-circle}** | **{check-circle}** |
|
||||
| See new findings in the merge request widget | **{dotted-circle}** | **{check-circle}** |
|
||||
| View identified secrets in the pipelines' **Security** tab | **{dotted-circle}** | **{check-circle}** |
|
||||
| [Manage vulnerabilities](../vulnerabilities/index.md) | **{dotted-circle}** | **{check-circle}** |
|
||||
| [Access the Security Dashboard](../security_dashboard/index.md) | **{dotted-circle}** | **{check-circle}** |
|
||||
| [Customize Secret Detection rulesets](#custom-rulesets) | **{dotted-circle}** | **{check-circle}** |
|
||||
- [Enable Secret Detection by including the template](#enable-secret-detection-by-including-the-template).
|
||||
|
||||
## Configuration
|
||||
- [Enable Secret Detection using a merge request](#enable-secret-detection-using-a-merge-request).
|
||||
|
||||
> - In GitLab 13.1, Secret Detection was split from the [SAST configuration](../sast#configuration) into its own CI/CD template. If you're using GitLab 13.0 or earlier and SAST is enabled, then Secret Detection is already enabled.
|
||||
> - [In GitLab 14.0](https://gitlab.com/gitlab-org/gitlab/-/issues/297269), Secret Detection jobs `secret_detection_default_branch` and `secret_detection` were consolidated into one job, `secret_detection`.
|
||||
### Enable Secret Detection by including the template
|
||||
|
||||
Secret Detection is performed by a [specific analyzer](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/Secret-Detection.gitlab-ci.yml)
|
||||
during the `secret-detection` job. It runs regardless of your app's programming language.
|
||||
We recommend this method if you have an existing GitLab CI/CD configuration file.
|
||||
|
||||
The Secret Detection analyzer includes [Gitleaks](https://github.com/zricethezav/gitleaks) checks.
|
||||
|
||||
Note that the Secret Detection analyzer ignores Password-in-URL vulnerabilities if the password
|
||||
begins with a dollar sign (`$`), as this likely indicates the password is an environment variable.
|
||||
For example, `https://username:$password@example.com/path/to/repo` isn't detected, while
|
||||
`https://username:password@example.com/path/to/repo` is.
|
||||
|
||||
NOTE:
|
||||
You don't have to configure Secret Detection manually as shown in this section if you're using
|
||||
[Auto Secret Detection](../../../topics/autodevops/stages.md#auto-secret-detection),
|
||||
provided by [Auto DevOps](../../../topics/autodevops/index.md).
|
||||
|
||||
To enable Secret Detection for GitLab 13.1 and later, you must include the
|
||||
`Secret-Detection.gitlab-ci.yml` template that's provided as a part of your GitLab installation. For
|
||||
GitLab versions earlier than 11.9, you can copy and use the job as defined in that template.
|
||||
|
||||
Ensure your `.gitlab-ci.yml` file has a `stage` called `test`, and add the following to your `.gitlab-ci.yml` file:
|
||||
Add the following extract to your `.gitlab-ci.yml` file:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
```
|
||||
|
||||
The included template creates Secret Detection jobs in your CI/CD pipeline and scans
|
||||
your project's source code for secrets.
|
||||
Pipelines now include a Secret Detection job, and the results are included in the merge request
|
||||
widget.
|
||||
|
||||
The results are saved as a
|
||||
[Secret Detection report artifact](../../../ci/yaml/artifacts_reports.md#artifactsreportssecret_detection)
|
||||
that you can later download and analyze. Due to implementation limitations, we
|
||||
always take the latest Secret Detection artifact available.
|
||||
### Enable Secret Detection using a merge request
|
||||
|
||||
### Supported distributions
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4496) in GitLab 13.11, deployed behind a feature flag, enabled by default.
|
||||
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/329886) in GitLab 14.1.
|
||||
|
||||
The default scanner images are build off a base Alpine image for size and maintainability.
|
||||
NOTE:
|
||||
This method works best with no existing `.gitlab-ci.yml` file, or with a minimal configuration
|
||||
file. If you have a complex GitLab configuration file it may not be parsed successfully, and an
|
||||
error may occur.
|
||||
|
||||
#### FIPS-enabled images
|
||||
To enable Secret Detection using a merge request:
|
||||
|
||||
1. On the top bar, select **Menu > Projects** and find your project.
|
||||
1. On the left sidebar, select **Security & Compliance > Configuration**.
|
||||
1. In the **Secret Detection** row, select **Configure with a merge request**.
|
||||
1. Review and merge the merge request.
|
||||
|
||||
Pipelines now include a Secret Detection job, and the results are included in the merge request
|
||||
widget.
|
||||
|
||||
## Configure scan settings
|
||||
|
||||
The Secret Detection scan settings can be changed through [CI/CD variables](#available-cicd-variables)
|
||||
by using the [`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
|
||||
|
||||
WARNING:
|
||||
All configuration of GitLab security scanning tools should be tested in a merge request before
|
||||
merging these changes to the default branch. Failure to do so can give unexpected results,
|
||||
including a large number of false positives.
|
||||
|
||||
To override a job definition, (for example, change properties like `variables` or `dependencies`),
|
||||
declare a job with the same name as the secret detection job to override. Place this new job after
|
||||
the template inclusion and specify any additional keys under it.
|
||||
|
||||
In the following example _extract_ of a `.gitlab-ci.yml` file:
|
||||
|
||||
- The Secret Detection template is [included](../../../ci/yaml/index.md#include).
|
||||
- In the `secret_detection` job, the CI/CD variable `SECRET_DETECTION_HISTORIC_SCAN` is set to
|
||||
`true`. Because the template is evaluated before the pipeline configuration, the last mention of
|
||||
the variable takes precedence.
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
|
||||
secret_detection:
|
||||
variables:
|
||||
SECRET_DETECTION_HISTORIC_SCAN: "true"
|
||||
```
|
||||
|
||||
### Available CI/CD variables
|
||||
|
||||
Secret Detection can be customized by defining available CI/CD variables:
|
||||
|
||||
| CI/CD variable | Default value | Description |
|
||||
|-----------------------------------|---------------|-------------|
|
||||
| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
|
||||
| `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
|
||||
| `SECRET_DETECTION_IMAGE_SUFFIX` | "" | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [Use FIPS-enabled images](#use-fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. |
|
||||
| `SECRET_DETECTION_LOG_OPTIONS` | "" | [`git log`](https://git-scm.com/docs/git-log) options used to define commit ranges. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350660) in GitLab 15.1.|
|
||||
|
||||
In previous GitLab versions, the following variables were also available:
|
||||
|
||||
| CI/CD variable | Default value | Description |
|
||||
|-----------------------------------|---------------|-------------|
|
||||
| `SECRET_DETECTION_COMMIT_FROM` | - | The commit a Gitleaks scan starts at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
|
||||
| `SECRET_DETECTION_COMMIT_TO` | - | The commit a Gitleaks scan ends at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
|
||||
| `SECRET_DETECTION_COMMITS` | - | The list of commits that Gitleaks should scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/352565) in GitLab 15.0. |
|
||||
|
||||
#### Use FIPS-enabled images
|
||||
|
||||
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6479) in GitLab 14.10.
|
||||
|
||||
GitLab offers [Red Hat UBI](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image)
|
||||
versions of the images that are FIPS-enabled. To use the FIPS-enabled images, you can either:
|
||||
The default scanner images are built off a base Alpine image for size and maintainability. GitLab
|
||||
offers [Red Hat UBI](https://www.redhat.com/en/blog/introducing-red-hat-universal-base-image)
|
||||
versions of the images that are FIPS-enabled.
|
||||
|
||||
- Set the `SAST_IMAGE_SUFFIX` to `-fips`.
|
||||
To use the FIPS-enabled images, either:
|
||||
|
||||
- Set the `SECRET_DETECTION_IMAGE_SUFFIX` CI/CD variable to `-fips`.
|
||||
- Add the `-fips` extension to the default image name.
|
||||
|
||||
For example:
|
||||
|
|
@ -132,124 +192,54 @@ include:
|
|||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
```
|
||||
|
||||
### Enable Secret Detection via an automatic merge request
|
||||
## Full history Secret Detection
|
||||
|
||||
> - [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/4496) in GitLab 13.11, deployed behind a feature flag, enabled by default.
|
||||
> - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/329886) in GitLab 14.1.
|
||||
By default, Secret Detection scans only the current state of the Git repository. Any secrets
|
||||
contained in the repository's history are not detected. To address this, Secret Detection can
|
||||
scan the Git repository's full history.
|
||||
|
||||
NOTE:
|
||||
This method works best with no existing `.gitlab-ci.yml` file, or with a minimal configuration
|
||||
file. If you have a complex GitLab configuration file it may not be parsed successfully, and an
|
||||
error may occur.
|
||||
We recommend you do a full history scan only once, after enabling Secret Detection. A full history
|
||||
can take a long time, especially for larger repositories with lengthy Git histories. After
|
||||
completing an initial full history scan, use only standard Secret Detection as part of your
|
||||
pipeline.
|
||||
|
||||
To enable Secret Detection in a project, you can create a merge request:
|
||||
### Enable full history Secret Detection
|
||||
|
||||
1. On the top bar, select **Menu > Projects** and find your project.
|
||||
1. On the left sidebar, select **Security & Compliance > Configuration**.
|
||||
1. In the **Secret Detection** row, select **Configure with a merge request**.
|
||||
1. Review and merge the merge request to enable Secret Detection.
|
||||
To enable full history Secret Detection, set the variable `SECRET_DETECTION_HISTORIC_SCAN` to `true` in your `.gitlab-ci.yml` file.
|
||||
|
||||
Pipelines now include a Secret Detection job.
|
||||
|
||||
### Customizing settings
|
||||
|
||||
The Secret Detection scan settings can be changed through [CI/CD variables](#available-cicd-variables)
|
||||
by using the
|
||||
[`variables`](../../../ci/yaml/index.md#variables) parameter in `.gitlab-ci.yml`.
|
||||
|
||||
WARNING:
|
||||
All customization of GitLab security scanning tools should be tested in a merge request before
|
||||
merging these changes to the default branch. Failure to do so can give unexpected results,
|
||||
including a large number of false positives.
|
||||
|
||||
To override a job definition, (for example, change properties like `variables` or `dependencies`),
|
||||
declare a job with the same name as the secret detection job to override. Place this new job after the template
|
||||
inclusion and specify any additional keys under it.
|
||||
|
||||
WARNING:
|
||||
Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/index.md#only--except)
|
||||
is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/index.md#rules) instead.
|
||||
|
||||
#### `GIT_DEPTH` variable
|
||||
|
||||
The [`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning) affects Secret Detection.
|
||||
The Secret Detection analyzer relies on generating patches between commits to scan content for
|
||||
secrets. If you override the default, ensure the value is greater than 1. If the number of commits
|
||||
in an MR is greater than the `GIT_DEPTH` value, Secret Detection will [fail to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
|
||||
|
||||
#### Custom settings example
|
||||
|
||||
In the following example, we include the Secret Detection template and at the same time we
|
||||
override the `secret_detection` job with the `SECRET_DETECTION_HISTORIC_SCAN` CI/CD variable to `true`:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
|
||||
secret_detection:
|
||||
variables:
|
||||
SECRET_DETECTION_HISTORIC_SCAN: "true"
|
||||
```
|
||||
|
||||
Because the template is [evaluated before](../../../ci/yaml/index.md#include)
|
||||
the pipeline configuration, the last mention of the variable takes precedence.
|
||||
|
||||
#### Available CI/CD variables
|
||||
|
||||
Secret Detection can be customized by defining available CI/CD variables:
|
||||
|
||||
| CI/CD variable | Default value | Description |
|
||||
|-----------------------------------|---------------|-------------|
|
||||
| `SECRET_DETECTION_EXCLUDED_PATHS` | "" | Exclude vulnerabilities from output based on the paths. This is a comma-separated list of patterns. Patterns can be globs (see [`doublestar.Match`](https://pkg.go.dev/github.com/bmatcuk/doublestar/v4@v4.0.2#Match) for supported patterns), or file or folder paths (for example, `doc,spec` ). Parent directories also match patterns. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/225273) in GitLab 13.3. |
|
||||
| `SECRET_DETECTION_HISTORIC_SCAN` | false | Flag to enable a historic Gitleaks scan. |
|
||||
| `SECRET_DETECTION_IMAGE_SUFFIX` | "" | Suffix added to the image name. If set to `-fips`, `FIPS-enabled` images are used for scan. See [FIPS-enabled images](#fips-enabled-images) for more details. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/355519) in GitLab 14.10. |
|
||||
| `SECRET_DETECTION_LOG_OPTIONS` | "" | [`git log`](https://git-scm.com/docs/git-log) options used to define commit ranges. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/350660) in GitLab 15.1.|
|
||||
|
||||
In previous GitLab versions, the following variables were also available:
|
||||
|
||||
| CI/CD variable | Default value | Description |
|
||||
|-----------------------------------|---------------|-------------|
|
||||
| `SECRET_DETECTION_COMMIT_FROM` | - | The commit a Gitleaks scan starts at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
|
||||
| `SECRET_DETECTION_COMMIT_TO` | - | The commit a Gitleaks scan ends at. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. Replaced with `SECRET_DETECTION_COMMITS`. |
|
||||
| `SECRET_DETECTION_COMMITS` | - | The list of commits that Gitleaks should scan. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/243564) in GitLab 13.5. [Removed](https://gitlab.com/gitlab-org/gitlab/-/issues/352565) in GitLab 15.0. |
|
||||
|
||||
### Custom rulesets **(ULTIMATE)**
|
||||
## Custom rulesets **(ULTIMATE)**
|
||||
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/211387) in GitLab 13.5.
|
||||
> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/339614) support for
|
||||
> passthrough chains. Expanded to include additional passthrough types of `file`, `git`, and `url` in GitLab 14.6.
|
||||
> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in GitLab 14.8.
|
||||
> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/339614) support for passthrough chains.
|
||||
> Expanded to include additional passthrough types of `file`, `git`, and `url` in GitLab 14.6.
|
||||
> - [Added](https://gitlab.com/gitlab-org/gitlab/-/issues/235359) support for overriding rules in
|
||||
> GitLab 14.8.
|
||||
|
||||
You can customize the default secret detection rules provided with GitLab.
|
||||
Ruleset customization supports the following capabilities that can be used
|
||||
simultaneously:
|
||||
You can customize the default Secret Detection rules provided with GitLab.
|
||||
|
||||
- [Disabling predefined rules](#disable-predefined-analyzer-rules).
|
||||
- [Overriding predefined rules](#override-predefined-analyzer-rules).
|
||||
- Modifying the default behavior of the Secret Detection analyzer by [synthesizing and passing a custom configuration](#synthesize-a-custom-configuration).
|
||||
The following customization options can be used separately, or in combination:
|
||||
|
||||
Customization allows replacing the default secret detection rules with rules that you define.
|
||||
- [Disable predefined rules](#disable-predefined-analyzer-rules).
|
||||
- [Override predefined rules](#override-predefined-analyzer-rules).
|
||||
- [Synthesize a custom configuration](#synthesize-a-custom-configuration).
|
||||
|
||||
To create a custom ruleset:
|
||||
### Disable predefined analyzer rules
|
||||
|
||||
1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
|
||||
1. Create a custom ruleset file named `secret-detection-ruleset.toml` in the `.gitlab` directory.
|
||||
|
||||
#### Disable predefined analyzer rules
|
||||
If there are specific Secret Detection rules that you don't want active, you can disable them.
|
||||
|
||||
To disable analyzer rules:
|
||||
|
||||
1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
|
||||
1. Create a custom ruleset file named `secret-detection-ruleset.toml` in the `.gitlab` directory, if
|
||||
one doesn't already exist.
|
||||
1. Set the `disabled` flag to `true` in the context of a `ruleset` section.
|
||||
1. In one or more `ruleset.identifier` subsections, list the rules to disable. Every
|
||||
`ruleset.identifier` section has:
|
||||
- A `type` field for the predefined rule identifier.
|
||||
- A `value` field for the rule name.
|
||||
|
||||
1. In one or more `ruleset.identifier` subsections, list the rules that you want disabled. Every `ruleset.identifier` section has:
|
||||
|
||||
- a `type` field, to name the predefined rule identifier.
|
||||
- a `value` field, to name the rule to be disabled.
|
||||
|
||||
##### Example: Disable predefined rules of Secret Detection analyzer
|
||||
|
||||
In the following example, the disabled rules is assigned to `secrets`
|
||||
by matching the `type` and `value` of identifiers:
|
||||
In the following example `secret-detection-ruleset.toml` file, the disabled rules are assigned to
|
||||
`secrets` by matching the `type` and `value` of identifiers:
|
||||
|
||||
```toml
|
||||
[secrets]
|
||||
|
|
@ -260,29 +250,30 @@ by matching the `type` and `value` of identifiers:
|
|||
value = "RSA private key"
|
||||
```
|
||||
|
||||
#### Override predefined analyzer rules
|
||||
### Override predefined analyzer rules
|
||||
|
||||
If there are specific Secret Detection rules you want to customize, you can override them. For
|
||||
example, you might increase the severity of specific secrets.
|
||||
|
||||
To override rules:
|
||||
|
||||
1. In one or more `ruleset.identifier` subsections, list the rules that you want to override. Every `ruleset.identifier` section has:
|
||||
|
||||
- a `type` field, to name the predefined rule identifier that the Secret Detection analyzer uses.
|
||||
- a `value` field, to name the rule to be overridden.
|
||||
|
||||
1. Create a `.gitlab` directory at the root of your project, if one doesn't already exist.
|
||||
1. Create a custom ruleset file named `secret-detection-ruleset.toml` in the `.gitlab` directory, if
|
||||
one doesn't already exist.
|
||||
1. In one or more `ruleset.identifier` subsections, list the rules to override. Every
|
||||
`ruleset.identifier` section has:
|
||||
- A `type` field for the predefined rule identifier.
|
||||
- A `value` field for the rule name.
|
||||
1. In the `ruleset.override` context of a `ruleset` section,
|
||||
provide the keys to override. Any combination of keys can be
|
||||
overridden. Valid keys are:
|
||||
|
||||
- description
|
||||
- message
|
||||
- name
|
||||
- severity (valid options are: Critical, High, Medium, Low, Unknown, Info)
|
||||
|
||||
##### Example: Override predefined rules of Secret Detection analyzer
|
||||
|
||||
In the following example, rules
|
||||
are matched by the `type` and `value` of identifiers and
|
||||
then overridden:
|
||||
In the following example `secret-detection-ruleset.toml` file, rules are matched by the `type` and
|
||||
`value` of identifiers and then overridden:
|
||||
|
||||
```toml
|
||||
[secrets]
|
||||
|
|
@ -297,166 +288,157 @@ then overridden:
|
|||
severity = "Info"
|
||||
```
|
||||
|
||||
#### Synthesize a custom configuration
|
||||
### Synthesize a custom configuration
|
||||
|
||||
To create a custom configuration, you can use passthrough chains.
|
||||
To create a custom configuration, you can use passthrough chains. Passthroughs can also be chained
|
||||
to build more complex configurations. For more details, see
|
||||
[SAST Customize ruleset](../sast/customize_rulesets.md).
|
||||
|
||||
1. In the `secret-detection-ruleset.toml` file, do one of the following:
|
||||
In the `secret-detection-ruleset.toml` file, do one of the following:
|
||||
|
||||
- Define a custom ruleset:
|
||||
- Define a custom ruleset, for example:
|
||||
|
||||
```toml
|
||||
[secrets]
|
||||
description = 'secrets custom rules configuration'
|
||||
```toml
|
||||
[secrets]
|
||||
description = 'secrets custom rules configuration'
|
||||
|
||||
[[secrets.passthrough]]
|
||||
type = "raw"
|
||||
target = "gitleaks.toml"
|
||||
value = """\
|
||||
title = "gitleaks config"
|
||||
# add regexes to the regex table
|
||||
[[rules]]
|
||||
description = "Test for Raw Custom Rulesets"
|
||||
regex = '''Custom Raw Ruleset T[est]{3}'''
|
||||
"""
|
||||
```
|
||||
[[secrets.passthrough]]
|
||||
type = "raw"
|
||||
target = "gitleaks.toml"
|
||||
value = """\
|
||||
title = "gitleaks config"
|
||||
# add regexes to the regex table
|
||||
[[rules]]
|
||||
description = "Test for Raw Custom Rulesets"
|
||||
regex = '''Custom Raw Ruleset T[est]{3}'''
|
||||
"""
|
||||
```
|
||||
|
||||
- Provide the name of the file containing a custom ruleset:
|
||||
- Provide the name of the file containing a custom ruleset, for example:
|
||||
|
||||
```toml
|
||||
[secrets]
|
||||
description = 'secrets custom rules configuration'
|
||||
```toml
|
||||
[secrets]
|
||||
description = 'secrets custom rules configuration'
|
||||
|
||||
[[secrets.passthrough]]
|
||||
type = "file"
|
||||
target = "gitleaks.toml"
|
||||
value = "config/gitleaks.toml"
|
||||
```
|
||||
[[secrets.passthrough]]
|
||||
type = "file"
|
||||
target = "gitleaks.toml"
|
||||
value = "config/gitleaks.toml"
|
||||
```
|
||||
|
||||
Passthroughs can also be chained to build more complex configurations.
|
||||
For more details, see [SAST Customize ruleset section](../sast/customize_rulesets.md).
|
||||
|
||||
### Logging level
|
||||
|
||||
To control the verbosity of logs set the `SECURE_LOG_LEVEL` CI/CD variable. Messages of this logging level or higher are output. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
|
||||
|
||||
From highest to lowest severity, the logging levels are:
|
||||
|
||||
- `fatal`
|
||||
- `error`
|
||||
- `warn`
|
||||
- `info` (default)
|
||||
- `debug`
|
||||
|
||||
## Post-processing and revocation
|
||||
|
||||
Upon detection of a secret, GitLab SaaS supports post-processing hooks.
|
||||
For more information, see [Post-processing and revocation](post_processing.md).
|
||||
|
||||
## Full History Secret Detection
|
||||
|
||||
GitLab 12.11 introduced support for scanning the full history of a repository. This new functionality
|
||||
is particularly useful when you are enabling Secret Detection in a repository for the first time and you
|
||||
want to perform a full secret detection scan. Running a secret detection scan on the full history can take a long time,
|
||||
especially for larger repositories with lengthy Git histories. We recommend not setting this CI/CD variable
|
||||
as part of your normal job definition.
|
||||
|
||||
A new configuration variable ([`SECRET_DETECTION_HISTORIC_SCAN`](#available-cicd-variables))
|
||||
can be set to change the behavior of the GitLab Secret Detection scan to run on the entire Git history of a repository.
|
||||
|
||||
## Running Secret Detection in an offline environment
|
||||
## Running Secret Detection in an offline environment **(PREMIUM SELF)**
|
||||
|
||||
For self-managed GitLab instances in an environment with limited, restricted, or intermittent access
|
||||
to external resources through the internet, some adjustments are required for the Secret Detection job to
|
||||
run successfully. For more information, see [Offline environments](../offline_deployments/index.md).
|
||||
to external resources through the internet, some configuration changes are required for the Secret
|
||||
Detection job to run successfully. The instructions in this section must be completed together with
|
||||
the instructions detailed in [offline environments](../offline_deployments/index.md).
|
||||
|
||||
### Requirements for offline Secret Detection
|
||||
### Configure GitLab Runner
|
||||
|
||||
To use Secret Detection in an offline environment, you need:
|
||||
By default, a runner tries to pull Docker images from the GitLab container registry even if a local
|
||||
copy is available. We recommend using this default setting, to ensure Docker images remain current.
|
||||
However, if no network connectivity is available, you must change the default GitLab Runner
|
||||
`pull_policy` variable.
|
||||
|
||||
- GitLab Runner with the [`docker` or `kubernetes` executor](#requirements).
|
||||
- A Docker Container Registry with locally available copy of Secret Detection [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers) images.
|
||||
- Configure certificate checking of packages (optional).
|
||||
Configure the GitLab Runner CI/CD variable `pull_policy` to
|
||||
[`if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy).
|
||||
|
||||
GitLab Runner has a [default `pull policy` of `always`](https://docs.gitlab.com/runner/executors/docker.html#using-the-always-pull-policy),
|
||||
meaning the runner tries to pull Docker images from the GitLab container registry even if a local
|
||||
copy is available. The GitLab Runner [`pull_policy` can be set to `if-not-present`](https://docs.gitlab.com/runner/executors/docker.html#using-the-if-not-present-pull-policy)
|
||||
in an offline environment if you prefer using only locally available Docker images. However, we
|
||||
recommend keeping the pull policy setting to `always` if not in an offline environment, as this
|
||||
enables the use of updated scanners in your CI/CD pipelines.
|
||||
### Use local Secret Detection analyzer image
|
||||
|
||||
### Make GitLab Secret Detection analyzer image available inside your Docker registry
|
||||
Use a local Secret Detection analyzer image if you want to obtain the image from a local Docker
|
||||
registry instead of the GitLab container registry.
|
||||
|
||||
Import the following default Secret Detection analyzer images from `registry.gitlab.com` into your
|
||||
[local Docker container registry](../../packages/container_registry/index.md):
|
||||
Prerequisites:
|
||||
|
||||
```plaintext
|
||||
registry.gitlab.com/security-products/secret-detection:3
|
||||
```
|
||||
- Importing Docker images into a local offline Docker registry depends on your
|
||||
network security policy. Consult your IT staff to find an accepted and approved process
|
||||
to import or temporarily access external resources.
|
||||
|
||||
The process for importing Docker images into a local offline Docker registry depends on
|
||||
**your network security policy**. Please consult your IT staff to find an accepted and approved
|
||||
process by which external resources can be imported or temporarily accessed. These scanners are [periodically updated](../index.md#vulnerability-scanner-maintenance)
|
||||
with new definitions, and you may be able to make occasional updates on your own.
|
||||
1. Import the default Secret Detection analyzer image from `registry.gitlab.com` into your
|
||||
[local Docker container registry](../../packages/container_registry/index.md):
|
||||
|
||||
For details on saving and transporting Docker images as a file, see Docker's documentation on
|
||||
[`docker save`](https://docs.docker.com/engine/reference/commandline/save/), [`docker load`](https://docs.docker.com/engine/reference/commandline/load/),
|
||||
[`docker export`](https://docs.docker.com/engine/reference/commandline/export/), and [`docker import`](https://docs.docker.com/engine/reference/commandline/import/).
|
||||
```plaintext
|
||||
registry.gitlab.com/security-products/secret-detection:3
|
||||
```
|
||||
|
||||
### Set Secret Detection CI/CD variables to use the local Secret Detection analyzer container image
|
||||
The Secret Detection analyzer's image is [periodically updated](../index.md#vulnerability-scanner-maintenance)
|
||||
so you may need to periodically update the local copy.
|
||||
|
||||
Add the following configuration to your `.gitlab-ci.yml` file. You must replace
|
||||
`SECURE_ANALYZERS_PREFIX` to refer to your local Docker container registry:
|
||||
1. Set the CI/CD variable `SECURE_ANALYZERS_PREFIX` to the local Docker container registry.
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
```yaml
|
||||
include:
|
||||
- template: Security/Secret-Detection.gitlab-ci.yml
|
||||
|
||||
variables:
|
||||
SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"
|
||||
```
|
||||
variables:
|
||||
SECURE_ANALYZERS_PREFIX: "localhost:5000/analyzers"
|
||||
```
|
||||
|
||||
The Secret Detection job should now use the local copy of the Secret Detection analyzer Docker image to scan your code and generate
|
||||
security reports without requiring internet access.
|
||||
The Secret Detection job should now use the local copy of the Secret Detection analyzer Docker
|
||||
image, without requiring internet access.
|
||||
|
||||
#### If support for Custom Certificate Authorities are needed
|
||||
|
||||
Support for custom certificate authorities was introduced in the following versions.
|
||||
|
||||
| Analyzer | Version |
|
||||
| -------- | ------- |
|
||||
| secrets | [v3.0.0](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/releases/v3.0.0) |
|
||||
### Configure a custom Certificate Authority
|
||||
|
||||
To trust a custom Certificate Authority, set the `ADDITIONAL_CA_CERT_BUNDLE` variable to the bundle
|
||||
of CA certs that you want to trust in the SAST environment. The `ADDITIONAL_CA_CERT_BUNDLE` value should contain the [text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1). For example, to configure this value in the `.gitlab-ci.yml` file, use the following:
|
||||
of CA certificates that you trust. Do this either in the `.gitlab-ci.yml` file, in a file
|
||||
variable, or as a CI/CD variable.
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
ADDITIONAL_CA_CERT_BUNDLE: |
|
||||
-----BEGIN CERTIFICATE-----
|
||||
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
|
||||
...
|
||||
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
- In the `.gitlab-ci.yml` file, the `ADDITIONAL_CA_CERT_BUNDLE` value must contain the
|
||||
[text representation of the X.509 PEM public-key certificate](https://tools.ietf.org/html/rfc7468#section-5.1).
|
||||
|
||||
The `ADDITIONAL_CA_CERT_BUNDLE` value can also be configured as a [custom variable in the UI](../../../ci/variables/index.md#custom-cicd-variables), either as a `file`, which requires the path to the certificate, or as a variable, which requires the text representation of the certificate.
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
variables:
|
||||
ADDITIONAL_CA_CERT_BUNDLE: |
|
||||
-----BEGIN CERTIFICATE-----
|
||||
MIIGqTCCBJGgAwIBAgIQI7AVxxVwg2kch4d56XNdDjANBgkqhkiG9w0BAQsFADCB
|
||||
...
|
||||
jWgmPqF3vUbZE0EyScetPJquRFRKIesyJuBFMAs=
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
- If using a file variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the path to the
|
||||
certificate.
|
||||
|
||||
- If using a variable, set the value of `ADDITIONAL_CA_CERT_BUNDLE` to the text
|
||||
representation of the certificate.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Getting warning message `gl-secret-detection-report.json: no matching files`
|
||||
### Set the logging level
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1.
|
||||
|
||||
Set the logging level to `debug` when you need diagnostic information in a Secret Detection job log.
|
||||
|
||||
WARNING:
|
||||
Debug logging can be a serious security risk. The output may contain the content of environment
|
||||
variables and other secrets available to the job. The output is uploaded to the GitLab server and
|
||||
visible in job logs.
|
||||
|
||||
1. In the `.gitlab-ci.yml` file, set the `SECURE_LOG_LEVEL` CI/CD variable to `debug`.
|
||||
1. Run the Secret Detection job.
|
||||
1. Analyze the content of the Secret Detection job.
|
||||
1. In the `.gitlab-ci.yml` file, set the `SECURE_LOG_LEVEL` CI/CD variable to `info` (default).
|
||||
|
||||
### Warning: `gl-secret-detection-report.json: no matching files`
|
||||
|
||||
For information on this, see the [general Application Security troubleshooting section](../../../ci/pipelines/job_artifacts.md#error-message-no-files-to-upload).
|
||||
|
||||
### Error: `Couldn't run the gitleaks command: exit status 2`
|
||||
|
||||
If a pipeline is triggered from a merge request containing 60 commits while the `GIT_DEPTH` variable's
|
||||
value is less than that, the Secret Detection job fails as the clone is not deep enough to contain all of the
|
||||
relevant commits. For information on the current default value, see the
|
||||
[pipeline configuration documentation](../../../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone).
|
||||
The Secret Detection analyzer relies on generating patches between commits to scan content for
|
||||
secrets. If the number of commits in a merge request is greater than the value of the
|
||||
[`GIT_DEPTH` CI/CD variable](../../../ci/runners/configure_runners.md#shallow-cloning), Secret
|
||||
Detection [fails to detect secrets](#error-couldnt-run-the-gitleaks-command-exit-status-2).
|
||||
|
||||
To confirm this as the cause of the error, set the
|
||||
[logging level](../../application_security/secret_detection/index.md#logging-level) to `debug`, then
|
||||
For example, if a pipeline is triggered from a merge request containing 60 commits and the
|
||||
`GIT_DEPTH` variable's value is less than 60, the Secret Detection job fails as the clone is not
|
||||
deep enough to contain all of the relevant commits. To veridy the current value, see
|
||||
[pipeline configuration](../../../ci/pipelines/settings.md#limit-the-number-of-changes-fetched-during-clone).
|
||||
|
||||
To confirm this as the cause of the error, set the [logging level](#set-the-logging-level) to `debug`, then
|
||||
rerun the pipeline. The logs should look similar to the following example. The text "object not
|
||||
found" is a symptom of this error.
|
||||
|
||||
|
|
@ -476,11 +458,12 @@ secret_detection:
|
|||
GIT_DEPTH: 100
|
||||
```
|
||||
|
||||
### `secret-detection` job fails with `ERR fatal: ambiguous argument` message
|
||||
### Error: `ERR fatal: ambiguous argument`
|
||||
|
||||
Your `secret-detection` job can fail with `ERR fatal: ambiguous argument` error if your
|
||||
repository's default branch is unrelated to the branch the job was triggered for.
|
||||
See issue [!352014](https://gitlab.com/gitlab-org/gitlab/-/issues/352014) for more details.
|
||||
Secret Detection can fail with the message `ERR fatal: ambiguous argument` error if your
|
||||
repository's default branch is unrelated to the branch the job was triggered for. See issue
|
||||
[!352014](https://gitlab.com/gitlab-org/gitlab/-/issues/352014) for more details.
|
||||
|
||||
To resolve the issue, make sure to correctly [set your default branch](../../project/repository/branches/default.md#change-the-default-branch-name-for-a-project) on your repository. You should set it to a branch
|
||||
that has related history with the branch you run the `secret-detection` job on.
|
||||
To resolve the issue, make sure to correctly [set your default branch](../../project/repository/branches/default.md#change-the-default-branch-name-for-a-project)
|
||||
on your repository. You should set it to a branch that has related history with the branch you run
|
||||
the `secret-detection` job on.
|
||||
|
|
|
|||
|
|
@ -31,20 +31,27 @@ If you are currently having an issue with GitLab, you may want to check your [su
|
|||
|
||||
## Azure Active Directory
|
||||
|
||||
Basic SAML app configuration:
|
||||
This section has screenshots for the elements of Azure Active Directory configuration.
|
||||
|
||||
### Basic SAML app configuration
|
||||
|
||||
|
||||
|
||||
User claims and attributes:
|
||||
### User claims and attributes
|
||||
|
||||
|
||||
|
||||
SCIM mapping:
|
||||
### SCIM mapping
|
||||
|
||||
Provisioning:
|
||||
|
||||
|
||||
|
||||
Attribute mapping:
|
||||
|
||||
|
||||
|
||||
Group Sync:
|
||||
### Group Sync
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB |
|
|
@ -122,7 +122,7 @@ prompts the user to sign in again through SSO.
|
|||
|
||||
An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/297389) to add a similar SSO requirement for API activity.
|
||||
|
||||
SSO has the following effects when enabled:
|
||||
SSO enforcement has the following effects when enabled:
|
||||
|
||||
- For groups, users can't share a project in the group outside the top-level group,
|
||||
even if the project is forked.
|
||||
|
|
@ -157,8 +157,8 @@ If you have any questions on configuring the SAML app, please contact your provi
|
|||
Follow the Azure documentation on [configuring single sign-on to applications](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal) with the notes below for consideration.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For a demo of the Azure SAML setup including SCIM, see [SCIM Provisioning on Azure Using SAML SSO for Groups Demo](https://youtu.be/24-ZxmTeEBU). The video is outdated in regard to
|
||||
objectID mapping and the [SCIM documentation should be followed](scim_setup.md#azure-configuration-steps).
|
||||
For a demo of the Azure SAML setup including SCIM, see [SCIM Provisioning on Azure Using SAML SSO for Groups Demo](https://youtu.be/24-ZxmTeEBU).
|
||||
The video is outdated in regard to objectID mapping and you should follow the [SCIM documentation](scim_setup.md#configure-azure-active-directory).
|
||||
|
||||
| GitLab Setting | Azure Field |
|
||||
| ------------------------------------ | ------------------------------------------ |
|
||||
|
|
@ -168,7 +168,7 @@ objectID mapping and the [SCIM documentation should be followed](scim_setup.md#a
|
|||
| Identity provider single sign-on URL | Login URL |
|
||||
| Certificate fingerprint | Thumbprint |
|
||||
|
||||
The recommended attributes and claims settings are:
|
||||
The recommended attributes are:
|
||||
|
||||
- **Unique User Identifier (Name identifier)** set to `user.objectID`.
|
||||
- **nameid-format** set to persistent.
|
||||
|
|
|
|||
|
|
@ -5,110 +5,129 @@ group: Authentication and Authorization
|
|||
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
|
||||
---
|
||||
|
||||
# SCIM provisioning using SAML SSO for GitLab.com groups **(PREMIUM SAAS)**
|
||||
# Configure SCIM for GitLab.com groups **(PREMIUM SAAS)**
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9388) in GitLab 11.10.
|
||||
|
||||
System for Cross-domain Identity Management (SCIM), is an open standard that enables the
|
||||
automation of user provisioning. When SCIM is provisioned for a GitLab group, membership of
|
||||
that group is synchronized between GitLab and the identity provider.
|
||||
You can use the open standard System for Cross-domain Identity Management (SCIM) to automatically:
|
||||
|
||||
- Create users.
|
||||
- Remove users (deactivate SCIM identity).
|
||||
|
||||
GitLab SAML SSO SCIM doesn't support updating users.
|
||||
|
||||
When SCIM is enabled for a GitLab group, membership of that group is synchronized between GitLab and an identity provider.
|
||||
|
||||
The GitLab [SCIM API](../../../api/scim.md) implements part of [the RFC7644 protocol](https://tools.ietf.org/html/rfc7644).
|
||||
|
||||
## Features
|
||||
## Configure GitLab
|
||||
|
||||
The following actions are available:
|
||||
Prerequisites:
|
||||
|
||||
- Create users
|
||||
- Remove users (deactivate SCIM identity)
|
||||
- [Group single sign-on](index.md) must be configured.
|
||||
|
||||
The following identity providers are supported:
|
||||
|
||||
- Azure
|
||||
- Okta
|
||||
|
||||
NOTE:
|
||||
Other providers can work with GitLab but they have not been tested and are not supported.
|
||||
|
||||
## Requirements
|
||||
|
||||
- [Group Single Sign-On](index.md) must be configured.
|
||||
|
||||
## GitLab configuration
|
||||
|
||||
Once [Group Single Sign-On](index.md) has been configured, we can:
|
||||
To configure GitLab SAML SSO SCIM:
|
||||
|
||||
1. On the top bar, select **Menu > Groups** and find your group.
|
||||
1. On the left sidebar, select **Settings > SAML SSO**.
|
||||
1. Select **Generate a SCIM token**.
|
||||
1. Save the token and URL for use in the next step.
|
||||
1. For configuration of your identity provider, save the:
|
||||
- Token from the **Your SCIM token** field.
|
||||
- URL from the **SCIM API endpoint URL** field.
|
||||
|
||||
|
||||
## Configure an identity provider
|
||||
|
||||
## Identity Provider configuration
|
||||
You can configure one of the following as an identity provider:
|
||||
|
||||
- [Azure](#azure-configuration-steps)
|
||||
- [Okta](#okta-configuration-steps)
|
||||
- [Azure Active Directory](#configure-azure-active-directory).
|
||||
- [Okta](#configure-okta).
|
||||
- [OneLogin](#configure-onelogin).
|
||||
|
||||
### Azure configuration steps
|
||||
NOTE:
|
||||
Other providers can work with GitLab but they have not been tested and are not supported.
|
||||
|
||||
The SAML application that was created during [Single sign-on](index.md) setup for [Azure](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal) now needs to be set up for SCIM. You can refer to [Azure SCIM setup documentation](https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/use-scim-to-provision-users-and-groups#getting-started).
|
||||
### Configure Azure Active Directory
|
||||
|
||||
1. In your app, go to the Provisioning tab, and set the **Provisioning Mode** to **Automatic**.
|
||||
Then fill in the **Admin Credentials**, and save. The **Tenant URL** and **secret token** are the items
|
||||
retrieved in the [previous step](#gitlab-configuration).
|
||||
The SAML application created during [single sign-on](index.md) set up for
|
||||
[Azure Active Directory](https://docs.microsoft.com/en-us/azure/active-directory/manage-apps/view-applications-portal)
|
||||
must be set up for SCIM. For an example, see [example configuration](example_saml_config.md#scim-mapping).
|
||||
|
||||
1. After saving, two more tabs appear:
|
||||
To configure Azure Active Directory for SCIM:
|
||||
|
||||
- **Settings**: We recommend setting a notification email and selecting the **Send an email notification when a failure occurs** checkbox.
|
||||
You also control what is actually synced by selecting the **Scope**. For example, **Sync only assigned users and groups** only syncs the users and groups assigned to the application. Otherwise, it syncs the whole Active Directory.
|
||||
1. In your app, go to the **Provisioning** tab and select **Get started**.
|
||||
1. Set the **Provisioning Mode** to **Automatic**.
|
||||
1. Complete the **Admin Credentials** using the value of:
|
||||
- **SCIM API endpoint URL** in GitLab for the **Tenant URL** field.
|
||||
- **Your SCIM token** in GitLab for the **Secret Token** field.
|
||||
1. Select **Test Connection**. If the test is successful, save your configuration before continuing, or see the
|
||||
[troubleshooting](#troubleshooting) information.
|
||||
1. Select **Save**.
|
||||
|
||||
- **Mappings**: We recommend keeping **Provision Azure Active Directory Users** enabled, and disable **Provision Azure Active Directory Groups**.
|
||||
Leaving **Provision Azure Active Directory Groups** enabled does not break the SCIM user provisioning, but it causes errors in Azure AD that may be confusing and misleading.
|
||||
After saving, **Settings** and **Mappings** sections appear.
|
||||
|
||||
1. You can then test the connection by selecting **Test Connection**. If the connection is successful, save your configuration before moving on. See below for [troubleshooting](#troubleshooting).
|
||||
|
||||
#### Configure attribute mapping
|
||||
|
||||
Follow [Azure documentation to configure the attribute mapping](https://docs.microsoft.com/en-us/azure/active-directory/app-provisioning/customize-application-attributes).
|
||||
|
||||
The following table below provides an attribute mapping known to work with GitLab. If
|
||||
your SAML configuration differs from [the recommended SAML settings](index.md#azure-setup-notes),
|
||||
modify the corresponding `customappsso` settings accordingly. In particular, the `externalId` must
|
||||
match the [SAML NameID](index.md#nameid).
|
||||
If a mapping is not listed in the table, use the Azure defaults.
|
||||
For a list of required attributes, refer to the [SCIM API documentation](../../../api/scim.md).
|
||||
|
||||
| Azure Active Directory Attribute | `customappsso` Attribute | Matching precedence |
|
||||
| -------------------------------- | ------------------------------ | ------------------- |
|
||||
| `objectId` | `externalId` | 1 |
|
||||
| `userPrincipalName` | `emails[type eq "work"].value` | |
|
||||
| `mailNickname` | `userName` | |
|
||||
|
||||
For guidance, you can view [an example configuration](example_saml_config.md#azure-active-directory).
|
||||
|
||||
1. Below the mapping list select **Show advanced options > Edit attribute list for AppName**.
|
||||
1. Ensure the `id` is the primary and required field, and `externalId` is also required.
|
||||
|
||||
NOTE:
|
||||
`username` should neither be primary nor required as we don't support
|
||||
that field on GitLab SCIM yet.
|
||||
|
||||
1. Save all changes.
|
||||
1. In the **Provisioning** step, set the `Provisioning Status` to `On`.
|
||||
|
||||
Once enabled, the synchronization details and any errors appears on the
|
||||
bottom of the **Provisioning** screen, together with a link to the audit events.
|
||||
1. Under **Settings**, if required, set a notification email and select the
|
||||
**Send an email notification when a failure occurs** checkbox.
|
||||
1. Under **Mappings**, we recommend you:
|
||||
1. Keep **Provision Azure Active Directory Users** enabled and select the **Provision Azure Active Directory Users**
|
||||
link to [configure attribute mappings](#configure-attribute-mappings).
|
||||
1. Below the mapping list select the **Show advanced options** checkbox.
|
||||
1. Select the **Edit attribute list for customappsso** link.
|
||||
1. Ensure the `id` is the primary and required field, and `externalId` is also required.
|
||||
1. Select **Save**.
|
||||
1. Return to the **Provisioning** tab, saving unsaved changes if necessary.
|
||||
1. Select **Edit attribute mappings**.
|
||||
1. Under **Mappings**:
|
||||
1. Select **Provision Azure Active Directory Groups**.
|
||||
1. On the Attribute Mapping page, turn off the **Enabled** toggle. Leaving it turned on doesn't break the SCIM user
|
||||
provisioning, but it causes errors in Azure Active Directory that may be confusing and misleading.
|
||||
1. Select **Save**.
|
||||
1. Return to the **Provisioning** tab, saving unsaved changes if necessary.
|
||||
1. Select **Edit attribute mappings**.
|
||||
1. Turn on the **Provisioning Status** toggle. Synchronization details and any errors appears on the bottom of the
|
||||
**Provisioning** screen, together with a link to the audit events.
|
||||
|
||||
WARNING:
|
||||
Once synchronized, changing the field mapped to `id` and `externalId` may cause a number of errors. These include provisioning errors, duplicate users, and may prevent existing users from accessing the GitLab group.
|
||||
Once synchronized, changing the field mapped to `id` and `externalId` may cause a number of errors. These include
|
||||
provisioning errors, duplicate users, and may prevent existing users from accessing the GitLab group.
|
||||
|
||||
### Okta configuration steps
|
||||
#### Configure attribute mappings
|
||||
|
||||
While [configuring Azure Active Directory for SCIM](#configure-azure-active-directory), you configure attribute mappings.
|
||||
For an example, see [example configuration](example_saml_config.md#scim-mapping).
|
||||
|
||||
The following table provides attribute mappings known to work with GitLab.
|
||||
|
||||
| Source attribute | Target attribute | Matching precedence |
|
||||
|:--------------------|:-------------------------------|:--------------------|
|
||||
| `objectId` | `externalId` | 1 |
|
||||
| `userPrincipalName` | `emails[type eq "work"].value` | |
|
||||
| `mailNickname` | `userName` | |
|
||||
|
||||
Each attribute mapping has:
|
||||
|
||||
- An Azure Active Directory attribute (source attribute).
|
||||
- A `customappsso` attribute (target attribute).
|
||||
- A matching precedence.
|
||||
|
||||
For each attribute:
|
||||
|
||||
1. Select the attribute to edit it.
|
||||
1. Select the required settings.
|
||||
1. Select **Ok**.
|
||||
|
||||
If your SAML configuration differs from [the recommended SAML settings](index.md#azure-setup-notes), select the mapping
|
||||
attributes and modify them accordingly. In particular, the `objectId` source attribute must map to the `externalId`
|
||||
target attribute.
|
||||
|
||||
If a mapping is not listed in the table, use the Azure Active Directory defaults. For a list of required attributes,
|
||||
refer to the [SCIM API documentation](../../../api/scim.md).
|
||||
|
||||
### Configure Okta
|
||||
|
||||
Before you start this section:
|
||||
|
||||
- Check that you are using Okta [Lifecycle Management](https://www.okta.com/products/lifecycle-management/) product. This product tier is required to use SCIM on Okta. To check which Okta product you are using, check your signed Okta contract, contact your Okta AE, CSM, or Okta support.
|
||||
- Complete the [GitLab configuration](#gitlab-configuration) process.
|
||||
- Complete the [GitLab configuration](#configure-gitlab) process.
|
||||
- Complete the setup for SAML application for [Okta](https://developer.okta.com/docs/guides/build-sso-integration/saml2/main/), as described in the [Okta setup notes](index.md#okta-setup-notes).
|
||||
- Check that your Okta SAML setup matches our documentation exactly, especially the NameID configuration. Otherwise, the Okta SCIM app may not work properly.
|
||||
|
||||
|
|
@ -140,7 +159,7 @@ The Okta GitLab application currently only supports SCIM. Continue
|
|||
using the separate Okta [SAML SSO](index.md) configuration along with the new SCIM
|
||||
application described above. An [issue exists](https://gitlab.com/gitlab-org/gitlab/-/issues/216173) to add SAML support to the Okta GitLab application.
|
||||
|
||||
### OneLogin
|
||||
### Configure OneLogin
|
||||
|
||||
As the developers of this app, OneLogin provides a "GitLab (SaaS)" app in their catalog, which includes a SCIM integration.
|
||||
Please reach out to OneLogin if you encounter issues.
|
||||
|
|
@ -317,4 +336,4 @@ and the error response can include a HTML result of the GitLab URL `https://gitl
|
|||
|
||||
This error is harmless and occurs because Group provisioning was turned on but GitLab SCIM integration does not support it nor require it. To
|
||||
remove the error, follow the instructions in the Azure configuration guide to disable the option
|
||||
[`Synchronize Azure Active Directory Groups to AppName`](#azure-configuration-steps).
|
||||
[`Synchronize Azure Active Directory Groups to AppName`](#configure-azure-active-directory).
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ Integrate your project to send notifications from GitLab to a
|
|||
room of your choice in [Google Chat](https://chat.google.com/) (former Google
|
||||
Hangouts).
|
||||
|
||||
## How it works
|
||||
## Integration workflow
|
||||
|
||||
To enable this integration, first you need to create a webhook for the room in
|
||||
Google Chat where you want to receive the notifications from your project.
|
||||
|
|
@ -23,9 +23,9 @@ notifications to Google Chat:
|
|||
|
||||
|
||||
|
||||
## In Google Chat
|
||||
## Enable the integration in Google Chat
|
||||
|
||||
Select a room and create a webhook:
|
||||
To enable the integration in Google Chat:
|
||||
|
||||
1. Enter the room where you want to receive notifications from GitLab.
|
||||
1. Open the room dropdown menu on the top-left and select **Manage webhooks**.
|
||||
|
|
@ -36,20 +36,6 @@ Select a room and create a webhook:
|
|||
|
||||
For further details, see [the Google Chat documentation for configuring webhooks](https://developers.google.com/chat/how-tos/webhooks).
|
||||
|
||||
## In GitLab
|
||||
|
||||
Enable the Google Chat integration in GitLab:
|
||||
|
||||
1. In your project, go to **Settings > Integrations** and select **Google Chat**.
|
||||
1. Scroll down to the end of the page where you find a **Webhook** field.
|
||||
1. Enter the webhook URL you copied from Google Chat.
|
||||
1. Select the events you want to be notified about in your Google Chat room.
|
||||
1. Optional. Select **Test settings** to verify the connection.
|
||||
1. Select **Save changes**.
|
||||
|
||||
To test the integration, make a change based on the events you selected and
|
||||
see the notification in your Google Chat room.
|
||||
|
||||
### Enable threads in Google Chat
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/27823) in GitLab 15.4.
|
||||
|
|
@ -62,3 +48,17 @@ To enable threaded notifications for the same GitLab object (for example, an iss
|
|||
1. Select **Create**.
|
||||
|
||||
You cannot enable threaded replies for existing Google Chat spaces.
|
||||
|
||||
## Enable the integration in GitLab
|
||||
|
||||
To enable the integration in GitLab:
|
||||
|
||||
1. In your project, go to **Settings > Integrations** and select **Google Chat**.
|
||||
1. Scroll down to the end of the page where you find a **Webhook** field.
|
||||
1. Enter the webhook URL you copied from Google Chat.
|
||||
1. Select the events you want to be notified about in your Google Chat room.
|
||||
1. Optional. Select **Test settings** to verify the connection.
|
||||
1. Select **Save changes**.
|
||||
|
||||
To test the integration, make a change based on the events you selected and
|
||||
see the notification in your Google Chat room.
|
||||
|
|
|
|||
|
|
@ -52,13 +52,19 @@ module API
|
|||
|
||||
merged_branch_names = repository.merged_branch_names(branches.map(&:name))
|
||||
|
||||
expiry_time = if Feature.enabled?(:increase_branch_cache_expiry, type: :ops)
|
||||
60.minutes
|
||||
else
|
||||
10.minutes
|
||||
end
|
||||
|
||||
present_cached(
|
||||
branches,
|
||||
with: Entities::Branch,
|
||||
current_user: current_user,
|
||||
project: user_project,
|
||||
merged_branch_names: merged_branch_names,
|
||||
expires_in: 10.minutes,
|
||||
expires_in: expiry_time,
|
||||
cache_context: -> (branch) { [current_user&.cache_key, merged_branch_names.include?(branch.name)] }
|
||||
)
|
||||
end
|
||||
|
|
|
|||
|
|
@ -21,7 +21,6 @@ module Gitlab
|
|||
CATEGORIES_FOR_TOTALS = %w[
|
||||
analytics
|
||||
compliance
|
||||
ecosystem
|
||||
epic_boards_usage
|
||||
epics_usage
|
||||
error_tracking
|
||||
|
|
@ -36,6 +35,7 @@ module Gitlab
|
|||
ci_users
|
||||
deploy_token_packages
|
||||
code_review
|
||||
ecosystem
|
||||
error_tracking
|
||||
ide_edit
|
||||
importer
|
||||
|
|
|
|||
|
|
@ -8,14 +8,6 @@
|
|||
category: ecosystem
|
||||
redis_slot: ecosystem
|
||||
aggregation: weekly
|
||||
- name: i_ecosystem_jira_service_list_issues
|
||||
category: ecosystem
|
||||
redis_slot: ecosystem
|
||||
aggregation: weekly
|
||||
- name: i_ecosystem_jira_service_create_issue
|
||||
category: ecosystem
|
||||
redis_slot: ecosystem
|
||||
aggregation: weekly
|
||||
- name: i_ecosystem_slack_service_issue_notification
|
||||
category: ecosystem
|
||||
redis_slot: ecosystem
|
||||
|
|
|
|||
|
|
@ -46000,6 +46000,9 @@ msgstr ""
|
|||
msgid "cannot be changed if shared runners are enabled"
|
||||
msgstr ""
|
||||
|
||||
msgid "cannot be changed since member is associated with a custom role"
|
||||
msgstr ""
|
||||
|
||||
msgid "cannot be enabled"
|
||||
msgstr ""
|
||||
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@
|
|||
"codesandbox-api": "0.0.23",
|
||||
"compression-webpack-plugin": "^5.0.2",
|
||||
"copy-webpack-plugin": "^6.4.1",
|
||||
"core-js": "^3.25.0",
|
||||
"core-js": "^3.25.1",
|
||||
"cron-validator": "^1.1.1",
|
||||
"cronstrue": "^1.122.0",
|
||||
"cropper": "^2.3.0",
|
||||
|
|
@ -245,7 +245,7 @@
|
|||
"sass": "^1.49.9",
|
||||
"stylelint": "^14.9.1",
|
||||
"timezone-mock": "^1.0.8",
|
||||
"webpack-dev-server": "4.10.1",
|
||||
"webpack-dev-server": "4.11.0",
|
||||
"xhr-mock": "^2.5.1",
|
||||
"yarn-check-webpack-plugin": "^1.2.0",
|
||||
"yarn-deduplicate": "^6.0.0"
|
||||
|
|
|
|||
|
|
@ -159,44 +159,6 @@ module Trigger
|
|||
end
|
||||
end
|
||||
|
||||
class Omnibus < Base
|
||||
def self.access_token
|
||||
# Default to "Multi-pipeline (from 'gitlab-org/gitlab' 'e2e:package-and-test' job)" at https://gitlab.com/gitlab-org/build/omnibus-gitlab-mirror/-/settings/access_tokens
|
||||
ENV['OMNIBUS_GITLAB_PROJECT_ACCESS_TOKEN'] || super
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
def downstream_project_path
|
||||
ENV.fetch('OMNIBUS_PROJECT_PATH', 'gitlab-org/build/omnibus-gitlab-mirror')
|
||||
end
|
||||
|
||||
def ref_param_name
|
||||
'OMNIBUS_BRANCH'
|
||||
end
|
||||
|
||||
def primary_ref
|
||||
'master'
|
||||
end
|
||||
|
||||
def trigger_stable_branch_if_detected?
|
||||
true
|
||||
end
|
||||
|
||||
def extra_variables
|
||||
{
|
||||
'GITLAB_VERSION' => ENV['CI_COMMIT_SHA'],
|
||||
'IMAGE_TAG' => ENV['CI_COMMIT_SHA'],
|
||||
'SKIP_QA_DOCKER' => 'true',
|
||||
'SKIP_QA_TEST' => 'true',
|
||||
'ALTERNATIVE_SOURCES' => 'true',
|
||||
'SECURITY_SOURCES' => Trigger.security? ? 'true' : 'false',
|
||||
'ee' => Trigger.ee? ? 'true' : 'false',
|
||||
'CACHE_UPDATE' => ENV['OMNIBUS_GITLAB_CACHE_UPDATE']
|
||||
}
|
||||
end
|
||||
end
|
||||
|
||||
class CNG < Base
|
||||
def variables
|
||||
# Delete variables that aren't useful when using native triggers.
|
||||
|
|
@ -467,8 +429,6 @@ end
|
|||
|
||||
if $0 == __FILE__
|
||||
case ARGV[0]
|
||||
when 'omnibus'
|
||||
Trigger::Omnibus.new.invoke!(downstream_job_name: 'Trigger:qa-test').wait!
|
||||
when 'cng'
|
||||
Trigger::CNG.new.invoke!.wait!
|
||||
when 'gitlab-com-database-testing'
|
||||
|
|
|
|||
|
|
@ -195,6 +195,15 @@ RSpec.describe Member do
|
|||
expect(member).not_to be_valid
|
||||
end
|
||||
end
|
||||
|
||||
context 'access_level cannot be changed' do
|
||||
it 'is invalid' do
|
||||
member.access_level = Gitlab::Access::MAINTAINER
|
||||
|
||||
expect(member).not_to be_valid
|
||||
expect(member.errors.full_messages).to include( "Access level cannot be changed since member is associated with a custom role")
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -211,6 +211,68 @@ RSpec.describe API::Branches do
|
|||
end
|
||||
|
||||
it_behaves_like 'repository branches'
|
||||
|
||||
context 'caching' do
|
||||
it 'caches the query' do
|
||||
get api(route), params: { per_page: 1 }
|
||||
|
||||
expect(API::Entities::Branch).not_to receive(:represent)
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
end
|
||||
|
||||
context 'when increase_branch_cache_expiry is enabled' do
|
||||
it 'uses the cache up to 60 minutes' do
|
||||
time_of_request = Time.current
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
|
||||
travel_to time_of_request + 59.minutes do
|
||||
expect(API::Entities::Branch).not_to receive(:represent)
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
end
|
||||
end
|
||||
|
||||
it 'requests for new value after 60 minutes' do
|
||||
get api(route), params: { per_page: 1 }
|
||||
|
||||
travel_to 61.minutes.from_now do
|
||||
expect(API::Entities::Branch).to receive(:represent)
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when increase_branch_cache_expiry is disabled' do
|
||||
before do
|
||||
stub_feature_flags(increase_branch_cache_expiry: false)
|
||||
end
|
||||
|
||||
it 'uses the cache up to 10 minutes' do
|
||||
time_of_request = Time.current
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
|
||||
travel_to time_of_request + 9.minutes do
|
||||
expect(API::Entities::Branch).not_to receive(:represent)
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
end
|
||||
end
|
||||
|
||||
it 'requests for new value after 10 minutes' do
|
||||
get api(route), params: { per_page: 1 }
|
||||
|
||||
travel_to 11.minutes.from_now do
|
||||
expect(API::Entities::Branch).to receive(:represent)
|
||||
|
||||
get api(route), params: { per_page: 1 }
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when unauthenticated', 'and project is private' do
|
||||
|
|
|
|||
|
|
@ -244,156 +244,6 @@ RSpec.describe Trigger do
|
|||
end
|
||||
end
|
||||
|
||||
describe Trigger::Omnibus do
|
||||
describe '#variables' do
|
||||
it 'invokes the trigger with expected variables' do
|
||||
expect(subject.variables).to include(
|
||||
'SKIP_QA_TEST' => 'true',
|
||||
'SKIP_QA_DOCKER' => 'true',
|
||||
'ALTERNATIVE_SOURCES' => 'true',
|
||||
'CACHE_UPDATE' => env['OMNIBUS_GITLAB_CACHE_UPDATE']
|
||||
)
|
||||
end
|
||||
|
||||
context 'when CI_COMMIT_SHA is set' do
|
||||
before do
|
||||
stub_env('CI_COMMIT_SHA', 'ci_commit_sha')
|
||||
end
|
||||
|
||||
it 'sets GITLAB_VERSION & IMAGE_TAG to ci_commit_sha' do
|
||||
expect(subject.variables).to include(
|
||||
'GITLAB_VERSION' => 'ci_commit_sha',
|
||||
'IMAGE_TAG' => 'ci_commit_sha'
|
||||
)
|
||||
end
|
||||
end
|
||||
|
||||
context 'when Trigger.security? is true' do
|
||||
before do
|
||||
allow(Trigger).to receive(:security?).and_return(true)
|
||||
end
|
||||
|
||||
it 'sets SECURITY_SOURCES to true' do
|
||||
expect(subject.variables['SECURITY_SOURCES']).to eq('true')
|
||||
end
|
||||
end
|
||||
|
||||
context 'when Trigger.security? is false' do
|
||||
before do
|
||||
allow(Trigger).to receive(:security?).and_return(false)
|
||||
end
|
||||
|
||||
it 'sets SECURITY_SOURCES to false' do
|
||||
expect(subject.variables['SECURITY_SOURCES']).to eq('false')
|
||||
end
|
||||
end
|
||||
|
||||
context 'when Trigger.ee? is true' do
|
||||
before do
|
||||
allow(Trigger).to receive(:ee?).and_return(true)
|
||||
end
|
||||
|
||||
it 'sets ee to true' do
|
||||
expect(subject.variables['ee']).to eq('true')
|
||||
end
|
||||
end
|
||||
|
||||
context 'when Trigger.ee? is false' do
|
||||
before do
|
||||
allow(Trigger).to receive(:ee?).and_return(false)
|
||||
end
|
||||
|
||||
it 'sets ee to false' do
|
||||
expect(subject.variables['ee']).to eq('false')
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '.access_token' do
|
||||
context 'when OMNIBUS_GITLAB_PROJECT_ACCESS_TOKEN is set' do
|
||||
let(:omnibus_gitlab_project_access_token) { 'omnibus_gitlab_project_access_token' }
|
||||
|
||||
before do
|
||||
stub_env('OMNIBUS_GITLAB_PROJECT_ACCESS_TOKEN', omnibus_gitlab_project_access_token)
|
||||
end
|
||||
|
||||
it 'returns the omnibus-specific access token' do
|
||||
expect(described_class.access_token).to eq(omnibus_gitlab_project_access_token)
|
||||
end
|
||||
end
|
||||
|
||||
context 'when OMNIBUS_GITLAB_PROJECT_ACCESS_TOKEN is not set' do
|
||||
before do
|
||||
stub_env('OMNIBUS_GITLAB_PROJECT_ACCESS_TOKEN', nil)
|
||||
end
|
||||
|
||||
it 'returns the default access token' do
|
||||
expect(described_class.access_token).to eq(Trigger::Base.access_token)
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#invoke!' do
|
||||
let(:downstream_project_path) { 'gitlab-org/build/omnibus-gitlab-mirror' }
|
||||
let(:ref) { 'master' }
|
||||
|
||||
let(:env) do
|
||||
super().merge(
|
||||
'QA_IMAGE' => 'qa_image',
|
||||
'GITLAB_QA_OPTIONS' => 'gitlab_qa_options',
|
||||
'QA_TESTS' => 'qa_tests',
|
||||
'ALLURE_JOB_NAME' => 'allure_job_name'
|
||||
)
|
||||
end
|
||||
|
||||
describe '#downstream_project_path' do
|
||||
context 'when OMNIBUS_PROJECT_PATH is set' do
|
||||
let(:downstream_project_path) { 'omnibus_project_path' }
|
||||
|
||||
before do
|
||||
stub_env('OMNIBUS_PROJECT_PATH', downstream_project_path)
|
||||
end
|
||||
|
||||
it 'triggers the pipeline on the correct project' do
|
||||
expect_run_trigger_with_params
|
||||
|
||||
subject.invoke!
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe '#ref' do
|
||||
context 'when OMNIBUS_BRANCH is set' do
|
||||
let(:ref) { 'omnibus_branch' }
|
||||
|
||||
before do
|
||||
stub_env('OMNIBUS_BRANCH', ref)
|
||||
end
|
||||
|
||||
it 'triggers the pipeline on the correct ref' do
|
||||
expect_run_trigger_with_params
|
||||
|
||||
subject.invoke!
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
context 'when CI_COMMIT_REF_NAME is a stable branch' do
|
||||
let(:ref) { '14-10-stable' }
|
||||
|
||||
before do
|
||||
stub_env('CI_COMMIT_REF_NAME', "#{ref}-ee")
|
||||
end
|
||||
|
||||
it 'triggers the pipeline on the correct ref' do
|
||||
expect_run_trigger_with_params
|
||||
|
||||
subject.invoke!
|
||||
end
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
describe Trigger::CNG do
|
||||
describe '#variables' do
|
||||
it 'does not include redundant variables' do
|
||||
|
|
|
|||
16
yarn.lock
16
yarn.lock
|
|
@ -3760,10 +3760,10 @@ core-js-pure@^3.0.0:
|
|||
resolved "https://registry.yarnpkg.com/core-js-pure/-/core-js-pure-3.6.5.tgz#c79e75f5e38dbc85a662d91eea52b8256d53b813"
|
||||
integrity sha512-lacdXOimsiD0QyNf9BC/mxivNJ/ybBGJXQFKzRekp1WTHoVUWsUHEn+2T8GJAzzIhyOuXA+gOxCVN3l+5PLPUA==
|
||||
|
||||
core-js@^3.25.0:
|
||||
version "3.25.0"
|
||||
resolved "https://registry.yarnpkg.com/core-js/-/core-js-3.25.0.tgz#be71d9e0dd648ffd70c44a7ec2319d039357eceb"
|
||||
integrity sha512-CVU1xvJEfJGhyCpBrzzzU1kjCfgsGUxhEvwUV2e/cOedYWHdmluamx+knDnmhqALddMG16fZvIqvs9aijsHHaA==
|
||||
core-js@^3.25.1:
|
||||
version "3.25.1"
|
||||
resolved "https://registry.yarnpkg.com/core-js/-/core-js-3.25.1.tgz#5818e09de0db8956e16bf10e2a7141e931b7c69c"
|
||||
integrity sha512-sr0FY4lnO1hkQ4gLDr24K0DGnweGO1QwSj5BpfQjpSJPdqWalja4cTps29Y/PJVG/P7FYlPDkH3hO+Tr0CvDgQ==
|
||||
|
||||
core-util-is@~1.0.0:
|
||||
version "1.0.3"
|
||||
|
|
@ -12114,10 +12114,10 @@ webpack-dev-middleware@^5.3.1:
|
|||
range-parser "^1.2.1"
|
||||
schema-utils "^4.0.0"
|
||||
|
||||
webpack-dev-server@4.10.1:
|
||||
version "4.10.1"
|
||||
resolved "https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-4.10.1.tgz#124ac9ac261e75303d74d95ab6712b4aec3e12ed"
|
||||
integrity sha512-FIzMq3jbBarz3ld9l7rbM7m6Rj1lOsgq/DyLGMX/fPEB1UBUPtf5iL/4eNfhx8YYJTRlzfv107UfWSWcBK5Odw==
|
||||
webpack-dev-server@4.11.0:
|
||||
version "4.11.0"
|
||||
resolved "https://registry.yarnpkg.com/webpack-dev-server/-/webpack-dev-server-4.11.0.tgz#290ee594765cd8260adfe83b2d18115ea04484e7"
|
||||
integrity sha512-L5S4Q2zT57SK7tazgzjMiSMBdsw+rGYIX27MgPgx7LDhWO0lViPrHKoLS7jo5In06PWYAhlYu3PbyoC6yAThbw==
|
||||
dependencies:
|
||||
"@types/bonjour" "^3.5.9"
|
||||
"@types/connect-history-api-fallback" "^1.3.5"
|
||||
|
|
|
|||
Loading…
Reference in New Issue