企业官网建设流程全解析

Harbor 测试用例解析：系统管理员角色删除他人项目（DB 认证模式）的验证原理与源码实现

【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor

本文围绕 Harbor 集成测试用例 2-34-admin-role-delete-projects.md 展开，说明在本地数据库认证（db_auth）模式下，如何验证一个被赋予“系统管理员”（System Admin）角色的非 admin 用户具备与 admin 用户完全相同的项目删除权限；同时结合 Harbor 的 RBAC 权限评估器源码，解释“角色即权限”背后的实现机制，帮助读者既能按用例复现验证步骤，也能理解权限判定在源码中的落点。

测试目标与背景

该用例的原始目标是（原文 Purpose）：

To verify that a user with system admin role can delete other user's projects when users are managed locally by Harbor (DB mode).

即：在用户由 Harbor 本地数据库管理（DB 模式）时，验证拥有系统管理员角色的用户可以删除其他用户创建的项目。

这里有两个关键前提概念：

1. 系统管理员角色 ≠ admin 用户。Harbor 内置一个特殊的admin用户，但系统管理员是一种可分配给任意用户的角色。本用例特意使用一个非 admin 用户（记为用户 M）并为其指派系统管理员角色，以证明权限来自“角色”而非“用户名”。这与同组的 2-31-admin-role-view-project.md、2-32-admin-role-search-projects.md、2-33-admin-role-delete-images.md 共同构成对系统管理员角色的完整能力验证。
2. DB 认证模式。用例要求auth_mode设置为db_auth，用户数据存储在 Harbor 本地数据库中。从源码看，这也是系统默认值：配置元数据定义 中AUTH_MODE的DefaultValue即为db_auth，可选值还有ldap_auth、oidc_auth等；用户配置实现 在未显式配置时同样回落到db_auth。

环境要求

按原文档 Environment 小节，执行该测试需要：

• 两台正在运行且可用的 Harbor 实例（用例原文要求 two(2) Harbor instances are running and available）；
• Harbor 以本地数据库做认证，即auth_mode为db_auth；
• 一台安装了 Docker CLI 的 Linux 主机（Docker 客户端）；
• 至少两个非 admin 用户，其中一个（用户 M）将被赋予系统管理员角色。

原文档还有一条重要约束（NOTE）：本测试中使用的非 admin 用户 M 不应与测试 2-24 中使用的非 admin 用户相同，以避免会话缓存、浏览器 Cookie 等残留状态影响判定结果。

完整测试步骤

用例 2-34 自身的步骤非常简短：

1. 为一个非 admin 用户 M 指派系统管理员角色（system admin role），使其以管理员身份活动；
2. 重复测试 2-24 的全部步骤。

由于“重复 2-24 的全部步骤”是本用例的实际操作主体，下面按 2-24-admin-delete-projects.md 展开。2-24 中的注意事项同样适用：用户 A 与项目 X 应替换为更长、更有辨识度的名字；必须同时使用两种浏览器（如 Chrome 与 Firefox）保证会话相互独立，不要在同一个浏览器的不同窗口/标签页中登录两个用户。

完整操作流程如下：

1. 以非 admin 用户 A 登录 UI；
2. 创建项目 X，使用户 A 拥有该项目的 project admin 角色；
3. 在 Docker 客户端上以用户 A 登录并执行docker push，推送一个镜像到项目 X，例如projectX/myimage:v1；
4. 执行docker pull，验证镜像可正常拉取；
5. 在 UI 中登出用户 A；
6. 登录管理员用户（本用例中即被赋予系统管理员角色的用户 M）；
7. 删除项目 X ——预期失败（因为项目下还存在镜像，应报错）；
8. 删除项目 X 下的所有镜像；
9. 再次删除项目 X；
10. 以管理员身份查看 Dashboard 的操作日志，应能看到项目 X 及其镜像的删除操作记录。

预期结果

原文档 Expected Outcome 小节指出：

