Harbor 数据库认证模式下管理员管理项目成员实战指南DB 模式 RBAC 测试用例深度解析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor导读本文以 Harbor 开源仓库中的系统测试用例 3-11-DB-admin-user-manage-project-members.md 为核心完整还原管理员在本地数据库认证db_auth模式下为项目添加不同角色成员并验证各角色在 Docker CLI 侧 push/pull 权限的端到端验证流程。文章将逐一拆解测试步骤的意图、底层角色模型的实现依据与预期结果帮助读者掌握 Harbor 项目成员管理RBAC的完整链路并可直接在自建 Harbor 环境中复现该测试。一、测试场景概述DB 模式下的项目成员管理1.1 测试目的该测试用例验证一个核心能力当 Harbor 使用本地数据库auth_mode db_auth管理用户时系统管理员可以将不同角色的成员加入任意项目且各角色的实际权限推拉镜像与 UI 中展示的角色一致。用户数据完全存储在 Harbor 自己的本地数据库中不依赖任何外部认证源如 LDAP、OIDC、UAA。在 Harbor 源码中数据库认证模式的定义位于 src/common/const.goDBAuth db_auth。该常量是 Harbor 系统配置项auth_mode的合法取值之一也是本测试前提条件的源码依据。1.2 测试环境要求根据测试用例文档复现本测试需要满足以下环境条件条件说明Harbor 实例已运行且可通过 Web UI 与 Docker CLI 访问认证模式auth_mode设置为db_auth用户数据存于本地数据库Docker 客户端一台装有 Docker CLI 的 Linux 主机非管理员用户至少 3 个非系统管理员用户下文称 A、B、C目标项目至少 1 个管理员当前不是其成员的项目下文称项目 X1.3 测试操作约定重要注意事项原文档对测试过程有明确约定复现时务必遵守测试中的用户 A、B、C 是非系统管理员用户实际执行时应将 A、B、C 与项目 X 替换为更长、更有意义的名称如dev_alice、dev_bob、qa_carol与demo-project。必须同时使用两种浏览器来保持两个独立的 Web 会话例如 Chrome Firefox或 Chrome Safari。严禁在同一浏览器的不同窗口标签页中同时登录两个用户否则会话会相互覆盖导致角色验证结果失真。这一约定的本质是Harbor 的 Web 会话基于 Cookie 隔离不同浏览器代表不同会话从而可以同时观察管理员修改角色与成员侧视角两个界面实时校验角色变更是否即时生效。二、角色模型基础Harbor 项目成员的三种角色在深入测试步骤之前先明确 Harbor 中项目成员角色的底层定义。角色常量定义在 src/common/const.goRoleProjectAdmin 1 RoleDeveloper 2 RoleGuest 3 RoleMaintainer 4 RoleLimitedGuest 5本测试聚焦其中的三种经典角色角色常量值权限要点项目管理员Project Admin1项目的最高权限角色可管理项目成员、配置、镜像等开发者Developer2可推送push与拉取pull镜像可编辑镜像信息访客Guest3只读角色可拉取pull镜像不可推送push注Maintainer4与LimitedGuest5是 Harbor 后续版本引入的角色本测试用例编写时期主要覆盖 1/2/3 三种角色。从源码结构看成员实体模型在 src/pkg/member/models/member.go 中定义每个项目成员记录包含project_id所属项目、entity_id成员实体 ID、entity_typeu表示用户成员 /g表示用户组与role角色值这是数据库project_member表的核心结构。2.1 成员管理控制层的实现佐证项目成员管理的核心逻辑集中在 src/controller/member/controller.go。其中几个关键方法与测试场景一一对应Create为项目添加成员。代码会校验至少提供member_user或member_group之一并通过isValidRole校验角色必须是 1/2/3/4/5 之一否则返回ErrInvalidRolerole is not in 1,2,3——这正好对应测试中以指定角色添加成员的操作。UpdateRole更新项目成员角色即测试第 20、25 步管理员修改用户 C 角色的底层实现。Delete从项目中移除成员即测试第 27 步管理员将用户 C 移出项目 X。IsProjectAdmin判断某用户是否是任意项目的管理员用于后续鉴权判断。DAO 层src/pkg/member/dao/dao.go则提供AddProjectMember、UpdateProjectMemberRole、DeleteProjectMemberByID、ListRoles等数据库操作并有对应的 dao_test.go 单元测试如TestAddProjectMember、TestUpdateProjectMemberRole、TestListRoles验证这些操作的正确性。三、测试步骤详解完整复现管理员管理项目成员全流程下面按原文档步骤分组展开并标注每一步的预期结果与验证要点。3.1 第一阶段管理员添加三名成员并验证基础权限步骤 1-5UI 中添加成员以管理员身份登录 Harbor Web UI。找到一个管理员当前不是其成员的既有项目 X这正是验证管理员可管理任意项目而不只是自己所属项目的关键前提。将用户 A 添加到项目 X角色设为项目管理员。将用户 B 添加到项目 X角色设为开发者。将用户 C 添加到项目 X角色设为访客。对应到源码添加成员时后端会构建member记录并写入project_member表src/controller/member/controller.go当目标用户已存在时直接通过GetByName查到UserID后绑定若用户不存在则触发auth.SearchAndOnBoardUser流程DB 模式下一般不会走到该分支因为用户已预置。步骤 6-8以管理员身份验证项目 X 的基础可用性在 Docker 客户端主机上使用docker login harbor_host以管理员身份登录 Harbor。使用docker push向项目 X 推送一个镜像。使用docker pull从项目 X 拉取该镜像。预期结果步骤 7、8 应成功。管理员拥有系统级权限可以管理任何项目。3.2 第二阶段验证项目管理员角色用户 A步骤 9-11以用户 A 身份操作登出 admin以用户 A 身份docker login。使用docker push向项目 X 推送镜像。使用docker pull从项目 X 拉取镜像。预期结果步骤 10、11 应成功。用户 A 作为项目管理员Role 1对项目 X 拥有完全的读写权限。3.3 第三阶段验证开发者角色用户 B步骤 12-14以用户 B 身份操作登出用户 A以用户 B 身份docker login。使用docker push向项目 X 推送镜像。使用docker pull从项目 X 拉取镜像。预期结果步骤 13、14 应成功。开发者Role 2同样具备 push 与 pull 权限。3.4 第四阶段验证访客角色的限制用户 C步骤 15-17以用户 C 身份操作登出用户 B以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 16 成功、步骤 17 应失败。访客Role 3是只读角色可以拉取镜像但推送镜像会被拒绝。这一结果与 Harbor 的角色模型完全吻合RoleGuest 3的权限集只包含 pull/读取类操作。Harbor 的 registry 令牌服务Token Service在签发 Docker Registry v2 token 时会根据用户的项目角色计算可访问的 scopepull/push,pullGuest 仅获得pull权限因此docker push会返回denied错误。3.5 第五阶段管理员动态调整角色并即时生效用户 C 角色升级之旅步骤 18-21Guest → Developer保持管理员的 UI 会话持续登录在另一个浏览器中以用户 C 登录。在用户 C 的 UI 中确认其角色是项目 X 的Guest访客。在管理员的 UI 中将用户 C 的角色改为项目 X 的Developer开发者。回到用户 C 的 UI确认其角色已变为Developer。预期结果步骤 19、21 符合描述即角色变更即时可见。步骤 22-24以 Developer 身份操作在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 23、24 应成功——角色升级后用户 C 的推送权限随之生效。步骤 25-26Developer → Project Admin在管理员的 UI 中将用户 C 的角色改为项目 X 的Project Admin项目管理员。在用户 C 的 UI 中确认其角色已变为Project Admin。预期结果步骤 26 符合描述。这组步骤是动态 RBAC的核心验证管理员修改角色后无需用户重新登录或重启任何服务权限即时生效。其底层实现即controller.UpdateRole → manager.UpdateRole → dao.UpdateProjectMemberRolesrc/pkg/member/dao/dao.go更新project_member表中的 role 记录Docker CLI 每次 push/pull 都会向 Harbor 重新请求 tokentoken 携带的权限以数据库最新角色为准因此角色变更立即反映在后续操作中。3.6 第六阶段移除成员与项目公开性对访客的影响步骤 27-31移除成员 公开项目在管理员的 UI 中将用户 C从项目 X 移除。将项目 X 的公开性Publicity设置为开启。在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 30 应成功公开项目对未登录/非成员用户开放 pull步骤 31 应失败非成员没有 push 权限。步骤 32-35关闭公开性后验证访客完全无权限将项目 X 的公开性设置为关闭。在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 34、35均应失败——私有项目中非成员用户既不能拉取也不能推送。项目移除成员的底层实现是controller.Delete → manager.Delete → dao.DeleteProjectMemberByIDsrc/pkg/member/dao/dao.go从project_member表删除该成员记录。移除后用户 C 对项目 X 不再拥有任何项目级角色其访问权限完全取决于项目的公开性设置公开项目允许匿名 pull私有项目则彻底拒绝。四、预期结果汇总表将原文档的Expected Outcome整理为便于执行验证的结果清单步骤操作预期结果7、8admin push / pull成功10、11用户 A项目管理员push / pull成功13、14用户 B开发者push / pull成功16用户 C访客pull成功17用户 C访客push失败19、21用户 C 角色 UI 展示与设置一致23、24用户 C升级为开发者pull / push成功26用户 C升级为项目管理员UI 展示与设置一致30公开项目 非成员 pull成功31公开项目 非成员 push失败34、35私有项目 非成员 pull / push均失败这条结果链清晰地勾勒出 Harbor 权限模型的完整边界项目成员权限角色决定能不能操作项目公开性决定非成员能看见什么二者叠加构成最终的访问控制。五、测试要点总结与实战启示5.1 测试设计亮点双浏览器会话隔离用独立浏览器同时观察管理员与成员两个视角验证角色变更的即时性与 UI 展示一致性避免会话覆盖导致的假阳性。同一用户的多级角色跃迁用户 C 经历 Guest → Developer → Project Admin → 被移除 的完整生命周期一次性覆盖角色升级、动态生效、成员移除、公开性兜底四种场景。CLI 与 UI 双重验证UI 验证角色展示Docker CLI 验证真实权限形成声明权限与实际权限的闭环校验。5.2 对生产环境的启示从源码结构看本测试验证的成员管理能力由 src/controller/member/controller.go 与 src/pkg/member/dao/dao.go 共同支撑可直接迁移到以下生产实践最小权限原则落地按团队职能分配 Guest/Developer/Project Admin开发人员仅授予 Developer只读消费者授予 Guest角色动态调整人员职能变化时直接在项目成员页调整角色无需重新签发凭据权限即时生效公开项目的风险控制只有明确需要对外共享的仓库才开启公开性且公开项目仅暴露 pull 能力写操作仍严格受角色约束。5.3 相关资源索引测试用例原文3-11-DB-admin-user-manage-project-members.md角色常量定义src/common/const.go成员控制层实现src/controller/member/controller.go成员 DAO 层实现src/pkg/member/dao/dao.go成员模型定义src/pkg/member/models/member.go相关单元测试src/pkg/member/dao/dao_test.go、src/controller/member/controller_test.go【免费下载链接】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 模式 RBAC 测试用例深度解析）
Harbor 数据库认证模式下管理员管理项目成员实战指南DB 模式 RBAC 测试用例深度解析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor导读本文以 Harbor 开源仓库中的系统测试用例 3-11-DB-admin-user-manage-project-members.md 为核心完整还原管理员在本地数据库认证db_auth模式下为项目添加不同角色成员并验证各角色在 Docker CLI 侧 push/pull 权限的端到端验证流程。文章将逐一拆解测试步骤的意图、底层角色模型的实现依据与预期结果帮助读者掌握 Harbor 项目成员管理RBAC的完整链路并可直接在自建 Harbor 环境中复现该测试。一、测试场景概述DB 模式下的项目成员管理1.1 测试目的该测试用例验证一个核心能力当 Harbor 使用本地数据库auth_mode db_auth管理用户时系统管理员可以将不同角色的成员加入任意项目且各角色的实际权限推拉镜像与 UI 中展示的角色一致。用户数据完全存储在 Harbor 自己的本地数据库中不依赖任何外部认证源如 LDAP、OIDC、UAA。在 Harbor 源码中数据库认证模式的定义位于 src/common/const.goDBAuth db_auth。该常量是 Harbor 系统配置项auth_mode的合法取值之一也是本测试前提条件的源码依据。1.2 测试环境要求根据测试用例文档复现本测试需要满足以下环境条件条件说明Harbor 实例已运行且可通过 Web UI 与 Docker CLI 访问认证模式auth_mode设置为db_auth用户数据存于本地数据库Docker 客户端一台装有 Docker CLI 的 Linux 主机非管理员用户至少 3 个非系统管理员用户下文称 A、B、C目标项目至少 1 个管理员当前不是其成员的项目下文称项目 X1.3 测试操作约定重要注意事项原文档对测试过程有明确约定复现时务必遵守测试中的用户 A、B、C 是非系统管理员用户实际执行时应将 A、B、C 与项目 X 替换为更长、更有意义的名称如dev_alice、dev_bob、qa_carol与demo-project。必须同时使用两种浏览器来保持两个独立的 Web 会话例如 Chrome Firefox或 Chrome Safari。严禁在同一浏览器的不同窗口标签页中同时登录两个用户否则会话会相互覆盖导致角色验证结果失真。这一约定的本质是Harbor 的 Web 会话基于 Cookie 隔离不同浏览器代表不同会话从而可以同时观察管理员修改角色与成员侧视角两个界面实时校验角色变更是否即时生效。二、角色模型基础Harbor 项目成员的三种角色在深入测试步骤之前先明确 Harbor 中项目成员角色的底层定义。角色常量定义在 src/common/const.goRoleProjectAdmin 1 RoleDeveloper 2 RoleGuest 3 RoleMaintainer 4 RoleLimitedGuest 5本测试聚焦其中的三种经典角色角色常量值权限要点项目管理员Project Admin1项目的最高权限角色可管理项目成员、配置、镜像等开发者Developer2可推送push与拉取pull镜像可编辑镜像信息访客Guest3只读角色可拉取pull镜像不可推送push注Maintainer4与LimitedGuest5是 Harbor 后续版本引入的角色本测试用例编写时期主要覆盖 1/2/3 三种角色。从源码结构看成员实体模型在 src/pkg/member/models/member.go 中定义每个项目成员记录包含project_id所属项目、entity_id成员实体 ID、entity_typeu表示用户成员 /g表示用户组与role角色值这是数据库project_member表的核心结构。2.1 成员管理控制层的实现佐证项目成员管理的核心逻辑集中在 src/controller/member/controller.go。其中几个关键方法与测试场景一一对应Create为项目添加成员。代码会校验至少提供member_user或member_group之一并通过isValidRole校验角色必须是 1/2/3/4/5 之一否则返回ErrInvalidRolerole is not in 1,2,3——这正好对应测试中以指定角色添加成员的操作。UpdateRole更新项目成员角色即测试第 20、25 步管理员修改用户 C 角色的底层实现。Delete从项目中移除成员即测试第 27 步管理员将用户 C 移出项目 X。IsProjectAdmin判断某用户是否是任意项目的管理员用于后续鉴权判断。DAO 层src/pkg/member/dao/dao.go则提供AddProjectMember、UpdateProjectMemberRole、DeleteProjectMemberByID、ListRoles等数据库操作并有对应的 dao_test.go 单元测试如TestAddProjectMember、TestUpdateProjectMemberRole、TestListRoles验证这些操作的正确性。三、测试步骤详解完整复现管理员管理项目成员全流程下面按原文档步骤分组展开并标注每一步的预期结果与验证要点。3.1 第一阶段管理员添加三名成员并验证基础权限步骤 1-5UI 中添加成员以管理员身份登录 Harbor Web UI。找到一个管理员当前不是其成员的既有项目 X这正是验证管理员可管理任意项目而不只是自己所属项目的关键前提。将用户 A 添加到项目 X角色设为项目管理员。将用户 B 添加到项目 X角色设为开发者。将用户 C 添加到项目 X角色设为访客。对应到源码添加成员时后端会构建member记录并写入project_member表src/controller/member/controller.go当目标用户已存在时直接通过GetByName查到UserID后绑定若用户不存在则触发auth.SearchAndOnBoardUser流程DB 模式下一般不会走到该分支因为用户已预置。步骤 6-8以管理员身份验证项目 X 的基础可用性在 Docker 客户端主机上使用docker login harbor_host以管理员身份登录 Harbor。使用docker push向项目 X 推送一个镜像。使用docker pull从项目 X 拉取该镜像。预期结果步骤 7、8 应成功。管理员拥有系统级权限可以管理任何项目。3.2 第二阶段验证项目管理员角色用户 A步骤 9-11以用户 A 身份操作登出 admin以用户 A 身份docker login。使用docker push向项目 X 推送镜像。使用docker pull从项目 X 拉取镜像。预期结果步骤 10、11 应成功。用户 A 作为项目管理员Role 1对项目 X 拥有完全的读写权限。3.3 第三阶段验证开发者角色用户 B步骤 12-14以用户 B 身份操作登出用户 A以用户 B 身份docker login。使用docker push向项目 X 推送镜像。使用docker pull从项目 X 拉取镜像。预期结果步骤 13、14 应成功。开发者Role 2同样具备 push 与 pull 权限。3.4 第四阶段验证访客角色的限制用户 C步骤 15-17以用户 C 身份操作登出用户 B以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 16 成功、步骤 17 应失败。访客Role 3是只读角色可以拉取镜像但推送镜像会被拒绝。这一结果与 Harbor 的角色模型完全吻合RoleGuest 3的权限集只包含 pull/读取类操作。Harbor 的 registry 令牌服务Token Service在签发 Docker Registry v2 token 时会根据用户的项目角色计算可访问的 scopepull/push,pullGuest 仅获得pull权限因此docker push会返回denied错误。3.5 第五阶段管理员动态调整角色并即时生效用户 C 角色升级之旅步骤 18-21Guest → Developer保持管理员的 UI 会话持续登录在另一个浏览器中以用户 C 登录。在用户 C 的 UI 中确认其角色是项目 X 的Guest访客。在管理员的 UI 中将用户 C 的角色改为项目 X 的Developer开发者。回到用户 C 的 UI确认其角色已变为Developer。预期结果步骤 19、21 符合描述即角色变更即时可见。步骤 22-24以 Developer 身份操作在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 23、24 应成功——角色升级后用户 C 的推送权限随之生效。步骤 25-26Developer → Project Admin在管理员的 UI 中将用户 C 的角色改为项目 X 的Project Admin项目管理员。在用户 C 的 UI 中确认其角色已变为Project Admin。预期结果步骤 26 符合描述。这组步骤是动态 RBAC的核心验证管理员修改角色后无需用户重新登录或重启任何服务权限即时生效。其底层实现即controller.UpdateRole → manager.UpdateRole → dao.UpdateProjectMemberRolesrc/pkg/member/dao/dao.go更新project_member表中的 role 记录Docker CLI 每次 push/pull 都会向 Harbor 重新请求 tokentoken 携带的权限以数据库最新角色为准因此角色变更立即反映在后续操作中。3.6 第六阶段移除成员与项目公开性对访客的影响步骤 27-31移除成员 公开项目在管理员的 UI 中将用户 C从项目 X 移除。将项目 X 的公开性Publicity设置为开启。在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 30 应成功公开项目对未登录/非成员用户开放 pull步骤 31 应失败非成员没有 push 权限。步骤 32-35关闭公开性后验证访客完全无权限将项目 X 的公开性设置为关闭。在 Docker 客户端主机上以用户 C 身份docker login。使用docker pull从项目 X 拉取镜像。使用docker push向项目 X 推送镜像。预期结果步骤 34、35均应失败——私有项目中非成员用户既不能拉取也不能推送。项目移除成员的底层实现是controller.Delete → manager.Delete → dao.DeleteProjectMemberByIDsrc/pkg/member/dao/dao.go从project_member表删除该成员记录。移除后用户 C 对项目 X 不再拥有任何项目级角色其访问权限完全取决于项目的公开性设置公开项目允许匿名 pull私有项目则彻底拒绝。四、预期结果汇总表将原文档的Expected Outcome整理为便于执行验证的结果清单步骤操作预期结果7、8admin push / pull成功10、11用户 A项目管理员push / pull成功13、14用户 B开发者push / pull成功16用户 C访客pull成功17用户 C访客push失败19、21用户 C 角色 UI 展示与设置一致23、24用户 C升级为开发者pull / push成功26用户 C升级为项目管理员UI 展示与设置一致30公开项目 非成员 pull成功31公开项目 非成员 push失败34、35私有项目 非成员 pull / push均失败这条结果链清晰地勾勒出 Harbor 权限模型的完整边界项目成员权限角色决定能不能操作项目公开性决定非成员能看见什么二者叠加构成最终的访问控制。五、测试要点总结与实战启示5.1 测试设计亮点双浏览器会话隔离用独立浏览器同时观察管理员与成员两个视角验证角色变更的即时性与 UI 展示一致性避免会话覆盖导致的假阳性。同一用户的多级角色跃迁用户 C 经历 Guest → Developer → Project Admin → 被移除 的完整生命周期一次性覆盖角色升级、动态生效、成员移除、公开性兜底四种场景。CLI 与 UI 双重验证UI 验证角色展示Docker CLI 验证真实权限形成声明权限与实际权限的闭环校验。5.2 对生产环境的启示从源码结构看本测试验证的成员管理能力由 src/controller/member/controller.go 与 src/pkg/member/dao/dao.go 共同支撑可直接迁移到以下生产实践最小权限原则落地按团队职能分配 Guest/Developer/Project Admin开发人员仅授予 Developer只读消费者授予 Guest角色动态调整人员职能变化时直接在项目成员页调整角色无需重新签发凭据权限即时生效公开项目的风险控制只有明确需要对外共享的仓库才开启公开性且公开项目仅暴露 pull 能力写操作仍严格受角色约束。5.3 相关资源索引测试用例原文3-11-DB-admin-user-manage-project-members.md角色常量定义src/common/const.go成员控制层实现src/controller/member/controller.go成员 DAO 层实现src/pkg/member/dao/dao.go成员模型定义src/pkg/member/models/member.go相关单元测试src/pkg/member/dao/dao_test.go、src/controller/member/controller_test.go【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考