docker镜像仓库访问控制需“认证+授权”分层落实：先通过htpasswd、客户端证书或oauth2/ldap完成身份核验，再依scope、仓库acl或rbac实施细粒度权限控制，并辅以https、短时token、审计日志和镜像扫描等安全加固措施。
Docker 镜像仓库访问控制的核心是“认证 + 授权”，不能只靠密码或网络隔离，必须分层落实：先确认你是谁（认证），再决定你能做什么（授权）。
基础认证：让 Registry 知道你是谁
Registry 本身不管理用户，需借助外部机制完成身份核验。常见方式有：
-
htpasswd 文件认证：适合中小团队。用
htpasswd -Bbn username password > htpasswd生成密码文件，启动时通过环境变量挂载：REGISTRY_AUTH=htpasswd、REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd。 - TLS 客户端证书：生产环境推荐。每个客户端持有唯一证书，Registry 验证证书签名和 CN 字段，无需用户名密码，天然防爆破。
- OAuth2 或 LDAP 集成：适用于已有统一身份系统的企业。Registry 作为资源服务器，把认证委托给 Keycloak、AD 或 GitLab 等服务，支持单点登录和账号生命周期同步。
细粒度授权：按角色分配具体操作权限
认证通过后，Registry 根据 Token 中的 scope 字段判断操作范围。关键控制点包括：
-
作用域（scope）控制：Token 请求中明确指定如
repository:myapp/frontend:pull或repository:infra/redis:push,pull，Registry 仅允许对应仓库和动作。 -
仓库级 ACL 配置：在
config.yml中设置allow-nondistributable-artifacts，限制含敏感层的镜像只能被特定网段或域名访问，例如：["10.10.0.0/16", "prod-registry.internal"]。 -
RBAC 权限映射：若使用 Harbor 等增强型仓库，可为用户组分配“项目管理员”“开发者”“只读成员”等角色，直接控制 push/pull/delete 权限，甚至细化到标签正则匹配（如仅允许推送
^v[0-9]+\.[0-9]+\.[0-9]+$格式版本号）。
客户端凭证安全存储与使用
本地 Docker 客户端需正确保存并自动携带凭证，避免硬编码或明文泄露：
- 执行
docker login registry.example.com后，凭证默认写入~/.docker/config.json，其中auth字段为 Base64 编码的username:password； - 推荐启用
credsStore（如"credsStore": "desktop"或"secretservice"），交由系统钥匙串管理，避免配置文件暴露； - CI/CD 场景下，应使用短期有效的 Token 或 robot 账号，并通过 secret 注入，禁止将
config.json提交至代码库。
生产环境必须配套的安全加固项
光配权限不够，还需闭环防护：
-
强制 HTTPS：HTTP 下所有认证凭据明文传输，必须配置 TLS 证书，且客户端需信任该证书（或配置
--insecure-registry仅限测试）； - Token 有效期限制：认证服务签发 JWT 时设短过期时间（如 24 小时），避免长期有效凭证泄露造成持续风险；
- 审计日志开启：Registry 可配置日志输出 pull/push/delete 操作的 IP、用户、镜像名和时间，对接 ELK 或 SIEM 系统做行为分析；
- 镜像扫描前置：在 push 流程中集成 Trivy 或 Clair 扫描，拒绝含高危漏洞或违规许可证的镜像入库，从源头控权。
