企业级registry认证需通过独立中间层实现：docker_auth对接ldap/ad最轻量，harbor开箱即用支持项目级权限与安全功能，keycloak适用于oauth2统一认证；三者均需确保网络互通、tls有效及issuer严格匹配。
对接企业级认证中心不是给 Registry 直接“加个插件”，而是用独立认证服务做中间层——Registry 只管校验 Token，认证和权限逻辑全交给外部系统处理。
用 docker_auth 对接 LDAP/AD
这是最常用、最轻量的方案，适合已有 LDAP 或 Active Directory 的企业：
- 先跑一个 LDAP 容器（比如 osixia/openldap 或 lldap/lldap），确认基础 DN、管理员账号、用户结构（如 uid 属性）都清晰可查
- 部署 docker_auth，在它的 auth_config.yml 中填好 LDAP 地址、bind DN、密码文件路径，以及用户查询 filter（例如 (&(uid=${account})(objectClass=inetOrgPerson))）
- 关键要对齐：docker_auth 的 token.issuer 值（如 registry-auth），必须和 Registry 的 config.yml 中 auth.token.issuer 完全一致
- ACL 权限写在 docker_auth 配置里，支持用户名匹配、正则匹配（如 /^dev-.*/），但不自动识别 LDAP 组——需要把组信息映射到用户属性，或改 filter 加入组条件
用 Harbor 集成 LDAP/AD 或 OIDC
Harbor 是 CNCF 毕业项目，开箱即用，适合生产环境：
- 安装后进 Web 控制台，在“系统管理 → 认证模式”中切换为 LDAP 或 OIDC（支持 GitHub、GitLab、Keycloak 等）
- 填入 LDAP 服务器地址、Base DN、Manager DN 和密码；测试连接成功后，可预览同步的用户列表
- 权限控制落到“项目（Project）”级别：创建项目后，添加用户或 LDAP 组，并分配角色（访客、开发人员、维护者）
- 它还自带镜像扫描、不可变标签、操作审计日志，比纯 Registry + docker_auth 多一层安全兜底
用 Keycloak 实现 OAuth2 统一认证
适合已建好 Keycloak 的企业，或想统一管理多个系统登录的场景：
- 在 Keycloak 创建 Realm 和 Client（类型选 confidential），开启 Service Accounts，记下 client ID、secret 和 issuer URL
- 配置 docker_auth 的 auth_config.yml，把认证方式设为 oauth2，填入 Keycloak 的 token endpoint、client_id、client_secret
- Registry 的 config.yml 中 auth.token.realm、service、issuer 必须与 Keycloak 返回的 Token 声明严格一致（尤其是 issuer 字段）
- 权限仍靠 docker_auth 的 ACL 控制，也可以让 Keycloak 在 Token 中带自定义 claim（如 roles），再在 ACL 里用 ${claims.roles} 引用
客户端和网络连通性不能漏
再好的配置，如果链路不通也白搭：
- 确保 Registry 容器、docker_auth 容器、LDAP/Keycloak 容器在同一个 Docker 网络里，能用容器名互相访问（如 ldap:389、keycloak:8080）
- Registry 的 realm 地址必须是 HTTPS，且域名要能被客户端解析——本地测试可用自签名证书，但需提前把 CA 加入 Docker daemon 信任链
- 用户执行 docker login reg.example.com 时，实际是向 realm 地址发起请求获取 Token；若返回 401 或超时，优先检查网络、TLS、issuer 匹配这三项
