docker镜像仓库认证是一套基于令牌的动态分层架构，核心由registry、独立auth server和docker client协同完成：registry返回401并指定realm，client凭凭证向auth server换取短期jwt，再以bearer token重试请求；config.json仅存base64编码的初始凭据用于换token，token本身不落盘且具时效性。
Docker 镜像仓库认证不是“登录一次就永久有效”的简单密码校验，而是一套基于令牌（Token）的动态、分层、服务解耦的身份验证架构。它的设计目标是安全、可扩展、支持多租户和自动化场景。
Docker 镜像仓库认证的核心组件
Registry（镜像仓库服务）
负责存储和提供镜像数据（manifest、layers、config），本身不处理用户凭证。当收到未授权请求（如docker pull）时，它只做一件事：返回 HTTP 401 响应，并在WWW-Authenticate头中明确指出“去哪申请令牌”——例如：Bearer realm="https://auth.example.com/token",service="registry.example.com"
这个响应不暴露任何账号密码逻辑，纯粹是路由指令。Auth Server / Token Service（认证服务）
独立于 Registry 的服务，专门负责身份核验与令牌签发。它接收来自 Registry 的重定向请求，验证客户端提供的凭据（用户名/密码、access token、OAuth2 code、IAM role 等），然后颁发一个短期有效的 JWT（JSON Web Token）。该 Token 包含权限声明（如repository:myapp:pull,push），由 Registry 后续验证签名并执行授权。Docker Client（CLI 或 daemon）
自动完成整个流程：先尝试访问 Registry → 收到 401 → 解析realm和service→ 向 Auth Server 发起/token请求（附带凭证）→ 获取 Bearer Token → 在后续所有请求头中带上Authorization: Bearer <token></token>→ 完成操作。
认证信息怎么存？config.json 不是密码本
执行 docker login registry.example.com 后，凭证确实写入 ~/.docker/config.json，但要注意：
- 存的是 Base64 编码的
username:password，仅用于首次向 Auth Server 换取 Token，不是直接发给 Registry 的密码； - 客户端不会把
auth字段内容明文发给 Registry，而是用它去换 Token； - Token 本身不落盘（除非显式配置），每次拉取/推送都可能刷新，具备时效性（通常 15–60 分钟）；
- 若使用云厂商（如 AWS ECR），
docker login实际调用的是aws ecr get-login-password，生成的是临时 Token，连密码都不出现。
不同认证方式对应不同信任模型
Basic Auth（用户名+密码）
适合个人或小团队私有仓，依赖 HTTPS 保障传输安全；凭证长期有效，需配合强密码策略和定期轮换。Access Token / API Key
CI/CD 场景首选，可设置过期时间、绑定 IP 或 scope（如只允许pull），泄露影响可控。OAuth2 / SSO 集成（如 GitHub、LDAP、Azure AD）
企业级方案，用户不接触密码，权限由统一身份系统管控，支持单点登录与审计追踪。IAM Role / Instance Profile（云环境）
如 EC2 实例拉取 ECR 镜像时，无需显式登录，靠实例角色自动获取临时凭证，完全消除密钥硬编码风险。
这套架构让 Registry 保持轻量、专注存储，安全逻辑下沉到专用 Auth Server，既便于横向扩展，也利于对接企业已有身份体系。
