企业官网建设流程全解析

Harbor 系统管理员角色审计日志查看测试指南（DB 认证模式）

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

导读

本文基于 Harbor 开源仓库中的测试用例文档 4-04-DB-admin-role-view-logs.md，完整讲解在DB（本地数据库）认证模式下，如何验证"被授予系统管理员角色的非管理员用户"能否像默认管理员一样查看与检索操作审计日志。你将掌握 Harbor 审计日志功能的底层数据模型、权限判定逻辑，以及一套可复现的端到端验证步骤——从docker login、push/pull、删除镜像产生日志，到 Web UI 中按操作类型与时间范围过滤日志的完整链路。

一、测试用例定位：审计日志权限验证的第四环

在 Harbor 的测试用例体系（tests/testcases/Group4-logging/）中，"日志查看"被拆分为多个独立场景，从不同认证模式与角色组合覆盖审计日志的可见性：

4-04 的独特价值在于：它验证的是"角色授予"而非"身份绑定"。即一个在本地数据库中创建、本身不具备特殊权限的普通用户 A，在 UI 中被手动赋予系统管理员角色后，其日志查看能力应当与内置 admin 完全一致。

前置注意：用例文档明确要求，步骤中使用的非管理员用户 A不能与 Test 4-03 中的非管理员用户相同，以保证两次测试互相独立、不互相污染数据。

二、前置环境要求

根据用例文档的 Environment 小节，运行本测试需要满足以下条件：

1. 运行中的 Harbor 实例：测试需要 Harbor 已安装且可访问（访问地址下文统一记为<harbor_host>）。
2. DB 认证模式：Harbor 的auth_mode必须设置为db_auth，即用户数据保存在 Harbor 自己的本地数据库中。这是该用例区别于 LDAP 系列用例的核心前提。配置项位于安装时的 harbor.yml.tmpl 中（auth_mode: db_auth）。
3. 装有 Docker CLI 的 Linux 主机：用于执行docker login、docker push、docker pull等操作，模拟真实镜像流转行为。

三、测试步骤（完整可复现）

第 1 步：赋予非管理员用户系统管理员角色

在 Harbor Web UI 中创建一个普通用户 A（或使用已有的非管理员用户），然后通过用户管理界面将其角色提升为系统管理员。该操作通常由默认 admin 用户在 "Administration → Users" 中完成。

第 2 步：重复 Test 4-03 的全部操作

Test 4-03（4-03-DB-admin-view-logs.md）的核心操作序列如下，4-04 需完整重复：

1. 产生日志：在装有 Docker CLI 的主机上，以另一个非管理员用户身份执行docker login <harbor_host>，随后执行若干次docker push与docker pull，向 registry 推送并从 registry 拉取镜像。
2. UI 删除镜像：以该非管理员用户身份登录 Harbor Web UI，从项目中删除若干镜像。
3. 切换身份：退出该非管理员用户，改用被授予系统管理员角色的用户 A登录 UI。
4. 查看日志：查看该非管理员用户所属项目的日志（审计日志）。
5. 验证过滤功能：依次使用以下检索条件组合，核对搜索结果是否正确：

• 仅 push
• 仅 pull
• pull 与 push
• 仅 delete
• 全部
• push 与 delete
• 不同的日期范围
• 日期范围 + push

这些组合覆盖了 Harbor 审计日志查询接口中"操作类型（operation）"与"时间范围（时间戳）"两个核心过滤维度的交叉验证。

四、预期结果

• 第 2 步与第 4 步中非管理员用户产生的所有操作（push、pull、delete）都应被完整记录到审计日志中。
• 用户 A 在 UI 中能够查看这些日志，且日志中的时间与操作内容应与实际操作一一对应。
• 第 5 步中的所有过滤组合均能返回正确的结果。

关键结论：被授予系统管理员角色的用户，能够执行与默认 admin 用户完全相同的日志查看与检索操作。也就是说，系统管理员角色带来的权限边界是"能力等价"，而非"身份等价"。

五、源码佐证：审计日志如何落库与鉴权

为了让上述测试步骤更有依据，以下从 Harbor 源码出发，说明日志的存储模型与权限判定逻辑。这些实现细节正是"管理员角色可以查看全部日志"这一预期结果的底层保障。

5.1 数据模型：audit_log 表

审计日志的持久化实体定义在 src/pkg/audit/model/model.go 中，通过 Beego ORM 注册：

type AuditLog struct { ID int64 `orm:"pk;auto;column(id)" json:"id"` ProjectID int64 `orm:"column(project_id)" json:"project_id"` Operation string `orm:"column(operation)" json:"operation"` ResourceType string `orm:"column(resource_type)" json:"resource_type"` Resource string `orm:"column(resource)" json:"resource"` Username string `orm:"column(username)" json:"username"` OpTime time.Time `orm:"column(op_time)" json:"op_time" sort:"default:desc"` }