• 拥有系统管理员角色的用户可以执行与 admin 用户完全相同的所有操作（Same as Test 2-24）；
• 步骤 7：删除项目 X 应当失败，因为项目下仍有镜像；
• 步骤 8–9：先删除项目 X 的所有镜像、再删除项目 X，应当成功；
• 步骤 10：日志中应当出现项目 X 的删除及镜像删除操作记录。

从测试预期可以看出，Harbor 对项目删除采取保守策略：项目非空时删除会被拒绝，需先清空其下的镜像，删除行为同时会被审计日志留痕。用例本身将 Possible Problems 标记为 None，说明在满足环境条件时该流程不存在已知的干扰项。

源码解析：系统管理员角色为什么等价于 admin

用例的核心断言是“非 admin 用户只要被授予系统管理员角色，就拥有 admin 的完整能力”。这一断言在源码中有清晰的落点。

权限评估器：对系统管理员直接放行

Harbor 在 src/pkg/permission/evaluator/admin/admin.go 中定义了针对系统管理员的专用权限评估器：

// Evaluator the permission evaluator for the system administrator type Evaluator struct { username string } // HasPermission always return true for the system administrator func (e *Evaluator) HasPermission(_ context.Context, resource types.Resource, action types.Action) bool { log.Debugf("system administrator %s require %s action for resource %s", e.username, action, resource) // scanner-pull is for scanner to bypass the policy checking so admin user should not have this permission return action != rbac.ActionScannerPull }

从这段实现可以看到：

• 评估器结构体只持有一个username字段，用于打调试日志，判定逻辑与用户身份无关——只要当前用户是系统管理员，HasPermission对任意resource+action组合恒返回true；
• 唯一的例外是ActionScannerPull：该动作本来是供漏洞扫描器绕过策略检查使用的内部通道，源码注释明确说明 admin 用户不应拥有它；
• 也就是说，用户 M（非 admin 用户名）一旦被识别为系统管理员，其在删除他人项目时会走这条“恒真”分支，效果与 admin 用户完全一致——这正是用例步骤 7–10 能通过的原因。

系统命名空间策略：项目删除是系统级动作之一

系统管理员可操作的资源范围由系统命名空间的策略表定义。在 src/common/rbac/system/policies.go 中：

{Resource: rbac.ResourceProject, Action: rbac.ActionCreate}, {Resource: rbac.ResourceProject, Action: rbac.ActionRead}, {Resource: rbac.ResourceProject, Action: rbac.ActionUpdate}, {Resource: rbac.ResourceProject, Action: rbac.ActionDelete}, {Resource: rbac.ResourceProject, Action: rbac.ActionList},

ResourceProject上完整挂载了 Create / Read / Update /Delete/ List 五个动作，其中ActionDelete就是本用例验证的“删除他人项目”权限。该策略表还覆盖了用户、用户组、Registry、复制策略、GC、扫描等系统级资源，说明系统管理员角色的能力面远不止项目删除。命名空间本身的注册见 src/common/rbac/system/namespace.go，系统资源的统一前缀为/system。

DB 认证模式的前置作用

用例强调db_auth是验证前提。从 配置元数据 可见，AUTH_MODE是用户作用域（UserScope）下不可在线编辑（Editable: false）的基础配置，需在部署/初始化阶段通过环境（如 harbor.yml 中的auth_mode）确定。在 DB 模式下，用户与角色都落在本地数据库中，因此“为任意用户 M 指派系统管理员角色”这一操作才能在 Harbor 内部闭环完成，这也解释了为何同组用例按 DB / LDAP 两种认证方式各写一套（如 2-24 与 2-16）。

小结与验证要点

该用例的价值在于把“RBAC 中的角色与内置 admin 用户等价”这一设计点固化成了可回归的自动化验证：既覆盖了 UI 侧的删除、日志查看等完整操作链路，又通过db_auth环境与双浏览器会话的约束排除了认证与会话干扰。结合 权限策略表 与 管理员评估器 两处源码，可以确认 Harbor 对系统管理员采用“默认放行 + 少量例外”的粗粒度策略，而非逐条策略匹配，这是阅读和验证 Harbor 权限行为时值得记住的底层前提。

【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor