Harbor 系统管理员角色验证指南DB 模式下由非管理员提升为系统管理员后管理项目成员Test 3-21【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harborHarbor本项目当前仓库为 ha/harbor是一套开源的可信云原生制品仓库系统支持存储、签名与安全扫描制品。当认证方式为本地数据库模式auth_mode db_auth时用户信息完全由 Harbor 自身维护系统管理员与项目成员的管理权限也因此成为安全测试的关键点。本文基于仓库测试用例 3-21-DB-admin-role-user-manage-project-members.md 展开完整还原该用例的目的、前置条件、操作步骤与预期结果并结合 member 控制器源码 与 RBAC 权限定义深入解释系统管理员角色在底层是如何获得项目成员管理能力的。读完本文你将能够复现该测试场景并理解 Harbor 系统级角色与项目级角色的授权模型。一、测试目的验证系统管理员角色的权限等同性Test 3-21 的测试目的是验证一个被授予系统管理员system admin角色的非管理员用户能够与内置 admin 用户一样向项目中添加各种角色的成员。其核心断言是A user with system admin role can perform all operations the same as the admin user.该用例的认证前提是DB 模式Harbor 配置为通过本地数据库完成认证auth_mode设置为db_auth用户数据存放在本地数据库中。在源码层面db_auth对应的常量定义于 src/common/const.goDBAuth db_auth而用户模型中的SysAdminFlag字段则用于标记该用户是否为系统管理员见 src/common/models/user.go。在 Harbor 中系统管理员与项目成员是两个不同维度的权限系统管理员System Admin拥有 src/common/rbac/const.go 中ScopeSystem层面的系统级权限如创建项目、管理用户、配置系统等项目成员Project Member在具体项目内承担 projectAdmin / maintainer / developer / guest / limitedGuest 等角色权限由 src/common/rbac/project/rbac_role.go 中的rolePoliciesMap定义。Test 3-21 要验证的正是当非管理员用户被提升为系统管理员后这两套权限如何叠加生效即系统管理员能否无缝接管项目成员的增删改查操作。二、前置环境准备根据用例文档执行该测试需要满足以下环境要求正在运行且可访问的 Harbor 实例Harbor 配置为本地数据库认证auth_mode设置为db_auth用户数据存储在本地数据库中一台安装了 Docker CLI 的 Linux 主机作为 Docker 客户端Harbor 中至少存在三个非管理员用户至少存在一个 admin 用户不是其成员的项目。此外用例还特别给出两条操作注意事项下面提到的非管理员用户M不能与 Test 3-11 中使用的非管理员用户是同一个用户。也就是说执行本用例前需要准备一个独立、未被其他测试占用过的非管理员账号避免测试之间的状态互相干扰参考用例 3-11 中强调必须同时使用两种不同内核的浏览器如 Chrome Firefox、Chrome Safari来保证两个用户会话互相独立禁止在同一浏览器中通过多窗口/多标签页同时登录两个用户。这是因为 Harbor 的 Web 会话基于 Cookie 与 Session同一浏览器内核会共享会话状态只有跨浏览器才能模拟两个同时在线的独立用户。三、测试步骤总览Test 3-21 的步骤设计非常精炼只有两步将一个非管理员用户 M 授予系统管理员角色并以该用户身份即以 admin 用户身份执行操作重复执行 Test 3-11 的全部步骤。也就是说3-21 的完整执行链路 角色提升 3-11 全量回归。因此要正确执行本用例必须先完整掌握 3-11-DB-admin-user-manage-project-members.md 的详细步骤。下面先完整展开 3-11 的步骤再说明如何在 3-21 中套用。四、Test 3-11 完整步骤本用例的主体Test 3-11 的用途是验证 admin 用户内置admin账号在 DB 模式下可以向项目添加不同角色的成员。其完整步骤如下用户 A、B、C 均为非系统管理员用户项目 X 为被测项目实际操作中应替换为更长的、有意义的名称4.1 添加三种角色的项目成员以 admin 用户登录 Harbor UI找到一个 admin不是其成员的现有项目 X将用户 A 添加为项目 X 的项目管理员Project Admin将用户 B 添加为项目 X 的开发者Developer将用户 C 添加为项目 X 的访客Guest。这里的三种角色对应 Harbor 的项目成员角色常量定义于 src/common/const.go角色角色常量数值项目管理员RoleProjectAdmin1开发者RoleDeveloper2访客RoleGuest3另有RoleMaintainer4、RoleLimitedGuest5 两个扩展角色。在成员管理入口 src/controller/member/controller.go 中Request结构体通过Role字段携带要赋予的角色值Create方法在落库前会调用isValidRole校验角色值必须在 1、2、3、4、5 范围内非法值将返回ErrInvalidRolerole is not in 1,2,3见 src/controller/member/controller.go。4.2 验证 admin 的 push / pull 能力在 Docker 客户端主机上使用docker login harbor_host以 admin 身份登录使用docker push向项目 X 推送一个镜像应成功使用docker pull从项目 X 拉取该镜像应成功。4.3 按角色验证 A、B、C 的推拉权限退出 admin以用户 A 身份docker login用户 Adocker push镜像到项目 X项目管理员应成功用户 Adocker pull项目 X 的镜像应成功。退出用户 A以用户 B 身份登录用户 Bdocker push镜像到项目 X开发者应成功用户 Bdocker pull项目 X 的镜像应成功。退出用户 B以用户 C 身份登录用户 Cdocker pull项目 X 的镜像访客可拉取应成功用户 Cdocker push镜像到项目 X应失败。这一步是 RBAC 权限模型的直接体现在 src/common/rbac/project/rbac_role.go 的rolePoliciesMap中guest角色对repository资源只有pull、list、read权限rbac_role.go#L248-L279没有push权限因此 push 必然被拒绝而developer角色则同时拥有pull与push权限rbac_role.go#L195-L246。这正是镜像推拉测试背后的权限判定依据。4.4 在 UI 中动态变更成员角色并验证权限实时生效保持 admin 的 UI 会话不退出在另一个浏览器中登录用户 C在用户 C 的 UI 中确认自己在项目 X 中的角色是访客guest在 admin 的 UI 中将用户 C 在项目 X 中的角色变更为开发者在用户 C 的 UI 中确认自己的角色已变为开发者。在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像应成功用户 Cdocker push镜像到项目 X开发者权限应成功。在 admin 的 UI 中将用户 C 在项目 X 中的角色变更为项目管理员在用户 C 的 UI 中确认自己的角色已变为项目管理员。角色变更在底层由 src/controller/member/controller.go 的UpdateRole方法完成它先通过projectMgr.Get确认项目存在再调用mgr.UpdateRole(ctx, p.ProjectID, memberID, role)更新project_member表中该成员的role字段。由于 Harbor 在每次请求时都会基于当前成员表重新计算访问权限动态评估因此角色的变更无需重新登录即可立即生效——这正是步骤 18~26 能够在两个并存的浏览器会话中即时看到角色变化的原因。4.5 移除成员并验证公开项目publicity的访问控制在 admin 的 UI 中将用户 C 从项目 X 中移除将项目 X 的公开性publicity设置为开启在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像项目公开非成员也可拉取应成功用户 Cdocker push镜像到项目 X应失败——公开项目只开放拉取不开放推送。将项目 X 的公开性关闭在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像非成员 私有项目应失败用户 Cdocker push镜像到项目 X应失败。成员移除在底层由 src/controller/member/controller.go 的Delete方法实现通过projectMgr.Get定位项目后调用mgr.Delete(ctx, p.ProjectID, memberID)删除project_member中的对应记录。成员一旦被移除其项目级 RBAC 策略随即失效此时用户 C 能否访问项目 X完全取决于项目公开性配置——公开项目允许任何已认证用户 pull但 push 依旧被拒绝。五、预期结果汇总Test 3-21 的预期结果可归纳为两点权限等同性拥有系统管理员角色的用户 M 能够执行与 admin 用户完全相同的全部操作结果一致性本用例的每一步预期结果与 Test 3-11 完全一致。对照 3-11具体预期如下第 7、8、10、11、16 步admin 与 A 的 push/pull、C 的 pull应成功第 17 步访客 C push应报错第 19、21 步C 的角色显示与描述一致第 23、24 步开发者 C 的 pull/push应成功第 26 步C 变为项目管理员与描述一致第 30 步公开项目下非成员 pull应成功第 31 步公开项目下非成员 push应失败第 34~35 步私有项目下非成员 pull/push均应失败。六、源码级原理系统管理员为何等同 adminTest 3-21 断言系统管理员用户能执行 admin 的全部项目成员管理操作其依据可从以下三个源码层面得到印证6.1 系统级权限ScopeSystem 覆盖项目成员管理所需动作在 src/common/rbac/const.go 的PoliciesMap[ScopeSystem]中系统级权限包含了对ResourceProject的list、create动作以及对ResourceUser、ResourceUserGroup等系统资源的完整增删改查。这意味着系统管理员天然具备创建/浏览项目的资格这是其介入项目成员管理的前提。6.2 项目级权限对任意项目拥有成员管理动作更关键的是在 src/common/rbac/const.go 的NolimitProvider.GetPermissions中当 scope 为ScopeProject时权限集合显式追加了对ResourceMember的create、read、update、list、delete五个动作。也就是说系统管理员在任意项目范围内都被授予了成员管理的全部动作这正好对应 src/controller/member/controller.go 中Controller接口定义的Create、Delete、List、UpdateRole四个核心方法——添加成员、删除成员、列出成员、修改角色全部在系统管理员的能力范围之内。6.3 用户模型的系统管理员标志在 src/common/models/user.go 的User结构体中SysAdminFlag bool字段json:sysadmin_flag用于标记用户是否为系统管理员通过 UI 或 API 将该标志从false置为true即完成了用例步骤 1 中的角色提升。提升之后该用户的每次请求在鉴权阶段都会被同时赋予系统级与项目级策略从而获得与内置 admin 账号等同的操作能力。七、测试设计要点与注意事项用户隔离本用例中的非管理员用户 M 必须与 Test 3-11 使用的非管理员用户不同。这是测试用例之间的隔离要求避免前序测试遗留的项目成员关系或角色状态影响本用例的结果判定会话隔离验证角色动态变更3-11 第 18~26 步时必须使用两种浏览器保持两个用户会话并存。这既是为了验证角色变更实时生效也是为了确认 Harbor 的会话机制不会串号推拉双验证测试中 push 与 pull 的成对验证覆盖了 RBAC 中repository资源上push/pull两种动作的权限差异是检验项目成员角色是否生效的最直接手段公开性边界第 27~35 步在移除成员后切换项目公开性验证的是成员身份与项目公开策略两条独立访问路径——公开项目允许拉取、禁止推送私有项目两者皆拒结果判定由于 3-21 完全复用了 3-11 的步骤任何一步失败都意味着系统管理员用户 ≠ admin 用户的权限漏洞应重点排查 src/controller/member/controller.go 的鉴权链路与系统级策略注入逻辑。八、总结Test 3-21 是 Harbor RBAC 体系中连接系统级角色与项目级角色的关键验证用例它证明在db_auth模式下非管理员用户一旦被授予系统管理员角色即获得与内置 admin 等同的项目成员管理能力。从源码看这一能力由系统级策略中对ResourceMember的完整动作授权src/common/rbac/const.go、成员控制器 src/controller/member/controller.go 的Create/UpdateRole/Delete实现以及用户模型的SysAdminFlagsrc/common/models/user.go共同支撑。对测试与运维人员而言本文给出的完整步骤含 3-11 全量步骤可直接用于本地 Harbor 实例的功能回归与权限审计。相关测试用例与实现文件索引主用例3-21-DB-admin-role-user-manage-project-members.md被引用用例3-11-DB-admin-user-manage-project-members.md普通用户管理成员的对照用例3-01-DB-user-manage-project-members.md成员管理控制器src/controller/member/controller.go角色与权限常量src/common/const.go、src/common/rbac/const.go项目角色权限映射src/common/rbac/project/rbac_role.go用户模型src/common/models/user.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 模式下由非管理员提升为系统管理员后管理项目成员（Test 3-21）
Harbor 系统管理员角色验证指南DB 模式下由非管理员提升为系统管理员后管理项目成员Test 3-21【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harborHarbor本项目当前仓库为 ha/harbor是一套开源的可信云原生制品仓库系统支持存储、签名与安全扫描制品。当认证方式为本地数据库模式auth_mode db_auth时用户信息完全由 Harbor 自身维护系统管理员与项目成员的管理权限也因此成为安全测试的关键点。本文基于仓库测试用例 3-21-DB-admin-role-user-manage-project-members.md 展开完整还原该用例的目的、前置条件、操作步骤与预期结果并结合 member 控制器源码 与 RBAC 权限定义深入解释系统管理员角色在底层是如何获得项目成员管理能力的。读完本文你将能够复现该测试场景并理解 Harbor 系统级角色与项目级角色的授权模型。一、测试目的验证系统管理员角色的权限等同性Test 3-21 的测试目的是验证一个被授予系统管理员system admin角色的非管理员用户能够与内置 admin 用户一样向项目中添加各种角色的成员。其核心断言是A user with system admin role can perform all operations the same as the admin user.该用例的认证前提是DB 模式Harbor 配置为通过本地数据库完成认证auth_mode设置为db_auth用户数据存放在本地数据库中。在源码层面db_auth对应的常量定义于 src/common/const.goDBAuth db_auth而用户模型中的SysAdminFlag字段则用于标记该用户是否为系统管理员见 src/common/models/user.go。在 Harbor 中系统管理员与项目成员是两个不同维度的权限系统管理员System Admin拥有 src/common/rbac/const.go 中ScopeSystem层面的系统级权限如创建项目、管理用户、配置系统等项目成员Project Member在具体项目内承担 projectAdmin / maintainer / developer / guest / limitedGuest 等角色权限由 src/common/rbac/project/rbac_role.go 中的rolePoliciesMap定义。Test 3-21 要验证的正是当非管理员用户被提升为系统管理员后这两套权限如何叠加生效即系统管理员能否无缝接管项目成员的增删改查操作。二、前置环境准备根据用例文档执行该测试需要满足以下环境要求正在运行且可访问的 Harbor 实例Harbor 配置为本地数据库认证auth_mode设置为db_auth用户数据存储在本地数据库中一台安装了 Docker CLI 的 Linux 主机作为 Docker 客户端Harbor 中至少存在三个非管理员用户至少存在一个 admin 用户不是其成员的项目。此外用例还特别给出两条操作注意事项下面提到的非管理员用户M不能与 Test 3-11 中使用的非管理员用户是同一个用户。也就是说执行本用例前需要准备一个独立、未被其他测试占用过的非管理员账号避免测试之间的状态互相干扰参考用例 3-11 中强调必须同时使用两种不同内核的浏览器如 Chrome Firefox、Chrome Safari来保证两个用户会话互相独立禁止在同一浏览器中通过多窗口/多标签页同时登录两个用户。这是因为 Harbor 的 Web 会话基于 Cookie 与 Session同一浏览器内核会共享会话状态只有跨浏览器才能模拟两个同时在线的独立用户。三、测试步骤总览Test 3-21 的步骤设计非常精炼只有两步将一个非管理员用户 M 授予系统管理员角色并以该用户身份即以 admin 用户身份执行操作重复执行 Test 3-11 的全部步骤。也就是说3-21 的完整执行链路 角色提升 3-11 全量回归。因此要正确执行本用例必须先完整掌握 3-11-DB-admin-user-manage-project-members.md 的详细步骤。下面先完整展开 3-11 的步骤再说明如何在 3-21 中套用。四、Test 3-11 完整步骤本用例的主体Test 3-11 的用途是验证 admin 用户内置admin账号在 DB 模式下可以向项目添加不同角色的成员。其完整步骤如下用户 A、B、C 均为非系统管理员用户项目 X 为被测项目实际操作中应替换为更长的、有意义的名称4.1 添加三种角色的项目成员以 admin 用户登录 Harbor UI找到一个 admin不是其成员的现有项目 X将用户 A 添加为项目 X 的项目管理员Project Admin将用户 B 添加为项目 X 的开发者Developer将用户 C 添加为项目 X 的访客Guest。这里的三种角色对应 Harbor 的项目成员角色常量定义于 src/common/const.go角色角色常量数值项目管理员RoleProjectAdmin1开发者RoleDeveloper2访客RoleGuest3另有RoleMaintainer4、RoleLimitedGuest5 两个扩展角色。在成员管理入口 src/controller/member/controller.go 中Request结构体通过Role字段携带要赋予的角色值Create方法在落库前会调用isValidRole校验角色值必须在 1、2、3、4、5 范围内非法值将返回ErrInvalidRolerole is not in 1,2,3见 src/controller/member/controller.go。4.2 验证 admin 的 push / pull 能力在 Docker 客户端主机上使用docker login harbor_host以 admin 身份登录使用docker push向项目 X 推送一个镜像应成功使用docker pull从项目 X 拉取该镜像应成功。4.3 按角色验证 A、B、C 的推拉权限退出 admin以用户 A 身份docker login用户 Adocker push镜像到项目 X项目管理员应成功用户 Adocker pull项目 X 的镜像应成功。退出用户 A以用户 B 身份登录用户 Bdocker push镜像到项目 X开发者应成功用户 Bdocker pull项目 X 的镜像应成功。退出用户 B以用户 C 身份登录用户 Cdocker pull项目 X 的镜像访客可拉取应成功用户 Cdocker push镜像到项目 X应失败。这一步是 RBAC 权限模型的直接体现在 src/common/rbac/project/rbac_role.go 的rolePoliciesMap中guest角色对repository资源只有pull、list、read权限rbac_role.go#L248-L279没有push权限因此 push 必然被拒绝而developer角色则同时拥有pull与push权限rbac_role.go#L195-L246。这正是镜像推拉测试背后的权限判定依据。4.4 在 UI 中动态变更成员角色并验证权限实时生效保持 admin 的 UI 会话不退出在另一个浏览器中登录用户 C在用户 C 的 UI 中确认自己在项目 X 中的角色是访客guest在 admin 的 UI 中将用户 C 在项目 X 中的角色变更为开发者在用户 C 的 UI 中确认自己的角色已变为开发者。在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像应成功用户 Cdocker push镜像到项目 X开发者权限应成功。在 admin 的 UI 中将用户 C 在项目 X 中的角色变更为项目管理员在用户 C 的 UI 中确认自己的角色已变为项目管理员。角色变更在底层由 src/controller/member/controller.go 的UpdateRole方法完成它先通过projectMgr.Get确认项目存在再调用mgr.UpdateRole(ctx, p.ProjectID, memberID, role)更新project_member表中该成员的role字段。由于 Harbor 在每次请求时都会基于当前成员表重新计算访问权限动态评估因此角色的变更无需重新登录即可立即生效——这正是步骤 18~26 能够在两个并存的浏览器会话中即时看到角色变化的原因。4.5 移除成员并验证公开项目publicity的访问控制在 admin 的 UI 中将用户 C 从项目 X 中移除将项目 X 的公开性publicity设置为开启在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像项目公开非成员也可拉取应成功用户 Cdocker push镜像到项目 X应失败——公开项目只开放拉取不开放推送。将项目 X 的公开性关闭在 Docker 客户端上以用户 C 身份登录用户 Cdocker pull项目 X 的镜像非成员 私有项目应失败用户 Cdocker push镜像到项目 X应失败。成员移除在底层由 src/controller/member/controller.go 的Delete方法实现通过projectMgr.Get定位项目后调用mgr.Delete(ctx, p.ProjectID, memberID)删除project_member中的对应记录。成员一旦被移除其项目级 RBAC 策略随即失效此时用户 C 能否访问项目 X完全取决于项目公开性配置——公开项目允许任何已认证用户 pull但 push 依旧被拒绝。五、预期结果汇总Test 3-21 的预期结果可归纳为两点权限等同性拥有系统管理员角色的用户 M 能够执行与 admin 用户完全相同的全部操作结果一致性本用例的每一步预期结果与 Test 3-11 完全一致。对照 3-11具体预期如下第 7、8、10、11、16 步admin 与 A 的 push/pull、C 的 pull应成功第 17 步访客 C push应报错第 19、21 步C 的角色显示与描述一致第 23、24 步开发者 C 的 pull/push应成功第 26 步C 变为项目管理员与描述一致第 30 步公开项目下非成员 pull应成功第 31 步公开项目下非成员 push应失败第 34~35 步私有项目下非成员 pull/push均应失败。六、源码级原理系统管理员为何等同 adminTest 3-21 断言系统管理员用户能执行 admin 的全部项目成员管理操作其依据可从以下三个源码层面得到印证6.1 系统级权限ScopeSystem 覆盖项目成员管理所需动作在 src/common/rbac/const.go 的PoliciesMap[ScopeSystem]中系统级权限包含了对ResourceProject的list、create动作以及对ResourceUser、ResourceUserGroup等系统资源的完整增删改查。这意味着系统管理员天然具备创建/浏览项目的资格这是其介入项目成员管理的前提。6.2 项目级权限对任意项目拥有成员管理动作更关键的是在 src/common/rbac/const.go 的NolimitProvider.GetPermissions中当 scope 为ScopeProject时权限集合显式追加了对ResourceMember的create、read、update、list、delete五个动作。也就是说系统管理员在任意项目范围内都被授予了成员管理的全部动作这正好对应 src/controller/member/controller.go 中Controller接口定义的Create、Delete、List、UpdateRole四个核心方法——添加成员、删除成员、列出成员、修改角色全部在系统管理员的能力范围之内。6.3 用户模型的系统管理员标志在 src/common/models/user.go 的User结构体中SysAdminFlag bool字段json:sysadmin_flag用于标记用户是否为系统管理员通过 UI 或 API 将该标志从false置为true即完成了用例步骤 1 中的角色提升。提升之后该用户的每次请求在鉴权阶段都会被同时赋予系统级与项目级策略从而获得与内置 admin 账号等同的操作能力。七、测试设计要点与注意事项用户隔离本用例中的非管理员用户 M 必须与 Test 3-11 使用的非管理员用户不同。这是测试用例之间的隔离要求避免前序测试遗留的项目成员关系或角色状态影响本用例的结果判定会话隔离验证角色动态变更3-11 第 18~26 步时必须使用两种浏览器保持两个用户会话并存。这既是为了验证角色变更实时生效也是为了确认 Harbor 的会话机制不会串号推拉双验证测试中 push 与 pull 的成对验证覆盖了 RBAC 中repository资源上push/pull两种动作的权限差异是检验项目成员角色是否生效的最直接手段公开性边界第 27~35 步在移除成员后切换项目公开性验证的是成员身份与项目公开策略两条独立访问路径——公开项目允许拉取、禁止推送私有项目两者皆拒结果判定由于 3-21 完全复用了 3-11 的步骤任何一步失败都意味着系统管理员用户 ≠ admin 用户的权限漏洞应重点排查 src/controller/member/controller.go 的鉴权链路与系统级策略注入逻辑。八、总结Test 3-21 是 Harbor RBAC 体系中连接系统级角色与项目级角色的关键验证用例它证明在db_auth模式下非管理员用户一旦被授予系统管理员角色即获得与内置 admin 等同的项目成员管理能力。从源码看这一能力由系统级策略中对ResourceMember的完整动作授权src/common/rbac/const.go、成员控制器 src/controller/member/controller.go 的Create/UpdateRole/Delete实现以及用户模型的SysAdminFlagsrc/common/models/user.go共同支撑。对测试与运维人员而言本文给出的完整步骤含 3-11 全量步骤可直接用于本地 Harbor 实例的功能回归与权限审计。相关测试用例与实现文件索引主用例3-21-DB-admin-role-user-manage-project-members.md被引用用例3-11-DB-admin-user-manage-project-members.md普通用户管理成员的对照用例3-01-DB-user-manage-project-members.md成员管理控制器src/controller/member/controller.go角色与权限常量src/common/const.go、src/common/rbac/const.go项目角色权限映射src/common/rbac/project/rbac_role.go用户模型src/common/models/user.go【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考