Merge branch '220540-remove-ds-dind-from-docs' into 'master'

Remove DinD mode from DS docs

See merge request gitlab-org/gitlab!40631

changelogs/unreleased/220540-remove-ds-dind-from-docs.yml

+---
+title: Remove Docker-in-Docker mode from Dependency Scanning documentation
+merge_request: 40631
+author:
+type: removed

doc/user/application_security/dependency_scanning/analyzers.md

@@ -90,32 +90,7 @@ That's needed when one totally relies on [custom analyzers](#custom-analyzers).
 
 ## Custom analyzers
 
-### Custom analyzers with Docker-in-Docker
-
-When Docker-in-Docker for Dependency Scanning is enabled,
-you can provide your own analyzers as a comma-separated list of Docker images.
-Here's how to add `analyzers/nuget` and `analyzers/perl` to the default images.
-In `.gitlab-ci.yml` define:
-
-```yaml
-include:
-  template: Dependency-Scanning.gitlab-ci.yml
-
-variables:
-  DS_ANALYZER_IMAGES: "my-docker-registry/analyzers/nuget,amy-docker-registry/analyzers/perl"
-```
-
-The values must be the full path to the container registry images,
-like what you would feed to the `docker pull` command.
-
-NOTE: **Note:**
-This configuration doesn't benefit from the integrated detection step. Dependency
-Scanning has to fetch and spawn each Docker image to establish whether the
-custom analyzer can scan the source code.
-
-### Custom analyzers without Docker-in-Docker
-
-When Docker-in-Docker for Dependency Scanning is disabled, you can provide your own analyzers by
+You can provide your own analyzers by
 defining CI jobs in your CI configuration. For consistency, you should suffix your custom Dependency
 Scanning jobs with `-dependency_scanning`. Here's how to add a scanning job that's based on the
 Docker image `my-docker-registry/analyzers/nuget` and generates a Dependency Scanning report

doc/user/application_security/dependency_scanning/index.md

@@ -49,8 +49,6 @@ CAUTION: **Caution:**
 If you use your own Runners, make sure your installed version of Docker
 is **not** `19.03.0`. See [troubleshooting information](#error-response-from-daemon-error-processing-tar-file-docker-tar-relocation-error) for details.
 
-Beginning with GitLab 13.0, Docker privileged mode is necessary only if you've [enabled Docker-in-Docker for Dependency Scanning](#enabling-docker-in-docker).
-
 ## Supported languages and package managers
 
 GitLab relies on [`rules`](../../../ci/yaml/README.md#rules) to start relevant analyzers depending on the languages detected in the repository.
@@ -154,24 +152,10 @@ The following variables allow configuration of global dependency scanning settin
 | --------------------------------------- |------------ |
 | `SECURE_ANALYZERS_PREFIX`               | Override the name of the Docker registry providing the official default images (proxy). Read more about [customizing analyzers](analyzers.md). |
 | `DS_DEFAULT_ANALYZERS`                  | Override the names of the official default images. Read more about [customizing analyzers](analyzers.md). |
-| `DS_DISABLE_DIND`                       | Disable Docker-in-Docker and run analyzers [individually](#enabling-docker-in-docker). This variable is `true` by default. |
 | `ADDITIONAL_CA_CERT_BUNDLE`             | Bundle of CA certs to trust. The bundle of certificates provided here is also used by other tools during the scanning process, such as `git`, `yarn`, or `npm`. |
 | `DS_EXCLUDED_PATHS`                     | Exclude vulnerabilities from output based on the paths. A comma-separated list of patterns. Patterns can be globs, or file or folder paths (for example, `doc,spec`). Parent directories also match patterns. Default: `"spec, test, tests, tmp"` |
 | `SECURE_LOG_LEVEL`                      | Set the minimum logging level. Messages of this logging level or higher are output. From highest to lowest severity, the logging levels are: `fatal`, `error`, `warn`, `info`, `debug`. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10880) in GitLab 13.1. Default: `info` |
 
-#### Configuring Docker-in-Docker orchestrator
-
-The following variables configure the Docker-in-Docker orchestrator, and therefore are only used when the Docker-in-Docker mode is [enabled](#enabling-docker-in-docker).
-
-| Environment variable                    | Default     | Description |
-| --------------------------------------- | ----------- | ----------- |
-| `DS_ANALYZER_IMAGES`                    |             | Comma-separated list of custom images. The official default images are still enabled. Read more about [customizing analyzers](analyzers.md). |
-| `DS_ANALYZER_IMAGE_TAG`                 |             | Override the Docker tag of the official default images. Read more about [customizing analyzers](analyzers.md). |
-| `DS_PULL_ANALYZER_IMAGES`               |             | Pull the images from the Docker registry (set to `0` to disable). |
-| `DS_DOCKER_CLIENT_NEGOTIATION_TIMEOUT`  | 2m          | Time limit for Docker client negotiation. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, or `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
-| `DS_PULL_ANALYZER_IMAGE_TIMEOUT`        | 5m          | Time limit when pulling an analyzer's image. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, or `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
-| `DS_RUN_ANALYZER_TIMEOUT`               | 20m         | Time limit when running an analyzer. Timeouts are parsed using Go's [`ParseDuration`](https://golang.org/pkg/time/#ParseDuration). Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, or `h`. For example, `300ms`, `1.5h`, or `2h45m`. |
-
 #### Configuring specific analyzers used by Dependency Scanning
 
 The following variables are used for configuring specific analyzers (used for a specific language/framework).
@@ -206,27 +190,6 @@ you can use the `MAVEN_CLI_OPTS` environment variable.
 
 Read more on [how to use private Maven repositories](../index.md#using-private-maven-repos).
 
-### Enabling Docker-in-Docker
-
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/12487) in GitLab Ultimate 12.5.
-
-If needed, you can enable Docker-in-Docker to restore the Dependency Scanning behavior that existed
-prior to GitLab 13.0. Follow these steps to do so:
-
-1. Configure GitLab Runner with Docker-in-Docker in [privileged mode](https://docs.gitlab.com/runner/executors/docker.html#use-docker-in-docker-with-privileged-mode).
-1. Set the `DS_DISABLE_DIND` variable to `false`:
-
-   ```yaml
-   include:
-     - template: Dependency-Scanning.gitlab-ci.yml
-
-   variables:
-     DS_DISABLE_DIND: "false"
-   ```
-
-This creates a single `dependency_scanning` job in your CI/CD pipeline instead of multiple
-`<analyzer-name>-dependency_scanning` jobs.
-
 ## Interacting with the vulnerabilities
 
 Once a vulnerability is found, you can interact with it. Read more on how to
@@ -389,7 +352,6 @@ jobs to run successfully. For more information, see [Offline environments](../of
 
 Here are the requirements for using Dependency Scanning in an offline environment:
 
-- Keep Docker-In-Docker disabled (default).
 - GitLab Runner with the [`docker` or `kubernetes` executor](#requirements).
 - Docker Container Registry with locally available copies of Dependency Scanning [analyzer](https://gitlab.com/gitlab-org/security-products/analyzers) images.
 - Host an offline Git copy of the [gemnasium-db advisory database](https://gitlab.com/gitlab-org/security-products/gemnasium-db/).