Secret Mount Targets, SSH Mounts, and Git Authentication for Remote Contexts

When you use the CLI or Bake, the type can be detected automatically. You can also specify it explicitly with `type=file` or `type=env`. The following example mounts the environment variable `KUBECONFIG` to secret ID `kube`, as a file in the build container at `/run/secrets/kube`. ```console $ docker build --secret id=kube,env=KUBECONFIG . ``` When you use secrets from environment variables, you can omit the `env` parameter to bind the secret to a file with the same name as the variable. In the following example, the value of the `API_TOKEN` variable is mounted to `/run/secrets/API_TOKEN` in the build container. ```console $ docker build --secret id=API_TOKEN . ``` ### Target When consuming a secret in a Dockerfile, the secret is mounted to a file by default. The default file path of the secret, inside the build container, is `/run/secrets/<id>`. You can customize how the secrets get mounted in the build container using the `target` and `env` options for the `RUN --mount` flag in the Dockerfile. The following example takes secret id `aws` and mounts it to a file at `/run/secrets/aws` in the build container. ```dockerfile RUN --mount=type=secret,id=aws \ AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \ aws s3 cp ... ``` To mount a secret as a file with a different name, use the `target` option in the `--mount` flag. ```dockerfile RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \ aws s3 cp ... ``` To mount a secret as an environment variable instead of a file, use the `env` option in the `--mount` flag. ```dockerfile RUN --mount=type=secret,id=aws-key-id,env=AWS_ACCESS_KEY_ID \ --mount=type=secret,id=aws-secret-key,env=AWS_SECRET_ACCESS_KEY \ --mount=type=secret,id=aws-session-token,env=AWS_SESSION_TOKEN \ aws s3 cp ... ``` It's possible to use the `target` and `env` options together to mount a secret as both a file and an environment variable. ## SSH mounts If the credential you want to use in your build is an SSH agent socket or key, you can use the SSH mount instead of a secret mount. Cloning private Git repositories is a common use case for SSH mounts. The following example clones a private GitHub repository using a [Dockerfile SSH mount](/reference/dockerfile.md#run---mounttypessh). ```dockerfile # syntax=docker/dockerfile:1 FROM alpine ADD git@github.com:me/myprivaterepo.git /src/ ``` To pass an SSH socket the build, you use the [`docker build --ssh` flag](/reference/cli/docker/buildx/build.md#ssh), or equivalent options for [Bake](../bake/reference.md#targetssh). ```console $ docker buildx build --ssh default . ``` ## Git authentication for remote contexts BuildKit supports two pre-defined build secrets, `GIT_AUTH_TOKEN` and

This section elaborates on customizing secret mounts in Dockerfiles using the `target` and `env` options to specify file paths or environment variables. It provides examples of mounting secrets with different names and as environment variables. The section then introduces SSH mounts as an alternative for SSH agent sockets or keys, particularly for cloning private Git repositories, detailing the Dockerfile syntax and `docker build --ssh` flag. Finally, it mentions pre-defined build secrets for Git authentication in remote contexts.