Improve details on accessing image from a private Container Registry

doc/ci/docker/using_docker_build.md

@@ -572,7 +572,7 @@ The configuration is picked up by the `dind` service.
 ## Authenticate with registry in Docker-in-Docker
 
 When you use Docker-in-Docker, the
-[standard authentication methods](using_docker_images.md#define-an-image-from-a-private-container-registry)
+[standard authentication methods](using_docker_images.md#access-an-image-from-a-private-container-registry)
 don't work because a fresh Docker daemon is started with the service.
 
 ### Option 1: Run `docker login`

doc/ci/docker/using_docker_images.md

@@ -214,7 +214,7 @@ Look for the `[runners.docker]` section:
 The image and services defined this way are added to all jobs run by
 that runner.
 
-## Define an image from a private Container Registry
+## Access an image from a private Container Registry
 
 To access private container registries, the GitLab Runner process can use:
 
@@ -224,19 +224,12 @@ To access private container registries, the GitLab Runner process can use:
 
 To define which option should be used, the runner process reads the configuration in this order:
 
-- A `DOCKER_AUTH_CONFIG` variable provided as either:
-  - A [CI/CD variable](../variables/index.md) in the `.gitlab-ci.yml` file.
-  - A project's variables stored on the project's **Settings > CI/CD** page.
-- A `DOCKER_AUTH_CONFIG` variable provided as environment variable in the runner's `config.toml` file.
+- A `DOCKER_AUTH_CONFIG` [CI/CD variable](../variables/index.md).
+- A `DOCKER_AUTH_CONFIG` environment variable set in the runner's `config.toml` file.
 - A `config.json` file in `$HOME/.docker` directory of the user running the process.
   If the `--user` flag is provided to run the child processes as unprivileged user,
   the home directory of the main runner process user is used.
 
-The runner reads this configuration **only** from the `config.toml` file and ignores it if
-it's provided as a CI/CD variable. This is because the runner uses **only**
-`config.toml` configuration and does not interpolate **any** CI/CD variables at
-runtime.
-
 ### Requirements and limitations
 
 - Available for [Kubernetes executor](https://docs.gitlab.com/runner/executors/kubernetes.html)
@@ -253,9 +246,9 @@ private registry. Both require setting the CI/CD variable
 `DOCKER_AUTH_CONFIG` with appropriate authentication information.
 
 1. Per-job: To configure one job to access a private registry, add
-   `DOCKER_AUTH_CONFIG` as a job variable.
+   `DOCKER_AUTH_CONFIG` as a [CI/CD variable](../variables/index.md).
 1. Per-runner: To configure a runner so all its jobs can access a
-   private registry, add `DOCKER_AUTH_CONFIG` to the environment in the
+   private registry, add `DOCKER_AUTH_CONFIG` as an environment variable in the
    runner's configuration.
 
 See below for examples of each.
@@ -274,7 +267,7 @@ Let's also assume that these are the sign-in credentials:
 | username | `my_username`               |
 | password | `my_password`               |
 
-Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
+Use one of the following methods to determine the value for `DOCKER_AUTH_CONFIG`:
 
 - Do a `docker login` on your local machine:
 

doc/user/packages/dependency_proxy/index.md

@@ -66,7 +66,7 @@ has disrupted your existing Dependency Proxy usage.
 Because the Dependency Proxy is storing Docker images in a space associated with your group,
 you must authenticate against the Dependency Proxy.
 
-Follow the [instructions for using images from a private registry](../../../ci/docker/using_docker_images.md#define-an-image-from-a-private-container-registry),
+Follow the [instructions for using images from a private registry](../../../ci/docker/using_docker_images.md#access-an-image-from-a-private-container-registry),
 but instead of using `registry.example.com:5000`, use your GitLab domain with no port `gitlab.example.com`.
 
 For example, to manually log in:

doc/user/permissions.md

@@ -534,8 +534,8 @@ users:
 | Push container images to other projects     |                 |             |          |         |
 | Push source and LFS                         |                 |             |          |         |
 
-1. Only if the user is not an external one
-1. Only if the user is a member of the project
+1. Only if the triggering user is not an external one
+1. Only if the triggering user is a member of the project
 
 ## Running pipelines on protected branches