Docker镜像仓库应使用短期、可撤销、细粒度scope的JWT访问令牌替代静态密码以提升安全性；配置需依托支持Bearer认证的registry，通过平台CLI/API获取Token并Base64编码写入config.json，配合credential helper和环境变量注入实现安全实践。
Docker 镜像仓库配置访问令牌（Token）是提升安全性的关键手段，尤其在生产环境或 CI/CD 流水线中，应避免长期使用静态密码。Token 本质是短期、作用域受限的 JWT 凭据，由认证服务动态颁发，支持最小权限原则。
为什么用 Token 而不是密码？
密码一旦泄露或硬编码在脚本里，风险长期存在；而 Token 具备时效性（通常几小时到几天）、可撤销性、细粒度 scope（如仅限 pull 或指定仓库路径），且不需明文存储在 config.json 中。
如何配置 Token 访问私有仓库？
- 使用支持 OAuth/Bearer Token 的 registry（如 Harbor、GitLab Container Registry、ECR、GCR）
- 不直接调用
docker login输入密码，而是通过对应平台提供的 CLI 工具或 API 获取临时 Token - 将 Token 写入
~/.docker/config.json的auths字段，格式为 Base64 编码的username:token（注意：这里的 “username” 可能是服务账号名，token 本身替代密码）
例如，Harbor 用户可生成机器人账号（Robot Account），获取专属 Token：
{
"auths": {
"harbor.example.com": {
"auth": "dXNlcjpwYXNzd29yZC1vci10b2tlbg=="
}
}
}其中 dXNlcjpwYXNzd29yZC1vci10b2tlbg== 是 robot$demo:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... 的 Base64 编码结果。
推荐的安全实践
- 在 CI/CD 中，用环境变量注入 Token，配合
docker login --username $USER --password-stdin标准输入方式，避免命令行历史或日志泄露 - 使用 credential helper（如
ecr-login、gcr-login）自动刷新 Token，不依赖本地 config.json 存储长期凭据 - 定期轮换 Token，禁用不再使用的机器人账号或服务账号
- 配置 registry 的 scope 约束，例如只允许
repository:prod/app:pull，禁止push或其他命名空间操作
注意 Token 的生效前提
Registry 必须启用 Bearer 认证模式，并正确配置 WWW-Authenticate 响应头中的 realm 地址。客户端收到 401 后会自动向该 realm 请求 Token —— 这一过程对用户透明，但前提是底层认证服务（如 Dex、Keycloak 或 registry 自带 auth 模块）已就绪。
不复杂但容易忽略
