Docker仓库认证安全需系统性防护：凭据改用系统密钥管理器存储、私有仓库强制HTTPS+认证、权限按角色最小化分配、镜像须扫描签名验证。
直接说重点：docker 仓库认证安全不是“设个密码就完事”，而是要从凭据存储、传输、使用、权限四个环节系统性堵漏。最常被忽视的，是本地 ~/.docker/config.json 文件的明文（base64 编码）凭据和私有仓库未启用 tls/认证导致的裸奔暴露。
凭据不存文件，改用系统密钥管理器
Docker 默认把用户名密码 Base64 编码后写进 config.json，等于锁门只用一张纸片遮住钥匙孔。攻击者只要能读这个文件（比如 CI 节点残留、容器挂载宿主机目录、多用户共享服务器），就能秒解出明文账号密码。
- Linux 推荐配置
docker-credential-pass，配合 GPG 加密存储，凭据不落地 - macOS 启用
osxkeychain，凭据自动交由系统钥匙串保护 - Windows 使用
wincred，集成 Windows 凭据管理器 - 配置方式：修改
~/.docker/config.json，添加"credsStore": "osxkeychain"（对应平台）
私有仓库必须强制 HTTPS + 认证，禁用裸 HTTP
用 docker run -p 5000:5000 registry:2 启的默认仓库，本质是“把镜像货架摆在大街上”。攻击者 curl 一下 /v2/_catalog 就能列出所有镜像，再 curl 几次就能下载全部层数据。
- 必须用 TLS 证书反向代理（如 Nginx + Let's Encrypt），将 5000 端口仅限内网或通过 HTTPS 暴露
- 启用 Basic Auth（如 htpasswd）或更优的 Token 认证（Harbor / Docker Registry v2 的 auth service）
- 防火墙严格限制访问源 IP，禁止公网直接暴露 5000/8443 等 registry 端口
- Harbor 部署时务必开启“内容信任（Content Trust）”和“漏洞扫描阻断”策略
拉取与推送操作全程最小权限控制
一个用于 CI 流水线的机器人账号，不该拥有删除镜像或推送任意命名空间的权限；开发人员本地账号也不该有生产环境镜像仓库的写权限。
- 为不同角色创建专用服务账户（Service Account），按需分配
pull/push/delete权限 - 避免长期使用个人账号凭证，优先采用短期令牌（如 AWS ECR 的
get-login-password、Harbor 的 robot account） - CI/CD 中禁止硬编码凭证，改用 Secret 注入（Kubernetes Secret、GitLab CI Variables 加密变量、HashiCorp Vault）
- 禁止在 Dockerfile 或 shell 脚本中 echo 凭据、打印 config.json 内容——日志一落盘就等于泄露
自动化扫描与签名验证不能跳过
就算凭据守住了、仓库封好了，如果拉取的镜像是带后门的，一切防护都归零。供应链攻击往往始于一个被污染的基础镜像。
- 所有镜像入库前强制扫描：Harbor 自带 Clair 或集成 Trivy，设置 CVSS ≥7.0 的高危漏洞自动拦截
- 启用 Docker Content Trust（
DOCKER_CONTENT_TRUST=1）或 Harbor Notary，确保拉取的镜像经过可信签名 - 基础镜像统一由安全团队维护并定期更新，禁止开发人员随意 FROM 公共仓库的
latest标签 - 定期审计镜像层构成：
docker history image-name查看是否含可疑命令（如curl | bash、apt install wget）
