私有仓库账号权限管理核心是认证方式、权限粒度、服务端策略与客户端行为四者协同：htpasswd适用于测试，token（pat/robot account/iam）更安全可限权，ldap/oidc支持企业统一身份；harbor按项目角色分级授权，原生registry需nginx或docker_auth实现细粒度控制；凭证须禁明文、用password-stdin、config.json设600权限；生产必须https并审计日志。
私有仓库的账号权限管理与访问控制，核心是让不同角色的人或系统，在正确的时间、以正确的方式，对正确的镜像执行正确的操作。它不是简单地“设个密码”，而是围绕认证方式、权限粒度、服务端策略和客户端行为四者协同设计。
明确认证机制类型
私有仓库不统一用账号密码登录，选错方式会导致登录失败或权限失效：
-
基础认证（htpasswd）：适合小团队或测试环境。用
apache2-utils生成registry.password文件，启动 registry 时通过REGISTRY_AUTH=htpasswd指定路径 - Token 认证：Harbor 支持 robot account，Docker Hub 推荐 PAT，ACR/ECR 使用 AccessKey 或 IAM Role。这类凭据可设有效期、限操作范围，比明文密码更安全
- LDAP / AD 集成：企业已有域账号体系时，Harbor、Nexus 等可直连，用户用统一工号登录，权限自动映射到项目角色
- OIDC / OAuth2：Harbor 2.0+、ECR 支持 GitHub/GitLab 或企业 IdP 登录，一次认证换取短期 JWT，适合 SSO 场景
配置细粒度访问权限
权限必须由服务端定义并强制执行，客户端无法绕过：
- Harbor 按“项目（Project）”组织镜像，用户在项目中被赋予 访客、开发者、维护者、项目管理员 四类角色，分别对应 pull、push+pull、push+pull+delete、全权限
- 原生 Registry v2 不自带 RBAC，需借助 Nginx 代理 + htpasswd 实现用户分组，或接入
docker_auth等第三方认证服务实现作用域（scope）级权限，如repository:myapp:pull - 云厂商 ACR/TCR/ECR 使用 RAM 或 IAM 策略，可精确控制到命名空间、镜像名、操作类型（
pullImage、pushImage、DeleteRepository）
保障凭证安全与客户端合规使用
再强的服务端策略，也会因客户端误操作而失效：
- 禁止在命令行中明文写密码：
docker login --password mypass reg.example.com会泄露在 bash history 和进程列表中 - 推荐非交互式登录：
echo "$TOKEN" | docker login --username robot$project --password-stdin reg.example.com，配合 CI/CD 变量注入 - 登录成功后，Docker 自动将 base64 编码后的凭据存入
~/.docker/config.json，注意该文件权限应为600，避免被其他用户读取 - 内网 HTTP 仓库需在
/etc/docker/daemon.json中显式声明"insecure-registries"，否则 Docker 守护进程直接拒绝连接
配套运维与审计要求
权限管理不是一劳永逸，需持续验证与追踪：
- 所有 push/pull/delete 操作应记录完整日志，Harbor 提供审计日志界面，原生 registry 需结合 Nginx access log 或
loglevel配置 - 定期轮换 robot account Token、AccessKey、LDAP 绑定密钥，避免长期有效凭据成为风险点
- 生产环境必须启用 HTTPS，自签名证书需在每台客户端机器的 Docker daemon 中信任（
ca.crt复制到/etc/docker/certs.d/reg.example.com:443/） - 防火墙仅开放 registry 所需端口（如 443 或 5000），限制来源 IP 范围，尤其对公网暴露的 Harbor 实例
