密钥轮转核心在于让旧凭证彻底失效、新凭证精准生效并同步更新所有环节。需区分仓库登录凭证、ci/cd令牌、运行时访问密钥三类，按权限与风险实施分级策略：高权限账号用≤24小时短期令牌，开发者本地禁用明文密码改用credential helper，构建密钥仅通过buildkit --secret注入；同步强制清理残留路径、扫描凭据文件、开启审计告警，并每季度开展失效演练验证轮转链路完整性。
密钥轮转不是“定期换密码”那么简单，而是要让旧凭证彻底失效、新凭证精准生效，并确保所有使用环节同步更新。核心在于切断旧密钥的访问路径，而不是只改一个地方。
明确密钥类型与作用域
私有仓库的密钥通常分三类，轮转策略必须区分对待：
-
仓库登录凭证：用于
docker login推送/拉取镜像，存储在~/.docker/config.json中的auths字段，Base64 编码但可逆，等同明文 - CI/CD 系统令牌：如 GitHub OIDC token、Jenkins 凭据、GitLab CI 变量，用于自动化构建和推送，生命周期应绑定 job 或 session
- 应用运行时访问密钥：容器启动后从仓库拉取配置、插件或依赖时使用的临时 token（例如通过 Vault 动态签发），不写入镜像，只在内存中短期存在
实施分级轮转策略
不同密钥按风险等级设定轮转周期和方式：
- 高权限仓库账户（如 admin、pusher）：强制启用短期令牌（TTL ≤ 24 小时），禁用长期密码；每次 CI 流水线运行前调用 IAM 服务（如 AWS STS、Azure AD）获取新 token，执行完立即失效
-
开发者本地凭证：禁用
docker login直接存密码；改用 credential helper（如ecr-login、docker-credential-gcr），登录时自动换取短期 registry token，过期后重新触发认证流程 -
基础镜像构建密钥：若需在
docker build阶段访问私有 Git 或 npm 源，仅允许 BuildKit--secret方式注入，且 secret 文件在构建结束后不残留，不参与镜像层生成
配套强制清理与验证机制
轮转本身不能代替清理，必须同步阻断历史密钥残留路径：
- 在 CI 流水线末尾增加清理步骤：
docker logout registry.example.com && rm -f ~/.docker/config.json，避免凭据被后续 job 复用 - 对所有构建节点启用文件扫描（如 Trivy config scan），定期检查
/root/.docker/config.json、/home/*/docker/config.json是否存在未授权 registry 条目 - 私有仓库（如 Harbor、Nexus）开启审计日志，设置告警规则：当同一账号出现异地登录、高频失败尝试、非工作时间 push 行为时自动通知并冻结该 token
- 每季度执行一次“凭证失效演练”：手动吊销某组测试 token，验证所有服务（CI、部署脚本、监控拉取）是否能自动刷新并恢复，否则视为轮转链路断裂
不复杂但容易忽略：轮转的关键不在频率，而在能否让旧密钥真正“死透”。只要有一个地方缓存了旧 token、一个脚本硬编码了密码、一个容器挂载了宿主机的 .docker 目录，整个轮转就形同虚设。
