harbor以project为最小权限单元实现项目级rbac，通过创建隔离私有项目、禁用public空间、按角色分配最小权限（访客仅pull、开发者pull/push/scan、管理员限本项目）、启用内容信任与审计日志，构建精细化代码资产防护体系。
私有镜像仓库本身不支持项目级RBAC，必须依赖具备原生权限模型的仓库服务（如Harbor），而非Docker自带registry。真正防住代码资产外泄，关键不是“能不能拉”，而是“谁在什么项目里能推、删、扫描、配置策略”——权限必须按项目边界切分，且绑定最小动作集。
用Harbor创建隔离项目并关闭公共空间
Harbor以“Project”为最小权限单元，这是落地精细化控制的基础：
- 每个业务线、微服务或环境（dev/staging/prod）单独建一个私有项目，命名带前缀便于识别，例如 proj-finance-api、proj-ml-pipeline
- 禁用默认的 library（public）项目，防止成员误将含密镜像推到共享空间
- 项目设置中勾选“不可公开访问”，关闭“匿名用户可拉取”选项
- 启用“内容信任”开关，强制所有推送镜像必须经Cosign签名，未签名则拒绝入库
按角色分配最小权限，禁用个人长期凭证
权限矩阵要对齐实际职责，避免“一人一账号全通吃”：
- 访客：仅赋予 Pull 权限，适用于测试、运维等只读场景；不能看到镜像详情页的Dockerfile元数据（Harbor 2.8+ 支持隐藏Artifact详情）
- 开发者：赋予 Pull + Push + Scan，但禁止删除、禁止修改项目设置；CI流水线必须用机器人账号，而非开发者个人Token
- 项目管理员：可管理成员、配置扫描策略、设置保留规则，但无跨项目权限；不授予系统级“系统管理员”角色
- 所有机器人账号设90天自动过期，并绑定单一项目+指定动作（如仅允许
proj-payment:push），禁用全局Token
开启审计与策略即代码闭环验证
权限配得再细，没日志、不验证、不轮换，就等于没设防：
- 启用Harbor系统日志，重点采集
pull artifact、delete artifact、update project member三类事件 - 日志统一接入ELK，配置告警规则：例如“同一机器人账号1小时内触发5次push失败，且错误含
unauthorized”，说明权限配置异常或凭证失效 - 把项目YAML配置、机器人账号清单、签名策略（
cosign.yaml）全部纳入Git管理，每次变更走PR+自动校验 - 每季度执行一次权限验证：用curl模拟访客Token尝试push，用开发者Token尝试delete，确认行为与角色定义完全一致
补充防护：镜像构建阶段同步加固
仓库层权限只是最后一道门，代码资产早在构建时就可能泄露：
- Dockerfile中禁用
COPY . /app全量复制，改用精准路径，排除.env、secrets/等敏感目录 - 使用
COPY --chown=nonroot:nonroot显式降权，避免镜像内进程以root运行导致提权风险 - CI流程中禁用
aws_secret_access_key等明文环境变量注入，改用临时STS Token或HashiCorp Vault动态获取 - 对含数据库连接串、内部API密钥的镜像，额外打标签如
internal-only，并在Harbor项目策略中限制该标签镜像仅允许特定IP段拉取
