Harbor原生支持TOTP多因素认证和项目级RBAC最小权限控制，可有效防范凭证盗用与越权操作；Docker Registry需依赖外部服务补足MFA，权限管理也更粗粒度。

私有镜像仓库要真正守住镜像资产安全，不能只靠“设个密码”或“开个HTTPS”。多因素认证（MFA）和最小权限管理是两个必须落地的硬性防线——前者防凭证被盗，后者防越权滥用。目前主流方案中，Harbor原生支持MFA集成（如TOTP、LDAP+AD双因子），并内置RBAC模型；Docker Registry本身不支持MFA，需通过Nginx反向代理+外部认证服务（如Keycloak）补足。

Harbor中启用TOTP多因素认证

Harbor v2.5+已将TOTP作为内置功能，无需额外组件：

• 在系统设置 → 认证模式中启用“本地DB + TOTP”混合认证
• 管理员为用户开启MFA后，用户首次登录会扫码绑定Google Authenticator等OTP客户端
• 后续每次登录除输入用户名/密码外，还需输入6位动态验证码
• 支持紧急恢复码（Recovery Codes），建议导出并离线保管

基于项目级RBAC实施最小权限控制

Harbor的权限粒度精确到“项目（Project）”，不是全局账号权限，这是实现最小权限的关键：

• 禁止使用admin账户日常操作：为开发、测试、运维分别创建专用机器人账号（Robot Account），每个仅授予对应项目的pull、push或admin权限
• 生产项目设为“私有”，关闭“公开访问”，所有拉取必须显式授权
• 敏感项目（如含数据库凭证的镜像）启用“内容信任（Notary）”，强制签名验证再拉取
• 定期审计：通过审计日志 → 筛选“project_admin”或“push_image”事件，检查异常时间、IP、高频推送行为

CI/CD流水线中的权限隔离实践

自动化流程最容易成为权限漏洞入口，必须切断“一账号打天下”的链路：

• Jenkins/GitLab CI使用Harbor生成的短期有效机器人账号（Token有效期设为24h），任务结束后自动失效
• 不同环境（dev/staging/prod）使用独立Harbor项目，CI脚本中通过环境变量注入对应项目的registry地址与token
• 禁止在Dockerfile或CI配置中硬编码凭据；改用Harbor的“扫描结果阻断”策略：若Clair扫描发现CVSS≥7.0漏洞，自动拒绝push

补充加固：客户端侧的权限约束

服务端再严，客户端疏忽也会导致泄露：

• Docker客户端配置文件~/.docker/config.json禁止存储多个仓库的凭据，尤其避免混用admin token
• 团队统一使用docker login --password-stdin配合管道注入token，避免命令历史留存密码
• 开发机安装Docker Desktop时，禁用“Securely store Docker logins in macOS keychain / Windows Credential Manager”选项，防止凭据被恶意程序提取