Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorGitLab Bot <gitlab-bot@gitlab.com>2020-05-22 21:08:21 +0300
committerGitLab Bot <gitlab-bot@gitlab.com>2020-05-22 21:08:21 +0300
commit1cf95147eabbb193c1db2526e6c8888e950a3987 (patch)
tree88ae9b19860f7d0552efd048f47d494adcaa03af /doc
parentd6e421b21ed5574700c165cd3361094f4093ac72 (diff)
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r--doc/administration/auth/README.md3
-rw-r--r--doc/administration/packages/container_registry.md16
-rw-r--r--doc/api/graphql/reference/gitlab_schema.graphql10
-rw-r--r--doc/api/graphql/reference/gitlab_schema.json28
-rw-r--r--doc/api/graphql/reference/index.md2
-rw-r--r--doc/development/telemetry/usage_ping.md387
-rw-r--r--doc/user/application_security/container_scanning/index.md146
-rw-r--r--doc/user/application_security/dependency_scanning/index.md36
-rw-r--r--doc/user/compliance/license_compliance/index.md27
9 files changed, 339 insertions, 316 deletions
diff --git a/doc/administration/auth/README.md b/doc/administration/auth/README.md
index 1c5b00b36ad..54c5181853f 100644
--- a/doc/administration/auth/README.md
+++ b/doc/administration/auth/README.md
@@ -32,3 +32,6 @@ providers:
- [Shibboleth](../../integration/shibboleth.md)
- [Smartcard](smartcard.md) **(PREMIUM ONLY)**
- [Twitter](../../integration/twitter.md)
+
+NOTE: **Note:**
+UltraAuth has removed their software which supports OmniAuth integration. We have therefore removed all references to UltraAuth integration.
diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md
index f0903e39012..1a8fbf054ac 100644
--- a/doc/administration/packages/container_registry.md
+++ b/doc/administration/packages/container_registry.md
@@ -116,7 +116,7 @@ expose the Registry on a port so that you can reuse the existing GitLab TLS
certificate.
Assuming that the GitLab domain is `https://gitlab.example.com` and the port the
-Registry is exposed to the outside world is `4567`, here is what you need to set
+Registry is exposed to the outside world is `5050`, here is what you need to set
in `gitlab.rb` or `gitlab.yml` if you are using Omnibus GitLab or installed
GitLab from source respectively.
@@ -130,7 +130,7 @@ otherwise you will run into conflicts.
path to the existing TLS certificate and key used by GitLab:
```ruby
- registry_external_url 'https://gitlab.example.com:4567'
+ registry_external_url 'https://gitlab.example.com:5050'
```
Note how the `registry_external_url` is listening on HTTPS under the
@@ -151,7 +151,7 @@ otherwise you will run into conflicts.
1. Validate using:
```shell
- openssl s_client -showcerts -servername gitlab.example.com -connect gitlab.example.com:443 > cacert.pem
+ openssl s_client -showcerts -servername gitlab.example.com -connect gitlab.example.com:5050 > cacert.pem
```
NOTE: **Note:**
@@ -166,7 +166,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
registry:
enabled: true
host: gitlab.example.com
- port: 4567
+ port: 5050
```
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
@@ -176,7 +176,7 @@ Users should now be able to login to the Container Registry with their GitLab
credentials using:
```shell
-docker login gitlab.example.com:4567
+docker login gitlab.example.com:5050
```
### Configure Container Registry under its own domain
@@ -1062,7 +1062,7 @@ A user attempted to enable an S3-backed Registry. The `docker login` step went
fine. However, when pushing an image, the output showed:
```plaintext
-The push refers to a repository [s3-testing.myregistry.com:4567/root/docker-test/docker-image]
+The push refers to a repository [s3-testing.myregistry.com:5050/root/docker-test/docker-image]
dc5e59c14160: Pushing [==================================================>] 14.85 kB
03c20c1a019a: Pushing [==================================================>] 2.048 kB
a08f14ef632e: Pushing [==================================================>] 2.048 kB
@@ -1154,8 +1154,8 @@ Now that we have mitmproxy and Docker running, we can attempt to login and push
a container image. You may need to run as root to do this. For example:
```shell
-docker login s3-testing.myregistry.com:4567
-docker push s3-testing.myregistry.com:4567/root/docker-test/docker-image
+docker login s3-testing.myregistry.com:5050
+docker push s3-testing.myregistry.com:5050/root/docker-test/docker-image
```
In the example above, we see the following trace on the mitmproxy window:
diff --git a/doc/api/graphql/reference/gitlab_schema.graphql b/doc/api/graphql/reference/gitlab_schema.graphql
index 9e351124126..7cfd4196a34 100644
--- a/doc/api/graphql/reference/gitlab_schema.graphql
+++ b/doc/api/graphql/reference/gitlab_schema.graphql
@@ -5768,6 +5768,11 @@ type MergeRequest implements Noteable {
): UserConnection
"""
+ User who created this merge request
+ """
+ author: User
+
+ """
Timestamp of when the merge request was created
"""
createdAt: Time!
@@ -5918,6 +5923,11 @@ type MergeRequest implements Noteable {
mergeableDiscussionsState: Boolean
"""
+ Timestamp of when the merge request was merged, null if not merged
+ """
+ mergedAt: Time
+
+ """
The milestone of the merge request
"""
milestone: Milestone
diff --git a/doc/api/graphql/reference/gitlab_schema.json b/doc/api/graphql/reference/gitlab_schema.json
index c1addf68b79..db737743d32 100644
--- a/doc/api/graphql/reference/gitlab_schema.json
+++ b/doc/api/graphql/reference/gitlab_schema.json
@@ -16086,6 +16086,20 @@
"deprecationReason": null
},
{
+ "name": "author",
+ "description": "User who created this merge request",
+ "args": [
+
+ ],
+ "type": {
+ "kind": "OBJECT",
+ "name": "User",
+ "ofType": null
+ },
+ "isDeprecated": false,
+ "deprecationReason": null
+ },
+ {
"name": "createdAt",
"description": "Timestamp of when the merge request was created",
"args": [
@@ -16500,6 +16514,20 @@
"deprecationReason": null
},
{
+ "name": "mergedAt",
+ "description": "Timestamp of when the merge request was merged, null if not merged",
+ "args": [
+
+ ],
+ "type": {
+ "kind": "SCALAR",
+ "name": "Time",
+ "ofType": null
+ },
+ "isDeprecated": false,
+ "deprecationReason": null
+ },
+ {
"name": "milestone",
"description": "The milestone of the merge request",
"args": [
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index dfeb4e0f46d..7d0cf9eb322 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -860,6 +860,7 @@ Autogenerated return type of MarkAsSpamSnippet
| Name | Type | Description |
| --- | ---- | ---------- |
| `allowCollaboration` | Boolean | Indicates if members of the target project can push to the fork |
+| `author` | User | User who created this merge request |
| `createdAt` | Time! | Timestamp of when the merge request was created |
| `defaultMergeCommitMessage` | String | Default merge commit message of the merge request |
| `description` | String | Description of the merge request (Markdown rendered as HTML for caching) |
@@ -880,6 +881,7 @@ Autogenerated return type of MarkAsSpamSnippet
| `mergeStatus` | String | Status of the merge request |
| `mergeWhenPipelineSucceeds` | Boolean | Indicates if the merge has been set to be merged when its pipeline succeeds (MWPS) |
| `mergeableDiscussionsState` | Boolean | Indicates if all discussions in the merge request have been resolved, allowing the merge request to be merged |
+| `mergedAt` | Time | Timestamp of when the merge request was merged, null if not merged |
| `milestone` | Milestone | The milestone of the merge request |
| `project` | Project! | Alias for target_project |
| `projectId` | Int! | ID of the merge request project |
diff --git a/doc/development/telemetry/usage_ping.md b/doc/development/telemetry/usage_ping.md
index 6630f8e779e..e2033e97d0d 100644
--- a/doc/development/telemetry/usage_ping.md
+++ b/doc/development/telemetry/usage_ping.md
@@ -55,199 +55,7 @@ You can view the exact JSON payload sent to GitLab Inc. in the administration pa
1. Expand the **Usage statistics** section.
1. Click the **Preview payload** button.
-<details>
-<summary>Click to view an example of the payload structure.</summary>
-
-```json
-{
- "uuid": "0000000-0000-0000-0000-000000000000",
- "hostname": "example.com",
- "version": "12.10.0-pre",
- "installation_type": "omnibus-gitlab",
- "active_user_count": 999,
- "recorded_at": "2020-04-17T07:43:54.162+00:00",
- "edition": "EEU",
- "license_md5": "00000000000000000000000000000000",
- "license_id": null,
- "historical_max_users": 999,
- "licensee": {
- "Name": "ABC, Inc.",
- "Email": "email@example.com",
- "Company": "ABC, Inc."
- },
- "license_user_count": 999,
- "license_starts_at": "2020-01-01",
- "license_expires_at": "2021-01-01",
- "license_plan": "ultimate",
- "license_add_ons": {
- },
- "license_trial": false,
- "counts": {
- "assignee_lists": 999,
- "boards": 999,
- "ci_builds": 999,
- ...
- },
- "container_registry_enabled": true,
- "dependency_proxy_enabled": false,
- "gitlab_shared_runners_enabled": true,
- "gravatar_enabled": true,
- "influxdb_metrics_enabled": true,
- "ldap_enabled": false,
- "mattermost_enabled": false,
- "omniauth_enabled": true,
- "prometheus_metrics_enabled": false,
- "reply_by_email_enabled": "incoming+%{key}@incoming.gitlab.com",
- "signup_enabled": true,
- "web_ide_clientside_preview_enabled": true,
- "ingress_modsecurity_enabled": true,
- "projects_with_expiration_policy_disabled": 999,
- "projects_with_expiration_policy_enabled": 999,
- ...
- "elasticsearch_enabled": true,
- "license_trial_ends_on": null,
- "geo_enabled": false,
- "git": {
- "version": {
- "major": 2,
- "minor": 26,
- "patch": 1
- }
- },
- "gitaly": {
- "version": "12.10.0-rc1-93-g40980d40",
- "servers": 56,
- "filesystems": [
- "EXT_2_3_4"
- ]
- },
- "gitlab_pages": {
- "enabled": true,
- "version": "1.17.0"
- },
- "database": {
- "adapter": "postgresql",
- "version": "9.6.15"
- },
- "app_server": {
- "type": "console"
- },
- "avg_cycle_analytics": {
- "issue": {
- "average": 999,
- "sd": 999,
- "missing": 999
- },
- "plan": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "code": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "test": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "review": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "staging": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "production": {
- "average": null,
- "sd": 999,
- "missing": 999
- },
- "total": 999
- },
- "usage_activity_by_stage": {
- "configure": {
- "project_clusters_enabled": 999,
- ...
- },
- "create": {
- "merge_requests": 999,
- ...
- },
- "manage": {
- "events": 999,
- ...
- },
- "monitor": {
- "clusters": 999,
- ...
- },
- "package": {
- "projects_with_packages": 999
- },
- "plan": {
- "issues": 999,
- ...
- },
- "release": {
- "deployments": 999,
- ...
- },
- "secure": {
- "user_container_scanning_jobs": 999,
- ...
- },
- "verify": {
- "ci_builds": 999,
- ...
- }
- },
- "usage_activity_by_stage_monthly": {
- "configure": {
- "project_clusters_enabled": 999,
- ...
- },
- "create": {
- "merge_requests": 999,
- ...
- },
- "manage": {
- "events": 999,
- ...
- },
- "monitor": {
- "clusters": 999,
- ...
- },
- "package": {
- "projects_with_packages": 999
- },
- "plan": {
- "issues": 999,
- ...
- },
- "release": {
- "deployments": 999,
- ...
- },
- "secure": {
- "user_container_scanning_jobs": 999,
- ...
- },
- "verify": {
- "ci_builds": 999,
- ...
- }
- }
-}
-```
-
-</details>
+For an example payload, see [Example Usage Ping payload](#example-usage-ping-payload).
## Disable Usage Ping
@@ -484,3 +292,196 @@ Examples of query optimization work:
### 4. Ask for a Telemetry Review
On GitLab.com, we have DangerBot setup to monitor Telemetry related files and DangerBot will recommend a Telemetry review. Mention `@gitlab-org/growth/telemetry/engineers` in your MR for a review.
+
+## Example Usage Ping payload
+
+The following is example content of the Usage Ping payload.
+
+```json
+{
+ "uuid": "0000000-0000-0000-0000-000000000000",
+ "hostname": "example.com",
+ "version": "12.10.0-pre",
+ "installation_type": "omnibus-gitlab",
+ "active_user_count": 999,
+ "recorded_at": "2020-04-17T07:43:54.162+00:00",
+ "edition": "EEU",
+ "license_md5": "00000000000000000000000000000000",
+ "license_id": null,
+ "historical_max_users": 999,
+ "licensee": {
+ "Name": "ABC, Inc.",
+ "Email": "email@example.com",
+ "Company": "ABC, Inc."
+ },
+ "license_user_count": 999,
+ "license_starts_at": "2020-01-01",
+ "license_expires_at": "2021-01-01",
+ "license_plan": "ultimate",
+ "license_add_ons": {
+ },
+ "license_trial": false,
+ "counts": {
+ "assignee_lists": 999,
+ "boards": 999,
+ "ci_builds": 999,
+ ...
+ },
+ "container_registry_enabled": true,
+ "dependency_proxy_enabled": false,
+ "gitlab_shared_runners_enabled": true,
+ "gravatar_enabled": true,
+ "influxdb_metrics_enabled": true,
+ "ldap_enabled": false,
+ "mattermost_enabled": false,
+ "omniauth_enabled": true,
+ "prometheus_metrics_enabled": false,
+ "reply_by_email_enabled": "incoming+%{key}@incoming.gitlab.com",
+ "signup_enabled": true,
+ "web_ide_clientside_preview_enabled": true,
+ "ingress_modsecurity_enabled": true,
+ "projects_with_expiration_policy_disabled": 999,
+ "projects_with_expiration_policy_enabled": 999,
+ ...
+ "elasticsearch_enabled": true,
+ "license_trial_ends_on": null,
+ "geo_enabled": false,
+ "git": {
+ "version": {
+ "major": 2,
+ "minor": 26,
+ "patch": 1
+ }
+ },
+ "gitaly": {
+ "version": "12.10.0-rc1-93-g40980d40",
+ "servers": 56,
+ "filesystems": [
+ "EXT_2_3_4"
+ ]
+ },
+ "gitlab_pages": {
+ "enabled": true,
+ "version": "1.17.0"
+ },
+ "database": {
+ "adapter": "postgresql",
+ "version": "9.6.15"
+ },
+ "app_server": {
+ "type": "console"
+ },
+ "avg_cycle_analytics": {
+ "issue": {
+ "average": 999,
+ "sd": 999,
+ "missing": 999
+ },
+ "plan": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "code": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "test": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "review": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "staging": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "production": {
+ "average": null,
+ "sd": 999,
+ "missing": 999
+ },
+ "total": 999
+ },
+ "usage_activity_by_stage": {
+ "configure": {
+ "project_clusters_enabled": 999,
+ ...
+ },
+ "create": {
+ "merge_requests": 999,
+ ...
+ },
+ "manage": {
+ "events": 999,
+ ...
+ },
+ "monitor": {
+ "clusters": 999,
+ ...
+ },
+ "package": {
+ "projects_with_packages": 999
+ },
+ "plan": {
+ "issues": 999,
+ ...
+ },
+ "release": {
+ "deployments": 999,
+ ...
+ },
+ "secure": {
+ "user_container_scanning_jobs": 999,
+ ...
+ },
+ "verify": {
+ "ci_builds": 999,
+ ...
+ }
+ },
+ "usage_activity_by_stage_monthly": {
+ "configure": {
+ "project_clusters_enabled": 999,
+ ...
+ },
+ "create": {
+ "merge_requests": 999,
+ ...
+ },
+ "manage": {
+ "events": 999,
+ ...
+ },
+ "monitor": {
+ "clusters": 999,
+ ...
+ },
+ "package": {
+ "projects_with_packages": 999
+ },
+ "plan": {
+ "issues": 999,
+ ...
+ },
+ "release": {
+ "deployments": 999,
+ ...
+ },
+ "secure": {
+ "user_container_scanning_jobs": 999,
+ ...
+ },
+ "verify": {
+ "ci_builds": 999,
+ ...
+ }
+ }
+}
+```
diff --git a/doc/user/application_security/container_scanning/index.md b/doc/user/application_security/container_scanning/index.md
index 093780f36db..21a4155df40 100644
--- a/doc/user/application_security/container_scanning/index.md
+++ b/doc/user/application_security/container_scanning/index.md
@@ -8,35 +8,28 @@ type: reference, howto
## Overview
-If you are using [GitLab CI/CD](../../../ci/README.md), you can check your Docker
-images (or more precisely the containers) for known vulnerabilities by using
-[Clair](https://github.com/quay/clair) and [klar](https://github.com/optiopay/klar),
-two open source tools for Vulnerability Static Analysis for containers.
+Your application's Docker image may itself be based on Docker images that contain known
+vulnerabilities. By including an extra job in your pipeline that scans for those vulnerabilities and
+displays them in a merge request, you can use GitLab to audit your Docker-based apps.
+By default, container scanning in GitLab is based on [Clair](https://github.com/quay/clair) and
+[Klar](https://github.com/optiopay/klar), which are open-source tools for vulnerability static analysis in
+containers. [GitLab's Klar analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/klar/)
+scans the containers and serves as a wrapper for Clair.
-You can take advantage of Container Scanning by either [including the CI job](#configuration) in
-your existing `.gitlab-ci.yml` file or by implicitly using
-[Auto Container Scanning](../../../topics/autodevops/stages.md#auto-container-scanning-ultimate)
-that is provided by [Auto DevOps](../../../topics/autodevops/index.md).
-
-GitLab checks the Container Scanning report, compares the found vulnerabilities
-between the source and target branches, and shows the information right on the
-merge request.
-
-![Container Scanning Widget](img/container_scanning_v13_0.png)
-
-## Contribute your scanner
+NOTE: **Note:**
+To integrate security scanners other than Clair and Klar into GitLab, see
+[Security scanner integration](../../../development/integrations/secure.md).
-The [Security Scanner Integration](../../../development/integrations/secure.md) documentation explains how to integrate other security scanners into GitLab.
+You can enable container scanning by doing one of the following:
-## Use cases
+- [Include the CI job](#configuration) in your existing `.gitlab-ci.yml` file.
+- Implicitly use [Auto Container Scanning](../../../topics/autodevops/stages.md#auto-container-scanning-ultimate)
+ provided by [Auto DevOps](../../../topics/autodevops/index.md).
-If you distribute your application with Docker, then there's a great chance
-that your image is based on other Docker images that may in turn contain some
-known vulnerabilities that could be exploited.
+GitLab compares the found vulnerabilities between the source and target branches, and shows the
+information directly in the merge request.
-Having an extra job in your pipeline that checks for those vulnerabilities,
-and the fact that they are displayed inside a merge request, makes it very easy
-to perform audits for your Docker-based apps.
+![Container Scanning Widget](img/container_scanning_v13_0.png)
<!-- NOTE: The container scanning tool references the following heading in the code, so if you
make a change to this heading, make sure to update the documentation URLs used in the
@@ -44,26 +37,21 @@ to perform audits for your Docker-based apps.
## Requirements
-To enable Container Scanning in your pipeline, you need:
-
-- A GitLab Runner with the
- [`docker`](https://docs.gitlab.com/runner/executors/docker.html) or
- [`kubernetes`](https://docs.gitlab.com/runner/install/kubernetes.html)
- executor.
-- Docker `18.09.03` or higher installed on the machine where the Runners are
- running. If you're using the shared Runners on GitLab.com, this is already
- the case.
-- To [build and push](../../packages/container_registry/index.md#container-registry-examples-with-gitlab-cicd)
- your Docker image to your project's Container Registry.
- The name of the Docker image should use the following
- [predefined environment variables](../../../ci/variables/predefined_variables.md)
- as defined below:
+To enable Container Scanning in your pipeline, you need the following:
+
+- [GitLab Runner](https://docs.gitlab.com/runner/) with the [Docker](https://docs.gitlab.com/runner/executors/docker.html)
+ or [Kubernetes](https://docs.gitlab.com/runner/install/kubernetes.html) executor.
+- Docker `18.09.03` or higher installed on the same computer as the Runner. If you're using the
+ shared Runners on GitLab.com, then this is already the case.
+- [Build and push](../../packages/container_registry/index.md#container-registry-examples-with-gitlab-cicd)
+ your Docker image to your project's container registry. The name of the Docker image should use
+ the following [predefined environment variables](../../../ci/variables/predefined_variables.md):
```plaintext
$CI_REGISTRY_IMAGE/$CI_COMMIT_REF_SLUG:$CI_COMMIT_SHA
```
- These can be used directly in your `.gitlab-ci.yml` file:
+ You can use these directly in your `.gitlab-ci.yml` file:
```yaml
build:
@@ -81,37 +69,35 @@ To enable Container Scanning in your pipeline, you need:
## Configuration
-For GitLab 11.9 and later, to enable Container Scanning, you must
-[include](../../../ci/yaml/README.md#includetemplate) the
-[`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
-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.
+How you enable Container Scanning depends on your GitLab version:
+
+- GitLab 11.9 and later: [Include](../../../ci/yaml/README.md#includetemplate) the
+ [`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml)
+ that comes with your GitLab installation.
+- GitLab versions earlier than 11.9: Copy and use the job from the
+ [`Container-Scanning.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/Container-Scanning.gitlab-ci.yml).
-Add the following to your `.gitlab-ci.yml` file:
+To include the `Container-Scanning.gitlab-ci.yml` template (GitLab 11.9 and later), add the
+following to your `.gitlab-ci.yml` file:
```yaml
include:
- template: Container-Scanning.gitlab-ci.yml
```
-The included template will:
+The included template:
-1. Create a `container_scanning` job in your CI/CD pipeline.
-1. Pull the already built Docker image from your project's
- [Container Registry](../../packages/container_registry/index.md) (see [requirements](#requirements))
- and scan it for possible vulnerabilities.
+- Creates a `container_scanning` job in your CI/CD pipeline.
+- Pulls the built Docker image from your project's [Container Registry](../../packages/container_registry/index.md)
+ (see [requirements](#requirements)) and scans it for possible vulnerabilities.
-The results will be saved as a
+GitLab saves the results as a
[Container Scanning report artifact](../../../ci/pipelines/job_artifacts.md#artifactsreportscontainer_scanning-ultimate)
-that you can later download and analyze.
-Due to implementation limitations, we always take the latest Container Scanning
-artifact available. Behind the scenes, the
-[GitLab Klar analyzer](https://gitlab.com/gitlab-org/security-products/analyzers/klar/)
-is used and runs the scans.
+that you can download and analyze later. When downloading, you always receive the most-recent
+artifact.
-The following is a sample `.gitlab-ci.yml` that will build your Docker image,
-push it to the Container Registry, and run Container Scanning:
+The following is a sample `.gitlab-ci.yml` that builds your Docker image, pushes it to the Container
+Registry, and scans the containers:
```yaml
variables:
@@ -141,11 +127,15 @@ include:
### Customizing the Container Scanning settings
-You can change container scanning settings by using the [`variables`](../../../ci/yaml/README.md#variables)
-parameter in your `.gitlab-ci.yml` to change [environment variables](#available-variables).
+There may be cases where you want to customize how GitLab scans your containers. For example, you
+may want to enable more verbose output from Clair or Klar, access a Docker registry that requires
+authentication, and more. To change such settings, use the [`variables`](../../../ci/yaml/README.md#variables)
+parameter in your `.gitlab-ci.yml` to set [environment variables](#available-variables).
+The environment variables you set in your `.gitlab-ci.yml` overwrite those in
+`Container-Scanning.gitlab-ci.yml`.
-In the following example, we [include](../../../ci/yaml/README.md#include) the template and also
-set the `CLAIR_OUTPUT` variable to `High`:
+This example [includes](../../../ci/yaml/README.md#include) the Container Scanning template and
+enables verbose output from Clair by setting the `CLAIR_OUTPUT` environment variable to `High`:
```yaml
include:
@@ -155,9 +145,6 @@ variables:
CLAIR_OUTPUT: High
```
-The `CLAIR_OUTPUT` variable defined in the main `gitlab-ci.yml` will overwrite what's
-defined in `Container-Scanning.gitlab-ci.yml`, changing the Container Scanning behavior.
-
<!-- NOTE: The container scanning tool references the following heading in the code, so if you"
make a change to this heading, make sure to update the documentation URLs used in the"
container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar)" -->
@@ -188,13 +175,9 @@ using environment variables.
### Overriding the Container Scanning template
-CAUTION: **Deprecation:**
-Beginning in GitLab 13.0, the use of [`only` and `except`](../../../ci/yaml/README.md#onlyexcept-basic)
-is no longer supported. When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules) instead.
-
-If you want to override the job definition (for example, change properties like
-`variables`), you need to declare a `container_scanning` job after the
-template inclusion and specify any additional keys under it. For example:
+If you want to override the job definition (for example, to change properties like `variables`), you
+must declare a `container_scanning` job after the template inclusion, and then
+specify any additional keys. For example:
```yaml
include:
@@ -205,15 +188,20 @@ container_scanning:
GIT_STRATEGY: fetch
```
+CAUTION: **Deprecated:**
+GitLab 13.0 and later doesn't support [`only` and `except`](../../../ci/yaml/README.md#onlyexcept-basic).
+When overriding the template, you must use [`rules`](../../../ci/yaml/README.md#rules)
+instead.
+
### Vulnerability whitelisting
-If you want to whitelist specific vulnerabilities, you'll need to:
+To whitelist specific vulnerabilities, follow these steps:
-1. Set `GIT_STRATEGY: fetch` in your `.gitlab-ci.yml` file by following the instructions described in the
- [overriding the Container Scanning template](#overriding-the-container-scanning-template) section of this document.
-1. Define the whitelisted vulnerabilities in a YAML file named `clair-whitelist.yml` which must use the format described
- in the [whitelist example file](https://github.com/arminc/clair-scanner/blob/v12/example-whitelist.yaml).
-1. Add the `clair-whitelist.yml` file to the Git repository of your project.
+1. Set `GIT_STRATEGY: fetch` in your `.gitlab-ci.yml` file by following the instructions in
+ [overriding the Container Scanning template](#overriding-the-container-scanning-template).
+1. Define the whitelisted vulnerabilities in a YAML file named `clair-whitelist.yml`. This must use
+ the format described in the [whitelist example file](https://github.com/arminc/clair-scanner/blob/v12/example-whitelist.yaml).
+1. Add the `clair-whitelist.yml` file to your project's Git repository.
### Running Container Scanning in an offline environment
diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md
index 9a08dd0c979..bd6a2dda6f8 100644
--- a/doc/user/application_security/dependency_scanning/index.md
+++ b/doc/user/application_security/dependency_scanning/index.md
@@ -498,42 +498,6 @@ BUNDLER_AUDIT_ADVISORY_DB_REF_NAME: "master"
BUNDLER_AUDIT_ADVISORY_DB_URL: "gitlab.example.com/ruby-advisory-db.git"
```
-#### Java (Maven) projects
-
-When using self-signed certificates, add the following job section to the `.gitlab-ci.yml`:
-
-```yaml
-gemnasium-maven-dependency_scanning:
- variables:
- MAVEN_CLI_OPTS: "-s settings.xml -Dmaven.wagon.http.ssl.insecure=true -Dmaven.wagon.http.ssl.allowall=true -Dmaven.wagon.http.ssl.ignore.validity.dates=true"
-```
-
-#### Java (Gradle) projects
-
-When using self-signed certificates, add the following job section to the `.gitlab-ci.yml`:
-
-```yaml
-gemnasium-maven-dependency_scanning:
- before_script:
- - echo -n | openssl s_client -connect maven-repo.example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/internal.crt
- - keytool -importcert -file /tmp/internal.crt -cacerts -storepass changeit -noprompt
-```
-
-This adds the self-signed certificates of your Maven repository to the Java KeyStore of the analyzer's Docker image.
-
-#### Scala (sbt) projects
-
-When using self-signed certificates, add the following job section to the `.gitlab-ci.yml`:
-
-```yaml
-gemnasium-maven-dependency_scanning:
- before_script:
- - echo -n | openssl s_client -connect maven-repo.example.com:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/internal.crt
- - keytool -importcert -file /tmp/internal.crt -cacerts -storepass changeit -noprompt
-```
-
-This adds the self-signed certificates of your Maven repository to the Java KeyStore of the analyzer's Docker image.
-
#### Python (setuptools)
When using self-signed certificates for your private PyPi repository, no extra job configuration (aside
diff --git a/doc/user/compliance/license_compliance/index.md b/doc/user/compliance/license_compliance/index.md
index 0d191931169..47250df97a6 100644
--- a/doc/user/compliance/license_compliance/index.md
+++ b/doc/user/compliance/license_compliance/index.md
@@ -348,6 +348,32 @@ npmRegistryServer: "https://npm.example.com"
You can supply a custom root certificate to complete TLS verification by using the
`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables).
+### Configuring Bower projects
+
+You can configure Bower projects by using a [`.bowerrc`](https://bower.io/docs/config/#bowerrc-specification)
+file.
+
+#### Using private Bower registries
+
+If you have a private Bower registry you can use the
+[`registry`](https://bower.io/docs/config/#bowerrc-specification)
+setting to specify its location.
+
+For example:
+
+```plaintext
+{
+ "registry": "https://registry.bower.io"
+}
+```
+
+#### Custom root certificates for Bower
+
+You can supply a custom root certificate to complete TLS verification by using the
+`ADDITIONAL_CA_CERT_BUNDLE` [environment variable](#available-variables), or by
+specifying a `ca` setting in a [`.bowerrc`](https://bower.io/docs/config/#bowerrc-specification)
+file.
+
### Migration from `license_management` to `license_scanning`
In GitLab 12.8 a new name for `license_management` job was introduced. This change was made to improve clarity around the purpose of the scan, which is to scan and collect the types of licenses present in a projects dependencies.
@@ -451,6 +477,7 @@ The License Compliance job should now use local copies of the License Compliance
your code and generate security reports, without requiring internet access.
Additional configuration may be needed for connecting to [private Maven repositories](#using-private-maven-repos),
+[private Bower registries](#using-private-bower-registries),
[private NPM registries](#using-private-npm-registries), [private Yarn registries](#using-private-yarn-registries), and [private Python repositories](#using-private-python-repos).
Exact name matches are required for [project policies](#project-policies-for-license-compliance)