docker仓库认证不提供用户级权限隔离，需服务端rbac、客户端约束与运行时校验协同实现：harbor/aws ecr等服务端控制镜像访问；客户端用独立账号和凭据助手限制操作范围；运行时启用内容信任与opa策略校验镜像来源；审计日志与定期扫描确保行为可追溯。
在多用户共享的服务器上，docker 仓库认证本身不直接提供用户级权限隔离——config.json 是 per-user 的本地凭证文件，但它的内容（如 base64 编码的账号密码）只控制“谁能拉/推镜像”，不控制“能拉哪些镜像、能推到哪个项目、能否删除”。真正的隔离式权限控制，必须靠仓库服务端策略 + 客户端运行时约束协同实现。
一、服务端：用私有仓库内置 RBAC 实现镜像级隔离
不要依赖 Docker 客户端单点登录，而要把权限决策交给仓库本身：
- Harbor：为每个团队/租户创建独立项目（Project），设置成员角色（guest、developer、maintainer、admin）；启用“公开性”开关和“机器人账户”供 CI 使用；开启内容信任（Notary）防止篡改
-
AWS ECR：通过 IAM 策略精确控制 action（如
ecr:GetDownloadUrlForLayer）、resource（如arn:aws:ecr:us-east-1:123456789012:repository/myapp-*）、条件（如aws:RequestedRegion） -
自建 Registry + Auth 插件：例如用
registry:2配合token-auth-server或 Dex OIDC，把用户身份映射到命名空间（如tenant-a/app-web只允许 tenant-a 组访问）
二、客户端：限制每个用户能操作的 registry 和命名空间
避免用户手动修改 ~/.docker/config.json 覆盖他人凭证或越权访问：
- 禁止共享 Linux 用户账号；每个真实用户使用独立系统账号（
useradd -m alice），确保~/.docker/config.json文件属主唯一、权限为600 - 用 credential helper 替代明文存储：例如 AWS 用户配置
"credsStore": "ecr-login"，GCP 用户用gcloud auth configure-docker，凭证由系统密钥环托管，不落地 - 对敏感 registry（如生产镜像库），禁用
docker login交互式登录，改为分发短期 token 或机器人账户凭据，并绑定 IP/设备指纹
三、运行时：容器启动阶段二次校验镜像来源与签名
即使用户能 pull 下来镜像，也要阻止其运行未经批准的镜像：
- 在 Docker daemon 层启用 content trust：
{"icc":false,"live-restore":true,"notary":{"enabled":true}}，配合DOCKER_CONTENT_TRUST=1环境变量，强制只运行带签名的镜像 - 用 OPA（Open Policy Agent） 或 Gatekeeper 做 admission control：拦截
docker run请求，检查镜像 registry 域名、tag 是否匹配白名单（如仅允许harbor.internal/tenant-b/*:prod-v2） - 构建 CI 流水线时，在推送前自动打标签并签名：
docker trust sign harbor.internal/app/db:202610，再将公钥分发至各节点验证器
四、审计与兜底：行为可追溯、越权有阻断
权限不是设完就结束，得让每一次操作留痕且可控：
- 开启 Docker daemon 的 audit log（
--log-driver=syslog --log-opt syslog-address=udp://10.0.1.100:514），记录谁、何时、从哪台机器、pull 了哪个镜像 - 定期扫描所有节点上的本地镜像，比对是否来自授权 registry：用
skopeo list-tags docker://harbor.internal/base/python获取合法 tag 列表，脚本校验docker images输出 - 对高危操作（如
docker push到生产库）加二次确认或审批流，可集成 Slack webhook 或企业微信机器人
