构建机密
构建秘密是任何敏感信息,例如密码或 API 令牌,作为应用程序构建过程的一部分使用。
构建参数和环境变量不适合用于向构建传递秘密,因为它们会保留在最终镜像中。相反,您应该使用秘密挂载或 SSH 挂载,它们可以安全地将秘密暴露给您的构建。
构建秘密类型
- 秘密挂载是用于将秘密传递到构建中的通用挂载。秘密挂载从构建客户端获取秘密,并在构建指令执行期间,将其暂时提供给构建容器。这在例如您的构建需要与私有工件服务器或 API 通信时非常有用。
- SSH 挂载是特殊用途的挂载,用于在构建中提供 SSH 套接字或密钥。它们通常用于您需要在构建中获取私有 Git 仓库时。
- 远程上下文的 Git 身份验证是一组预定义的秘密,用于您使用远程 Git 上下文(也是私有仓库)进行构建时。这些秘密是“预检”秘密:它们不在您的构建指令中消耗,但它们用于向构建器提供获取上下文所需的凭据。
使用构建秘密
对于秘密挂载和 SSH 挂载,使用构建秘密是一个两步过程。首先,您需要将秘密传递到 docker build 命令中,然后您需要在 Dockerfile 中使用该秘密。
要将秘密传递给构建,请使用 docker build --secret 标志,或 Bake 的等效选项。
$ docker build --secret id=aws,src=$HOME/.aws/credentials .
variable "HOME" {
default = null
}
target "default" {
secret = [
"id=aws,src=${HOME}/.aws/credentials"
]
}要在构建中消耗秘密并使其可访问 RUN 指令,请在 Dockerfile 中使用 --mount=type=secret 标志。
RUN --mount=type=secret,id=aws \
AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \
aws s3 cp ...秘密挂载
秘密挂载将秘密作为文件或环境变量暴露给构建容器。您可以使用秘密挂载将敏感信息(例如 API 令牌、密码或 SSH 密钥)传递到您的构建中。
来源
秘密的来源可以是文件或环境变量。当您使用 CLI 或 Bake 时,可以自动检测类型。您也可以使用 type=file 或 type=env 明确指定。
以下示例将环境变量 KUBECONFIG 挂载到秘密 ID kube,作为构建容器中 /run/secrets/kube 处的文件。
$ docker build --secret id=kube,env=KUBECONFIG .
当您使用环境变量中的秘密时,您可以省略 env 参数,以将秘密绑定到与变量同名的文件。在以下示例中,API_TOKEN 变量的值挂载到构建容器中的 /run/secrets/API_TOKEN。
$ docker build --secret id=API_TOKEN .
目标
在 Dockerfile 中使用秘密时,默认情况下秘密会挂载到文件中。秘密在构建容器内的默认文件路径是 /run/secrets/<id>。您可以使用 Dockerfile 中 RUN --mount 标志的 target 和 env 选项来自定义秘密在构建容器中的挂载方式。
以下示例获取秘密 ID aws 并将其挂载到构建容器中 /run/secrets/aws 处的文件。
RUN --mount=type=secret,id=aws \
AWS_SHARED_CREDENTIALS_FILE=/run/secrets/aws \
aws s3 cp ...要以不同名称将秘密挂载为文件,请在 --mount 标志中使用 target 选项。
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials \
aws s3 cp ...要将秘密挂载为环境变量而不是文件,请在 --mount 标志中使用 env 选项。
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 ...可以同时使用 target 和 env 选项将秘密同时挂载为文件和环境变量。
SSH 挂载
如果您想在构建中使用的凭据是 SSH 代理套接字或密钥,您可以使用 SSH 挂载而不是秘密挂载。克隆私有 Git 仓库是 SSH 挂载的常见用例。
以下示例使用 Dockerfile SSH 挂载克隆私有 GitHub 仓库。
# syntax=docker/dockerfile:1
FROM alpine
ADD git@github.com:me/myprivaterepo.git /src/要将 SSH 套接字传递给构建,您可以使用 docker build --ssh 标志,或 Bake 的等效选项。
$ docker buildx build --ssh default .
远程上下文的 Git 身份验证
BuildKit 支持两个预定义的构建秘密:GIT_AUTH_TOKEN 和 GIT_AUTH_HEADER。当您使用远程私有 Git 仓库进行构建时,包括以下情况,请使用它们来指定 HTTP 身份验证参数:
- 将私有 Git 仓库作为构建上下文进行构建
- 使用
ADD在构建中获取私有 Git 仓库
例如,假设您在 https://gitlab.com/example/todo-app.git 上有一个私有 GitLab 项目,并且您想使用该仓库作为构建上下文运行构建。未经验证的 docker build 命令会失败,因为构建器未获得拉取仓库的授权。
$ docker build https://gitlab.com/example/todo-app.git
[+] Building 0.4s (1/1) FINISHED
=> ERROR [internal] load git source https://gitlab.com/example/todo-app.git
------
> [internal] load git source https://gitlab.com/example/todo-app.git:
0.313 fatal: could not read Username for 'https://gitlab.com': terminal prompts disabled
------
要向 Git 服务器验证构建器身份,请将 GIT_AUTH_TOKEN 环境变量设置为包含有效的 GitLab 访问令牌,并将其作为秘密传递给构建。
$ GIT_AUTH_TOKEN=$(cat gitlab-token.txt) docker build \
--secret id=GIT_AUTH_TOKEN \
https://gitlab.com/example/todo-app.git
GIT_AUTH_TOKEN 也适用于 ADD,可在您的构建中获取私有 Git 仓库。
FROM alpine
ADD https://gitlab.com/example/todo-app.git /srcHTTP 身份验证方案
默认情况下,通过 HTTP 的 Git 身份验证使用 Bearer 身份验证方案。
Authorization: Bearer <GIT_AUTH_TOKEN>如果您需要使用带有用户名和密码的基本方案,您可以设置 GIT_AUTH_HEADER 构建秘密。
$ export GIT_AUTH_TOKEN=$(cat gitlab-token.txt)
$ export GIT_AUTH_HEADER=basic
$ docker build \
--secret id=GIT_AUTH_TOKEN \
--secret id=GIT_AUTH_HEADER \
https://gitlab.com/example/todo-app.git
BuildKit 目前只支持 Bearer 和 Basic 方案。
多个主机
您可以按每个主机设置 GIT_AUTH_TOKEN 和 GIT_AUTH_HEADER 秘密,这允许您对不同的主机名使用不同的身份验证参数。要指定主机名,请将主机名作为后缀附加到秘密 ID:
$ export GITLAB_TOKEN=$(cat gitlab-token.txt)
$ export GERRIT_TOKEN=$(cat gerrit-username-password.txt)
$ export GERRIT_SCHEME=basic
$ docker build \
--secret id=GIT_AUTH_TOKEN.gitlab.com,env=GITLAB_TOKEN \
--secret id=GIT_AUTH_TOKEN.gerrit.internal.example,env=GERRIT_TOKEN \
--secret id=GIT_AUTH_HEADER.gerrit.internal.example,env=GERRIT_SCHEME \
https://gitlab.com/example/todo-app.git