必须集成ldap或oidc，因其可复用企业统一身份源，解决内置账号导致的密码分散、权限回收滞后、无法批量授权及审计缺失等问题；ldap适用于对接ad/自有目录服务，oidc适用于已有sso平台或多租户场景，二者均支撑基于组织架构的细粒度、可审计权限管控。
容器镜像仓库要实现安全、可审计的权限管控，关键不是只设个密码，而是把身份认证和权限策略真正“接进”企业已有体系。LDAP 和 OIDC 是目前最主流的两种集成方式，它们分别适用于不同场景，但目标一致：复用统一身份源，避免账号孤岛，让权限分配有据可依、可管可控。
为什么必须集成 LDAP 或 OIDC？
单纯用仓库内置用户，会带来明显问题：密码分散管理、离职人员权限难及时回收、无法按组织架构批量授权、审计日志缺乏可信身份上下文。而 LDAP（对接 AD/LDAP 服务器）和 OIDC（对接 Keycloak、Auth0、企业微信/钉钉开放平台等）能直接拉取真实组织结构中的用户与组信息，使镜像仓库成为身份体系的“下游消费者”，而非独立系统。
LDAP 集成实操要点
以 Harbor 为例，启用 LDAP 后，用户登录即触发绑定查询，权限由“项目 + 用户所属 LDAP 组”共同决定：
- 配置时需明确指定用户搜索 DN（如 ou=dev,dc=corp,dc=com）、组搜索基础路径及成员属性（常见为 memberOf 或 member）
- 务必关闭匿名绑定，启用 TLS 加密通信（LDAPS 或 StartTLS），防止凭证明文传输
- 在 Harbor 的“项目”中，可将整个 LDAP 组（如 cn=backend-team,ou=groups,dc=corp,dc=com）直接绑定为 “Developer” 角色，无需逐个添加用户
- 建议同步开启“自动用户创建”，避免首次登录失败；同时设置“LDAP 用户仅读”策略，禁止其修改自身资料，确保主目录权威性
OIDC 集成适用场景与配置关键
OIDC 更适合已有现代化单点登录（SSO）平台的企业，或需要支持多租户、第三方应用接入的场景：
- Harbor 或 Quay 配置 OIDC 时，核心参数包括 Issuer URL、Client ID、Client Secret 和 CA 证书（用于验证 ID Token 签名）
- 用户首次登录会跳转至 OIDC 提供商完成认证，成功后 Harbor 根据 ID Token 中的 groups 或 roles 声明字段，映射到本地角色（如把 token 中的 "role": "ci-pusher" 映射为 Harbor 的 Project Maintainer）
- 推荐使用 scope=openid profile email groups 请求用户属性，确保组信息可被正确提取
- OIDC 模式下，建议启用“ID Token 过期时间校验”和“签发者校验”，防止伪造 token 接入
权限落地：从认证到细粒度控制
认证只是第一步，真正的分职权管理体现在后续动作上：
- Harbor 中每个项目可独立配置成员角色（Guest、Developer、Maintainer、Project Admin），且支持基于标签的推送限制（如只允许 prod-* 标签推送到生产项目）
- 结合 Notary 或 Cosign，对特定项目启用内容信任，要求所有推送镜像必须签名，未签名则拒绝 pull
- 通过 Webhook + 外部审批服务（如 Jenkins 或自研审批流），对 delete 或 tag overwrite 操作强制人工确认
- 所有操作日志（谁、何时、对哪个镜像、执行了什么动作）均关联真实 LDAP/OIDC 用户标识，满足等保与 SOC2 审计要求
