Docker Build-Push-Action 中使用 Secrets 的权限问题解析

问题背景

在使用 Docker Build-Push-Action 构建镜像时，开发者尝试通过 secrets 机制将敏感信息传递到 Dockerfile 中使用。具体场景是在构建过程中需要访问 1Password 的服务账号令牌，用于注入配置文件。然而在实际操作中，遇到了 /run/secrets/OP_SERVICE_ACCOUNT_TOKEN: Permission denied 的错误。

技术分析

这个权限问题的根源在于基础镜像的选择。当使用 1password/op:2 作为基础镜像时，该镜像内部设置了特定的用户权限：

1. 该镜像默认使用 opuser 用户（UID=999，GID=999）运行
2. 默认情况下，BuildKit 挂载的 secrets 文件权限为 root 用户所有
3. 非 root 用户（如 opuser）没有权限读取这些 secrets 文件

解决方案

方案一：修改基础镜像

最简单的解决方案是更换基础镜像，例如使用 debian:bookworm-slim 等标准镜像，然后通过 bind mount 方式引入 op 二进制文件：

FROM debian:bookworm-slim

WORKDIR /opt/app
COPY . /opt/app

ARG ENVIRONMENT_NAME

RUN --mount=type=bind,from=1password/op:2,source=/usr/local/bin/op,target=/usr/bin/op \
    --mount=type=secret,id=OP_SERVICE_ACCOUNT_TOKEN \
  export OP_SERVICE_ACCOUNT_TOKEN=$(cat /run/secrets/OP_SERVICE_ACCOUNT_TOKEN) && \
  op inject -i src/elt_projects/dbt/profiles.${ENVIRONMENT_NAME}.yml -o src/elt_projects/dbt/profiles.yml --force

方案二：调整 secrets 挂载权限

如果必须使用原基础镜像，可以通过设置 secrets 挂载的 uid 和 gid 参数来匹配基础镜像中的用户：

FROM 1password/op:2

WORKDIR /opt/app
COPY . /opt/app

ARG ENVIRONMENT_NAME

RUN --mount=type=secret,id=OP_SERVICE_ACCOUNT_TOKEN,uid=999,gid=999 \
  export OP_SERVICE_ACCOUNT_TOKEN=$(cat /run/secrets/OP_SERVICE_ACCOUNT_TOKEN) && \
  op inject -i src/elt_projects/dbt/profiles.${ENVIRONMENT_NAME}.yml -o src/elt_projects/dbt/profiles.yml --force

最佳实践建议

1. 了解基础镜像的用户配置：在使用任何第三方基础镜像前，应该先了解其用户权限设置
2. 合理使用 secrets：确保 secrets 的挂载权限与容器内运行用户的权限匹配
3. 最小权限原则：即使需要调整权限，也应遵循最小权限原则，只授予必要的访问权限
4. 测试验证：在 CI/CD 流水线中，应该包含对 secrets 访问的测试验证步骤

总结

在 Docker Build-Push-Action 中使用 secrets 时，权限问题是一个常见但容易被忽视的细节。通过理解基础镜像的用户权限配置，并合理设置 secrets 挂载参数，可以有效地解决这类问题。对于需要特定权限设置的第三方镜像，开发者应该仔细查阅其文档或镜像配置，确保构建过程中的各项操作都有适当的权限支持。