• 表名为audit_log，每条记录对应一次操作；
• ProjectID将日志归属到具体项目（这正是"按项目查看日志"的数据基础）；
• Operation记录操作类型（如 pull/push/delete 等，DAO 层 src/pkg/audit/dao/dao.go 中allowedMaps明确允许 pull、create、delete 三类操作进入清理范围）；
• OpTime默认按降序排序返回，即最新的日志排在最前，对应 UI 中默认的时间倒序展示。

DAO 层（src/pkg/audit/dao/dao.go）还提供了Purge方法，支持按保留小时数（retentionHour）清理过期日志，测试中涉及"日期范围"检索时，可结合日志保留策略理解数据量。

5.2 权限判定：系统管理员可全局查看

日志查询接口的权限逻辑位于 src/server/v2.0/handler/auditlog.go 的checkPermissionAndBuildQuery方法：

• 首先要求用户已通过认证（secCtx.IsAuthenticated()），否则返回 401；
• 接着调用a.RequireSystemAccess(ctx, rbac.ActionList, rbac.ResourceAuditLog)判断是否为系统管理员；
• 若是系统管理员：直接放行，查询条件不加任何项目过滤，可以看到全部项目的审计日志；
• 若不是：降级为按项目权限过滤——枚举当前用户有rbac.ResourceLog查看权限的所有项目，将这些项目 ID 拼成 OR 条件；若一个项目都没有，则注入-1占位值确保查询结果为空。

系统管理员身份的判定在 src/common/security/local/context.go 的IsSysAdmin()方法中：s.user.SysAdminFlag || s.user.AdminRoleInAuth。也就是说，无论是内置 admin 的标记（SysAdminFlag），还是通过用户管理授予的系统管理员角色（AdminRoleInAuth），都会返回true。这从源码层面印证了 4-04 的预期结果：被授予系统管理员角色的用户 A，与内置 admin 在日志查看上走完全相同的"全量可见"分支。

5.3 审计日志的三种查询入口

• 系统级日志 API：ListAuditLogs（位于 src/server/v2.0/handler/auditlog.go），管理员全局查看所有项目日志；
• 项目级日志 API：项目详情下的日志查询（位于 src/server/v2.0/handler/project.go 的ListLogs相关逻辑），按项目 ID 过滤；
• 扩展审计日志（Audit Log Ext）：ListAuditLogExts提供带扩展字段的审计日志视图，同样由auditlogAPI暴露。

六、测试要点与常见误区

1. 用户隔离：4-04 使用的非管理员用户 A 与 4-03 中的非管理员用户必须不同，避免两个用例共享同一条日志记录而导致归属判断混淆。
2. 角色授予时机：应在产生 push/pull/delete 日志之前完成系统管理员角色的授予，否则无法验证"授予后"的完整查看能力。
3. 日志与操作对应性：验证日志内容时，重点核对OpTime（操作时间）、Operation（操作类型）与Username（操作者）三列是否与实际操作一致——这正是 DAO 层Create方法写入的字段（用户名超过 255 字符时会被截断为...结尾，见 src/pkg/audit/dao/dao.go）。
4. 过滤条件的语义：用例中的"push only / pull only / delete only / 组合条件 / 日期范围"对应查询接口的q关键字参数（操作类型）与时间范围参数。组合条件（如"push 与 delete"）验证的是多关键字同时生效的能力。
5. 结果为空是正常情况：若用户 A 在授予角色前产生的日志不属于任何可见项目，非管理员分支会返回空结果；授予系统管理员角色后则应全量可见。

七、与其他用例的关联

本用例是 Group4-logging 日志测试矩阵的一部分。与之配套的还有：

• 4-01-DB-user-view-logs.md：验证普通用户在 DB 模式下仅能看到自己所属项目的日志（对应源码中"非系统管理员按项目过滤"分支）；
• 4-05-LDAP-admin-role-view-logs.md：验证 LDAP 认证模式下同样的角色能力；
• 4-06-LDAP-usergroup-view-logs.md：验证通过 LDAP 用户组继承管理员权限时的日志可见性。

将 4-01 与 4-04 对比阅读，可以清晰看出 Harbor 审计日志的权限模型：普通用户按项目授权可见，系统管理员全局可见——这一设计在checkPermissionAndBuildQuery的分支逻辑中一目了然。

八、总结

Test 4-04 验证了 Harbor 在 DB 认证模式下"角色授予"与"日志查看"之间的等价关系：被赋予系统管理员角色的非管理员用户，其日志查看与检索能力与内置 admin 完全一致。结合源码可见，这一结论由IsSysAdmin()的判定逻辑与checkPermissionAndBuildQuery的全量可见分支共同保证。

本用例可作为 Harbor 部署后审计合规性验证的标准操作流程：创建测试用户 → 授予系统管理员角色 → 模拟 push/pull/delete → 在 UI 中按多维度过滤核对日志，从而确认审计日志功能的完整性与权限隔离的正确性。若你的 Harbor 实例使用 LDAP 认证，可参考同目录下的 4-05 与 4-06 用例完成等价的验证。

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