尧图网站建设 
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 权限评估器源码解释“角色即权限”背后的实现机制帮助读者既能按用例复现验证步骤也能理解权限判定在源码中的落点。测试目标与背景该用例的原始目标是原文 PurposeTo verify that a user with system admin role can delete other users projects when users are managed locally by Harbor (DB mode).即在用户由 Harbor 本地数据库管理DB 模式时验证拥有系统管理员角色的用户可以删除其他用户创建的项目。这里有两个关键前提概念系统管理员角色 ≠ 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 共同构成对系统管理员角色的完整能力验证。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 availableHarbor 以本地数据库做认证即auth_mode为db_auth一台安装了 Docker CLI 的 Linux 主机Docker 客户端至少两个非 admin 用户其中一个用户 M将被赋予系统管理员角色。原文档还有一条重要约束NOTE本测试中使用的非 admin 用户 M 不应与测试 2-24 中使用的非 admin 用户相同以避免会话缓存、浏览器 Cookie 等残留状态影响判定结果。完整测试步骤用例 2-34 自身的步骤非常简短为一个非 admin 用户 M 指派系统管理员角色system admin role使其以管理员身份活动重复测试 2-24 的全部步骤。由于“重复 2-24 的全部步骤”是本用例的实际操作主体下面按 2-24-admin-delete-projects.md 展开。2-24 中的注意事项同样适用用户 A 与项目 X 应替换为更长、更有辨识度的名字必须同时使用两种浏览器如 Chrome 与 Firefox保证会话相互独立不要在同一个浏览器的不同窗口/标签页中登录两个用户。完整操作流程如下以非 admin 用户 A 登录 UI创建项目 X使用户 A 拥有该项目的 project admin 角色在 Docker 客户端上以用户 A 登录并执行docker push推送一个镜像到项目 X例如projectX/myimage:v1执行docker pull验证镜像可正常拉取在 UI 中登出用户 A登录管理员用户本用例中即被赋予系统管理员角色的用户 M删除项目 X ——预期失败因为项目下还存在镜像应报错删除项目 X 下的所有镜像再次删除项目 X以管理员身份查看 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对任意resourceaction组合恒返回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。小结与验证要点验证点对应步骤预期系统管理员角色可代管他人项目步骤 7–9非 admin 用户 M 能执行项目删除流程非空项目禁止删除步骤 7项目下存在镜像时删除失败先清镜像再删项目步骤 8–9删除成功删除操作可审计步骤 10Dashboard 日志出现项目与镜像删除记录权限与用户名解耦源码admin 评估器 恒真放行仅排除 scanner-pull该用例的价值在于把“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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor 测试用例解析：系统管理员角色删除他人项目（DB 认证模式）的验证原理与源码实现
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 权限评估器源码解释“角色即权限”背后的实现机制帮助读者既能按用例复现验证步骤也能理解权限判定在源码中的落点。测试目标与背景该用例的原始目标是原文 PurposeTo verify that a user with system admin role can delete other users projects when users are managed locally by Harbor (DB mode).即在用户由 Harbor 本地数据库管理DB 模式时验证拥有系统管理员角色的用户可以删除其他用户创建的项目。这里有两个关键前提概念系统管理员角色 ≠ 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 共同构成对系统管理员角色的完整能力验证。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 availableHarbor 以本地数据库做认证即auth_mode为db_auth一台安装了 Docker CLI 的 Linux 主机Docker 客户端至少两个非 admin 用户其中一个用户 M将被赋予系统管理员角色。原文档还有一条重要约束NOTE本测试中使用的非 admin 用户 M 不应与测试 2-24 中使用的非 admin 用户相同以避免会话缓存、浏览器 Cookie 等残留状态影响判定结果。完整测试步骤用例 2-34 自身的步骤非常简短为一个非 admin 用户 M 指派系统管理员角色system admin role使其以管理员身份活动重复测试 2-24 的全部步骤。由于“重复 2-24 的全部步骤”是本用例的实际操作主体下面按 2-24-admin-delete-projects.md 展开。2-24 中的注意事项同样适用用户 A 与项目 X 应替换为更长、更有辨识度的名字必须同时使用两种浏览器如 Chrome 与 Firefox保证会话相互独立不要在同一个浏览器的不同窗口/标签页中登录两个用户。完整操作流程如下以非 admin 用户 A 登录 UI创建项目 X使用户 A 拥有该项目的 project admin 角色在 Docker 客户端上以用户 A 登录并执行docker push推送一个镜像到项目 X例如projectX/myimage:v1执行docker pull验证镜像可正常拉取在 UI 中登出用户 A登录管理员用户本用例中即被赋予系统管理员角色的用户 M删除项目 X ——预期失败因为项目下还存在镜像应报错删除项目 X 下的所有镜像再次删除项目 X以管理员身份查看 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对任意resourceaction组合恒返回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。小结与验证要点验证点对应步骤预期系统管理员角色可代管他人项目步骤 7–9非 admin 用户 M 能执行项目删除流程非空项目禁止删除步骤 7项目下存在镜像时删除失败先清镜像再删项目步骤 8–9删除成功删除操作可审计步骤 10Dashboard 日志出现项目与镜像删除记录权限与用户名解耦源码admin 评估器 恒真放行仅排除 scanner-pull该用例的价值在于把“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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考