如何在Azure Devops CI/CD流水线的docker构建过程中注入Vault密钥

注意：禁止将Vault Token、永久凭据等敏感信息写入Dockerfile或镜像层，避免凭据泄露风险

方案1：使用BuildKit秘密挂载（推荐，无凭据残留） #

• 本地提前获取有效期较短的Vault Token，确保该Token仅有数据库迁移所需密钥的只读权限
• 修改Dockerfile，声明需要挂载的秘密，添加Vault客户端安装和密钥拉取逻辑

# 基础镜像示例，根据你实际使用的基础镜像调整
FROM python:3.11-slim

# 安装Vault客户端（如果基础镜像没有的话）
RUN apt update && apt install -y vault && rm -rf /var/lib/apt/lists/*

# 声明构建时需要挂载的vault_token秘密
RUN --mount=type=secret,id=vault_token \
    # 从挂载的秘密文件读取Vault Token
    export VAULT_TOKEN=$(cat /run/secrets/vault_token) \
    # 配置Vault地址
    && export VAULT_ADDR=https://你的Vault服务地址 \
    # 拉取所需的数据库密钥，这里示例是kv v2引擎的路径，根据你实际路径调整
    && export DB_USER=$(vault kv get -field=username secret/db/migration) \
    && export DB_PASS=$(vault kv get -field=password secret/db/migration) \
    # 执行数据库迁移命令，这里示例用alembic，替换为你实际的迁移工具
    && alembic upgrade head

• 执行构建命令，通过BuildKit将Vault Token传递给构建过程，不会写入镜像层
  DOCKER_BUILDKIT=1 docker build --secret id=vault_token,env=VAULT_TOKEN .

该方案所有敏感变量仅在构建的RUN执行阶段存在，不会残留到镜像的任何层中，安全等级最高

方案2：多阶段构建临时传递（兼容旧版Docker） #

• 第一阶段为构建阶段，传入临时Vault Token拉取密钥执行迁移，第二阶段仅拷贝迁移后的产物，完全丢弃第一阶段的所有凭据信息

# 第一阶段：构建迁移阶段
FROM python:3.11-slim AS migration-builder
ARG VAULT_TOKEN
ARG VAULT_ADDR
RUN apt update && apt install -y vault && rm -rf /var/lib/apt/lists/*
# 拉取密钥执行迁移
RUN export VAULT_TOKEN=$VAULT_TOKEN && export VAULT_ADDR=$VAULT_ADDR \
    && export DB_USER=$(vault kv get -field=username secret/db/migration) \
    && export DB_PASS=$(vault kv get -field=password secret/db/migration) \
    && alembic upgrade head

# 第二阶段：最终镜像阶段，完全不包含第一阶段的凭据和环境变量
FROM python:3.11-slim
# 只拷贝需要的业务代码和迁移产物，不要拷贝第一阶段的任何凭据相关文件
COPY --from=migration-builder /app /app
CMD ["python", "main.py"]

• 执行构建命令传入参数
  docker build --build-arg VAULT_TOKEN=$VAULT_TOKEN --build-arg VAULT_ADDR=https://你的Vault服务地址 .

该方案需要确保你使用的Docker版本支持多阶段构建，且不要在最终镜像中打印或留存任何构建阶段的环境变量

最佳实践建议 #

• Vault Token使用短期有效期的单次 Token，执行完构建后立即失效，避免Token泄露风险
• 给Vault对应的迁移密钥路径配置最小权限原则，仅给构建所用的Token分配该路径的只读权限，不要分配其他路径的权限
• 不要在Dockerfile的任何ENV指令中存储敏感值，所有敏感变量仅在RUN指令执行时临时导出，用完即弃
• 构建完成后可以通过docker history 镜像名命令检查镜像层是否存在敏感信息泄露

内容的提问来源于stack exchange，提问作者Hardik Panchal