拓冰网站定制 
Harbor 数据库认证DB Mode下非管理员用户查看与过滤操作日志的完整验证指南【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文基于 Harbor 仓库中的测试用例 4-01-DB-user-view-logs.md 展开系统性地讲解在auth_mode 为db_auth本地数据库认证的 Harbor 环境中如何验证非管理员用户能否正确查看项目操作日志审计日志并逐一验证 push / pull / delete 等操作是否被完整记录、以及日志过滤功能是否按预期工作。读完本文你将掌握一套可直接复跑的端到端验证流程并理解 Harbor 审计日志从记录 → 存储 → 权限过滤 → 查询的完整链路及其底层源码实现。测试目标与适用场景该测试用例属于 Harbor 仓库tests/testcases/Group4-logging日志功能测试组的第一个用例核心目标只有一个验证当用户由 Harbor 本地数据库DB 模式统一管理时非管理员用户能够查看其有权限项目的操作日志且日志可以被正确记录、浏览与过滤。这个场景在真实生产中非常常见一个团队把 Harbor 的认证模式配置为本地数据库auth_mode: db_auth各项目成员非系统管理员需要自行查看自己参与的项目的操作历史用于排查谁在什么时候 push / pull / delete 了什么镜像。系统管理员则可以看到全部审计日志。说明Harbor 的认证模式还支持 LDAP / OIDC / UAA 等外部认证。本文用例仅覆盖DB 模式用户数据存储在 Harbor 本地数据库这是验证本地用户权限与日志隔离性的基础场景。前置条件Environment在执行测试前需要确认以下环境全部就绪前置条件说明Harbor 实例一个正在运行、可访问的 Harbor 实例认证模式Harbor 配置为本地数据库认证即auth_mode设为db_auth用户数据存放在本地数据库客户端主机一台安装了 Docker CLIDocker 客户端的 Linux 主机用户账号至少一个非管理员用户账号由本地数据库管理项目与镜像项目中存在可 push / pull / delete 的镜像且该非管理员用户对该项目拥有相应权限如开发人员或项目管理员其中认证模式在 Harbor 安装配置文件make/harbor.yml.tmpl可查看配置模板中以auth_mode参数体现修改后需重新运行make/prepare并重启服务才会生效。核心验证步骤Test Steps整个验证过程分为六步登录 → 制造操作 → UI 登录 → 删除镜像 → 查看日志 → 过滤日志。Step 1以非管理员用户身份登录 Docker 客户端在安装了 Docker CLI 的主机上使用非管理员用户账号登录 Harbordocker login harbor_hostharbor_host替换为实际的 Harbor 地址如192.168.1.10或myharbor.example.com输入的是非管理员用户的用户名与密码该用户必须是某个项目的成员否则后续将没有可查看的日志项目。Step 2执行 push 与 pull 操作制造日志登录成功后执行一批docker push和docker pull命令向 Harbor 推送镜像并从 Harbor 拉取镜像。例如# 为镜像打上 Harbor 仓库标签 docker tag nginx:latest harbor_host/project/nginx:latest # 推送镜像到 Harbor docker push harbor_host/project/nginx:latest # 从 Harbor 拉取镜像 docker pull harbor_host/project/nginx:latest这些操作是后续验证日志是否被记录的核心素材。建议 push 和 pull 各执行若干次并故意穿插执行方便后面验证只过滤 push只过滤 pull同时过滤 pull 和 push等组合条件。Step 3以非管理员用户登录 Web UI打开 Harbor Web 界面使用与 Step 1 相同的非管理员账号登录。此步骤验证的是非管理员用户能够正常进入 Harbor 门户并看到自己有权限的项目。Step 4删除项目中的部分镜像在 UI 中进入相应项目删除刚才推送的若干镜像或镜像的某个 tag。删除操作同样会进入日志用于验证delete类型的日志记录与过滤。Step 5查看项目日志在项目页面中打开日志Logs / 审计日志视图此时应能看到此前发生的 push、pull、delete 操作记录。重点核对每条日志的时间与操作内容是否与实际操作一致。Step 6逐项验证日志过滤条件测试用例要求使用以下搜索条件逐一过滤日志并确认过滤结果正确过滤组合预期语义push only只显示 push 操作pull only只显示 pull 操作pull and push同时显示 pull 和 push 两类操作delete only只显示 delete 操作all显示全部操作不限制操作类型push and delete同时显示 push 和 delete 两类操作不同日期范围date ranges按不同的起止时间区间过滤日期范围 push时间区间与操作类型组合过滤每次切换过滤条件后都应检查返回列表是否只包含符合条件的日志尤其是组合条件日期范围 push用于验证多个条件同时生效时的过滤逻辑。预期结果Expected Outcome测试通过的标准如下缺一不可Step 2 与 Step 4 的所有操作都应被记录push、pull、delete 全部出现在日志中不存在遗漏Step 5 可以正常查看日志日志列表可见且每条日志的时间与操作内容正确Step 6 的过滤功能生效所有列出的过滤条件都能返回与条件匹配的正确结果。只有同时满足以上三点才认为该用例通过即DB 模式下非管理员用户查看日志功能正常。从源码看审计日志的完整链路仅仅跑通 UI 还不够理解底层实现能帮助你在测试不通过时快速定位问题。下面结合本仓库源码说明 Harbor 审计日志从产生到展示的完整链路。日志数据模型audit_log 表审计日志在数据库中对应audit_log表其 ORM 模型定义在 src/pkg/audit/model/model.gotype 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 } func (a *AuditLog) TableName() string { return audit_log }从字段可以看出每条日志的核心信息属于哪个项目project_id、什么操作operation如 push / pull / delete、操作对象resource与resource_type、谁做的username、什么时间op_time。其中op_time默认按降序排序所以日志列表默认展示最新记录在前——这也是 UI 中时间倒序的底层来源。日志的写入请求中间件 事件通知操作日志并非由业务代码手动一条条写入而是通过 HTTP 请求中间件统一捕获。中间件实现位于 src/server/middleware/log/log.go其核心流程为从请求中提取X-Request-ID、trace ID 等信息附加到日志上下文构造commonevent.Metadata记录用户名默认unknown若已认证则取安全上下文中的用户名、请求方法RequestMethod、请求 URLRequestURL通过PreCheckMetadata()判断该请求是否属于需要记录审计的操作对需要审计的请求读取请求体受common.MaxAuditLogPayloadSize限制超出则直接返回413 Request Entity Too Large记录响应码并通过notification.AddEvent将事件投递到通知系统最终落库。同时审计日志的管理接口定义在 src/pkg/audit/manager.go提供Count、List、Get、Create、Delete、Purge按保留小时数清理旧日志等方法。这也是Step 4 删除镜像后 delete 操作也会被记录的实现基础——只要请求走了标准中间件链路就会统一生成审计事件。日志的查询与权限隔离非管理员只能看到自己有权访问的项目这是本用例最关键的验证点非管理员用户查看日志时系统如何保证他看不到其他项目的日志答案在 API Handler 中src/server/v2.0/handler/auditlog.go 的checkPermissionAndBuildQuery函数先校验用户已认证未认证直接返回 401 Unauthorized尝试以系统级权限查询RequireSystemAccess(ctx, rbac.ActionList, rbac.ResourceAuditLog)若用户不是系统管理员则改为列出该用户参与的所有项目通过projectCtl.List查询成员关系同时考虑用户所属用户组GroupIDs对每个项目进一步检查用户是否具备项目级日志查看权限HasProjectPermission(ctx, project.ProjectID, rbac.ActionList, rbac.ResourceLog)最终把有权限的项目 ID 集合构造成一个 OrList作为ProjectID关键词追加到查询条件中——没有权限的项目一条日志都不会返回如果没有任何有权限的项目会塞入-1保证查询结果为空。对应的 RBAC 资源定义见 src/common/rbac/const.go项目级资源ResourceLog Resource(log)项目日志系统级资源ResourceAuditLog Resource(audit-log)全局审计日志。而项目角色对日志的权限映射在 src/common/rbac/project/rbac_role.go{Resource: rbac.ResourceLog, Action: rbac.ActionList}即只有具备对应项目角色的用户才拥有log资源的list动作。换句话说本用例的通过条件本质上是验证项目成员 → 项目角色 → log 资源 list 权限 → 查询条件注入这条权限链是否完整生效。对应的 REST API日志查询对应的 API 定义在 api/v2.0/swagger.yaml主要包括GET /audit-logs获取用户作为项目管理员成员的项目的近期操作日志系统管理员可获取全部审计日志旧版接口已标记 deprecatedGET /auditlog-exts获取用户作为项目管理员成员的项目的近期操作日志或系统管理员获取全部审计日志扩展字段包含操作描述与结果GET /projects/{project_name}/logs获取指定项目的近期日志旧版项目级接口已标记 deprecatedGET /auditlog-exts/events获取审计日志的全部事件类型。这些接口均支持q查询条件、sort、page、pageSize参数返回X-Total-Count总条数头与Link分页链接——UI 上的日志过滤与分页正是通过q查询参数如按操作类型、按时间范围组合过滤实现的这与 Step 6 中验证的过滤条件一一对应。过滤条件的实际应用建议在执行 Step 6 时以下几点能帮助你更准确地完成验证操作类型维度先单独验证单一类型push only / pull only / delete only确认各类型都被正确标记与过滤再做组合pull and push / push and delete确认多选逻辑为并集关系时间维度先选择一个覆盖全部操作的大时间范围all再缩小到一个只覆盖部分操作的窄范围验证边界时间点上的日志是否被正确包含或排除组合维度最后验证日期范围 push这类跨维度组合确认不同类型条件之间是交集AND关系空结果检查故意选择一段没有任何操作的时间范围确认返回空列表且不报错验证过滤逻辑对空结果的健壮性。常见问题排查基于源码线索如果测试失败可以从以下方向入手定位日志完全没有记录检查请求是否经过src/server/middleware/log/log.go的中间件链路确认请求体大小未超过common.MaxAuditLogPayloadSize超限会直接返回 413非管理员看不到日志重点检查 src/server/v2.0/handler/auditlog.go 的权限判定逻辑确认用户的项目角色在 src/common/rbac/project/rbac_role.go 中确实映射了log资源的list权限时间/操作内容不正确对照audit_log表中的op_time、operation、resource字段与 UI 展示是否一致可借助数据库客户端直接查询audit_log表核对原始数据过滤结果不对确认q查询参数的格式与 src/pkg/audit/manager.go 中Count/List的实现一致过滤条件最终会转换为 SQL 查询下推到数据库执行。总结本用例通过一次完整的端到端验证覆盖了 Harbor 在DB 认证模式下非管理员用户查看日志的全部关键路径Docker 客户端的 push / pull、UI 中的镜像删除、日志的查看与八种过滤组合。结合源码可以看到Harbor 通过请求中间件统一捕获操作事件、以audit_log表持久化并在 API 层通过系统级权限 项目级log资源list权限双层校验实现严格的日志隔离——这也是企业生产环境审计合规谁在何时对哪个镜像做了什么的基石。如需进一步扩展验证可参考仓库中的其他日志相关测试用例tests/testcases/Group4-logging/目录并结合 src/pkg/audit 与 src/server/v2.0/handler/auditlog.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 Mode）下非管理员用户查看与过滤操作日志的完整验证指南
Harbor 数据库认证DB Mode下非管理员用户查看与过滤操作日志的完整验证指南【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文基于 Harbor 仓库中的测试用例 4-01-DB-user-view-logs.md 展开系统性地讲解在auth_mode 为db_auth本地数据库认证的 Harbor 环境中如何验证非管理员用户能否正确查看项目操作日志审计日志并逐一验证 push / pull / delete 等操作是否被完整记录、以及日志过滤功能是否按预期工作。读完本文你将掌握一套可直接复跑的端到端验证流程并理解 Harbor 审计日志从记录 → 存储 → 权限过滤 → 查询的完整链路及其底层源码实现。测试目标与适用场景该测试用例属于 Harbor 仓库tests/testcases/Group4-logging日志功能测试组的第一个用例核心目标只有一个验证当用户由 Harbor 本地数据库DB 模式统一管理时非管理员用户能够查看其有权限项目的操作日志且日志可以被正确记录、浏览与过滤。这个场景在真实生产中非常常见一个团队把 Harbor 的认证模式配置为本地数据库auth_mode: db_auth各项目成员非系统管理员需要自行查看自己参与的项目的操作历史用于排查谁在什么时候 push / pull / delete 了什么镜像。系统管理员则可以看到全部审计日志。说明Harbor 的认证模式还支持 LDAP / OIDC / UAA 等外部认证。本文用例仅覆盖DB 模式用户数据存储在 Harbor 本地数据库这是验证本地用户权限与日志隔离性的基础场景。前置条件Environment在执行测试前需要确认以下环境全部就绪前置条件说明Harbor 实例一个正在运行、可访问的 Harbor 实例认证模式Harbor 配置为本地数据库认证即auth_mode设为db_auth用户数据存放在本地数据库客户端主机一台安装了 Docker CLIDocker 客户端的 Linux 主机用户账号至少一个非管理员用户账号由本地数据库管理项目与镜像项目中存在可 push / pull / delete 的镜像且该非管理员用户对该项目拥有相应权限如开发人员或项目管理员其中认证模式在 Harbor 安装配置文件make/harbor.yml.tmpl可查看配置模板中以auth_mode参数体现修改后需重新运行make/prepare并重启服务才会生效。核心验证步骤Test Steps整个验证过程分为六步登录 → 制造操作 → UI 登录 → 删除镜像 → 查看日志 → 过滤日志。Step 1以非管理员用户身份登录 Docker 客户端在安装了 Docker CLI 的主机上使用非管理员用户账号登录 Harbordocker login harbor_hostharbor_host替换为实际的 Harbor 地址如192.168.1.10或myharbor.example.com输入的是非管理员用户的用户名与密码该用户必须是某个项目的成员否则后续将没有可查看的日志项目。Step 2执行 push 与 pull 操作制造日志登录成功后执行一批docker push和docker pull命令向 Harbor 推送镜像并从 Harbor 拉取镜像。例如# 为镜像打上 Harbor 仓库标签 docker tag nginx:latest harbor_host/project/nginx:latest # 推送镜像到 Harbor docker push harbor_host/project/nginx:latest # 从 Harbor 拉取镜像 docker pull harbor_host/project/nginx:latest这些操作是后续验证日志是否被记录的核心素材。建议 push 和 pull 各执行若干次并故意穿插执行方便后面验证只过滤 push只过滤 pull同时过滤 pull 和 push等组合条件。Step 3以非管理员用户登录 Web UI打开 Harbor Web 界面使用与 Step 1 相同的非管理员账号登录。此步骤验证的是非管理员用户能够正常进入 Harbor 门户并看到自己有权限的项目。Step 4删除项目中的部分镜像在 UI 中进入相应项目删除刚才推送的若干镜像或镜像的某个 tag。删除操作同样会进入日志用于验证delete类型的日志记录与过滤。Step 5查看项目日志在项目页面中打开日志Logs / 审计日志视图此时应能看到此前发生的 push、pull、delete 操作记录。重点核对每条日志的时间与操作内容是否与实际操作一致。Step 6逐项验证日志过滤条件测试用例要求使用以下搜索条件逐一过滤日志并确认过滤结果正确过滤组合预期语义push only只显示 push 操作pull only只显示 pull 操作pull and push同时显示 pull 和 push 两类操作delete only只显示 delete 操作all显示全部操作不限制操作类型push and delete同时显示 push 和 delete 两类操作不同日期范围date ranges按不同的起止时间区间过滤日期范围 push时间区间与操作类型组合过滤每次切换过滤条件后都应检查返回列表是否只包含符合条件的日志尤其是组合条件日期范围 push用于验证多个条件同时生效时的过滤逻辑。预期结果Expected Outcome测试通过的标准如下缺一不可Step 2 与 Step 4 的所有操作都应被记录push、pull、delete 全部出现在日志中不存在遗漏Step 5 可以正常查看日志日志列表可见且每条日志的时间与操作内容正确Step 6 的过滤功能生效所有列出的过滤条件都能返回与条件匹配的正确结果。只有同时满足以上三点才认为该用例通过即DB 模式下非管理员用户查看日志功能正常。从源码看审计日志的完整链路仅仅跑通 UI 还不够理解底层实现能帮助你在测试不通过时快速定位问题。下面结合本仓库源码说明 Harbor 审计日志从产生到展示的完整链路。日志数据模型audit_log 表审计日志在数据库中对应audit_log表其 ORM 模型定义在 src/pkg/audit/model/model.gotype 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 } func (a *AuditLog) TableName() string { return audit_log }从字段可以看出每条日志的核心信息属于哪个项目project_id、什么操作operation如 push / pull / delete、操作对象resource与resource_type、谁做的username、什么时间op_time。其中op_time默认按降序排序所以日志列表默认展示最新记录在前——这也是 UI 中时间倒序的底层来源。日志的写入请求中间件 事件通知操作日志并非由业务代码手动一条条写入而是通过 HTTP 请求中间件统一捕获。中间件实现位于 src/server/middleware/log/log.go其核心流程为从请求中提取X-Request-ID、trace ID 等信息附加到日志上下文构造commonevent.Metadata记录用户名默认unknown若已认证则取安全上下文中的用户名、请求方法RequestMethod、请求 URLRequestURL通过PreCheckMetadata()判断该请求是否属于需要记录审计的操作对需要审计的请求读取请求体受common.MaxAuditLogPayloadSize限制超出则直接返回413 Request Entity Too Large记录响应码并通过notification.AddEvent将事件投递到通知系统最终落库。同时审计日志的管理接口定义在 src/pkg/audit/manager.go提供Count、List、Get、Create、Delete、Purge按保留小时数清理旧日志等方法。这也是Step 4 删除镜像后 delete 操作也会被记录的实现基础——只要请求走了标准中间件链路就会统一生成审计事件。日志的查询与权限隔离非管理员只能看到自己有权访问的项目这是本用例最关键的验证点非管理员用户查看日志时系统如何保证他看不到其他项目的日志答案在 API Handler 中src/server/v2.0/handler/auditlog.go 的checkPermissionAndBuildQuery函数先校验用户已认证未认证直接返回 401 Unauthorized尝试以系统级权限查询RequireSystemAccess(ctx, rbac.ActionList, rbac.ResourceAuditLog)若用户不是系统管理员则改为列出该用户参与的所有项目通过projectCtl.List查询成员关系同时考虑用户所属用户组GroupIDs对每个项目进一步检查用户是否具备项目级日志查看权限HasProjectPermission(ctx, project.ProjectID, rbac.ActionList, rbac.ResourceLog)最终把有权限的项目 ID 集合构造成一个 OrList作为ProjectID关键词追加到查询条件中——没有权限的项目一条日志都不会返回如果没有任何有权限的项目会塞入-1保证查询结果为空。对应的 RBAC 资源定义见 src/common/rbac/const.go项目级资源ResourceLog Resource(log)项目日志系统级资源ResourceAuditLog Resource(audit-log)全局审计日志。而项目角色对日志的权限映射在 src/common/rbac/project/rbac_role.go{Resource: rbac.ResourceLog, Action: rbac.ActionList}即只有具备对应项目角色的用户才拥有log资源的list动作。换句话说本用例的通过条件本质上是验证项目成员 → 项目角色 → log 资源 list 权限 → 查询条件注入这条权限链是否完整生效。对应的 REST API日志查询对应的 API 定义在 api/v2.0/swagger.yaml主要包括GET /audit-logs获取用户作为项目管理员成员的项目的近期操作日志系统管理员可获取全部审计日志旧版接口已标记 deprecatedGET /auditlog-exts获取用户作为项目管理员成员的项目的近期操作日志或系统管理员获取全部审计日志扩展字段包含操作描述与结果GET /projects/{project_name}/logs获取指定项目的近期日志旧版项目级接口已标记 deprecatedGET /auditlog-exts/events获取审计日志的全部事件类型。这些接口均支持q查询条件、sort、page、pageSize参数返回X-Total-Count总条数头与Link分页链接——UI 上的日志过滤与分页正是通过q查询参数如按操作类型、按时间范围组合过滤实现的这与 Step 6 中验证的过滤条件一一对应。过滤条件的实际应用建议在执行 Step 6 时以下几点能帮助你更准确地完成验证操作类型维度先单独验证单一类型push only / pull only / delete only确认各类型都被正确标记与过滤再做组合pull and push / push and delete确认多选逻辑为并集关系时间维度先选择一个覆盖全部操作的大时间范围all再缩小到一个只覆盖部分操作的窄范围验证边界时间点上的日志是否被正确包含或排除组合维度最后验证日期范围 push这类跨维度组合确认不同类型条件之间是交集AND关系空结果检查故意选择一段没有任何操作的时间范围确认返回空列表且不报错验证过滤逻辑对空结果的健壮性。常见问题排查基于源码线索如果测试失败可以从以下方向入手定位日志完全没有记录检查请求是否经过src/server/middleware/log/log.go的中间件链路确认请求体大小未超过common.MaxAuditLogPayloadSize超限会直接返回 413非管理员看不到日志重点检查 src/server/v2.0/handler/auditlog.go 的权限判定逻辑确认用户的项目角色在 src/common/rbac/project/rbac_role.go 中确实映射了log资源的list权限时间/操作内容不正确对照audit_log表中的op_time、operation、resource字段与 UI 展示是否一致可借助数据库客户端直接查询audit_log表核对原始数据过滤结果不对确认q查询参数的格式与 src/pkg/audit/manager.go 中Count/List的实现一致过滤条件最终会转换为 SQL 查询下推到数据库执行。总结本用例通过一次完整的端到端验证覆盖了 Harbor 在DB 认证模式下非管理员用户查看日志的全部关键路径Docker 客户端的 push / pull、UI 中的镜像删除、日志的查看与八种过滤组合。结合源码可以看到Harbor 通过请求中间件统一捕获操作事件、以audit_log表持久化并在 API 层通过系统级权限 项目级log资源list权限双层校验实现严格的日志隔离——这也是企业生产环境审计合规谁在何时对哪个镜像做了什么的基石。如需进一步扩展验证可参考仓库中的其他日志相关测试用例tests/testcases/Group4-logging/目录并结合 src/pkg/audit 与 src/server/v2.0/handler/auditlog.go 深入理解实现细节。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考