尧图网站建设 
Harbor 审计日志Audit Log实战DB 认证模式下管理员查看与筛选操作日志【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本指南基于 Harbor 开源仓库中的测试用例 4-03-DB-admin-view-logs.md 展开系统讲解在db_auth本地数据库认证模式下管理员如何查看与检索用户操作日志包括日志的生成来源push / pull / delete / create 等操作、底层audit_log表结构与查询接口实现、UI 端过滤条件的含义以及完整的端到端验证步骤。读完本文你将掌握 Harbor 日志审计功能的原理与标准验证方法能够独立复现该场景并排查日志缺失或过滤异常问题。一、测试用例定位Group4-logging 与日志审计该用例位于 tests/testcases/Group4-logging/ 目录下属于 Harbor 日志logging主题的测试组编号 4-03。它验证的核心场景是当 Harbor 以本地数据库DB modeauth_mode db_auth管理用户时管理员能够在 UI 中查看并筛选普通用户的全部操作日志。在该模式下用户数据保存在 Harbor 自身的 PostgreSQL 数据库中登录时由本地数据库进行认证这是 Harbor 开箱即用的默认认证方式也是验证日志审计功能最简单的环境前提。二、前置环境要求根据用例的 Environment 一节复现该场景需要满足三个条件Harbor 实例已启动并可用可通过 make/harbor.yml.tmpl 生成harbor.yml后执行安装脚本启动认证模式为db_auth即auth_mode配置为db_auth用户数据存储于本地数据库。这是 Harbor 默认认证模式一台装有 Docker CLI 的 Linux 主机用于执行docker login、docker push、docker pull等 Registry 操作。说明auth_mode在配置文件harbor.yml的auth段配置本文所述日志审计与认证模式本身解耦——只要操作发生并被写入audit_log管理员即可检索但db_auth是最简单、最不依赖外部认证源LDAP / OIDC / UAA的验证环境。三、日志从哪来审计日志的写入机制要理解为什么这些操作会被记录需要先看 Harbor 的审计日志实现。审计日志的模型与存储位于 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 }对应数据库表audit_log其建表语句位于 make/migrations/postgresql/0030_2.0.0_schema.up.sql字段类型说明idSERIAL PRIMARY KEY主键project_idint NOT NULL操作所属项目operationvarchar(20) NOT NULL操作类型push/pull/delete/createresource_typevarchar(255) NOT NULL资源类型project/artifact等resourcevarchar(1024) NOT NULL资源标识如仓库名或repo:tagusernamevarchar(255) NOT NULL操作者用户名op_timetimestamp default CURRENT_TIMESTAMP操作时间值得注意的迁移细节从 Harbor 2.0 起旧的access_log表被迁移为audit_log且操作类型发生了规范化——旧日志中的push在迁移时被改写为createresource_type 为artifactresource 拼接为repo:tagpull保持为pull镜像删除记录为delete。因此当前版本中镜像推送对应的 operation 是create而 UI 上显示的推送到镜像库是 create 操作这一点在理解日志过滤结果时非常关键见下文第四节。从源码结构看写入审计日志的入口为 src/pkg/audit/manager.go 中的Create方法它在写入数据库前会检查两个配置——若配置了AuditLogForwardEndpoint审计日志转发端点则同时向 syslog 等外部端点转发若设置了SkipAuditLogDatabase跳过数据库写入则直接返回。也就是说日志的落库行为可以通过这两个配置项控制。四、管理员如何查看与检索API 与权限模型日志查询的对外入口是 REST API。在 src/server/v2.0/handler/auditlog.go 中checkPermissionAndBuildQuery实现了权限过滤逻辑请求者必须已认证否则返回 401 Unauthorized若用户具备系统级listaudit_log资源权限即管理员则查询所有项目的日志否则系统会枚举该用户所属的全部项目仅保留其拥有项目日志查看权限listlog资源的项目将其ProjectID集合构造成OrList注入查询——这正是普通用户看不到其他项目日志的权限边界。查询链路为Handler 调用auditMgr.Count与auditMgr.List见 src/pkg/audit/manager.go底层 DAO 通过 beego ORM 执行带关键词过滤的查询见 src/pkg/audit/dao/dao.go支持按操作类型、时间范围、资源等条件过滤并按op_time默认倒序返回。为加速按时间与项目维度的检索数据库还建有索引idx_audit_log_op_time0060_2.3.0_schema.up.sql和idx_audit_log_project_id_optime0090_2.6.0_schema.up.sql。此外管理端还支持审计日志清理PurgeDAO 层通过DELETE FROM audit_log WHERE op_time NOW() - ? * interval 1 hour按保留时长清理过期日志并限定可清理的操作类型pull / create / delete支持 dry-run 预演见 src/pkg/audit/dao/dao.go可帮助控制日志表体积。UI 上的日志页面即调用上述GET /audit-logs接口管理员选择项目后可查看该项目的全部操作记录。五、完整验证步骤端到端实操以下步骤完整还原测试用例可在你的测试环境直接执行。第 1 步非管理员用户登录 Docker CLI在装有 Docker CLI 的主机上使用项目中创建的普通用户登录docker login harbor_host输入非管理员用户的用户名与密码。登录成功的前提是 Harbor 已配置db_auth且该用户已通过 UI 或 API 创建在本地数据库中。第 2 步产生 push / pull 操作向某项目推送镜像再从该项目拉取镜像# 为本地镜像打上 Harbor 仓库标签并推送 docker tag local_image harbor_host/project/repo:tag docker push harbor_host/project/repo:tag # 从 Harbor 拉取镜像 docker pull harbor_host/project/repo:tag可以多推几个 tag、多拉几次制造足够多的日志条目便于后续验证过滤效果。第 3 步以非管理员登录 UI浏览器访问 Harbor UI使用同一非管理员账号登录进入对应项目。第 4 步删除若干镜像在项目的镜像列表中删除几个镜像可同时删除多个 tag。删除操作会在审计日志中记录为delete操作。第 5 步切换为管理员退出非管理员账号使用admin或具备系统管理权限的账号登录 UI。第 6 步查看非管理员用户的日志管理员进入日志页面选择非管理员用户所在的项目应能看到该用户在第 2、4 步产生的全部操作记录。逐条核对**操作时间op_time**是否与实际操作时刻吻合操作类型是否正确推送对应 create、拉取对应 pull、删除对应 delete**操作者username**是否为该非管理员用户**资源resource**是否指向正确的项目/仓库:tag。第 7 步验证过滤条件在日志页面使用以下过滤组合逐一确认结果正确过滤条件预期结果push only仅拉取/推送的推送到镜像库操作只显示 create推送类记录pull only只显示 pull 类记录pull and push同时显示 pull 与 create推送记录delete only只显示 delete 类记录all显示该项目的全部日志push and delete只显示 create推送与 delete 记录不同日期范围时间过滤生效仅返回该区间内记录日期范围 push时间与操作类型双重过滤生效提示由于 Harbor 2.0 后推送操作在audit_log中统一记录为create见第三节迁移说明UI 过滤条件中的推送到镜像库push实际匹配的是 operation 为create的记录而 docker 客户端的docker pull对应 operation 为pull。若发现push 过滤结果为空请优先检查该版本 UI 过滤语义与底层 operation 值的对应关系。六、预期结果与判定标准Step 2 4 的全部操作均被记录非管理员用户的 push、pull、delete 操作都应出现在审计日志中且记录完整项目、操作类型、资源、用户、时间。Step 6 日志可查看且信息正确时间与操作内容与实际执行情况一致。Step 7 过滤可用上述 8 类过滤组合均返回正确结果无遗漏、无多余。若某类操作未出现在日志中可按下述顺序排查确认操作确实成功执行push/pull 无报错、删除在 UI 上成功确认当前账号是管理员或具备该项目的日志查看权限见第四节权限模型检查是否存在配置项影响写入如SKIP_LOG_AUDIT_DATABASEtrue会跳过数据库写入见 src/lib/config/metadata/metadatalist.go若日志量很大检查是否存在清理任务Purge按保留时长删除了旧日志。七、扩展审计日志相关配置项与日志审计直接相关的配置项定义在 src/lib/config/metadata/metadatalist.go 中供运维参考配置项EnvKey默认值说明audit_log_forward_endpointAUDIT_LOG_FORWARD_ENDPOINT空审计日志转发端点如 syslog配置后日志会同步转发skip_log_audit_databaseSKIP_LOG_AUDIT_DATABASEfalse是否跳过数据库写入审计日志pull_audit_log_disablePULL_AUDIT_LOG_DISABLEfalse是否关闭 pull 操作的审计日志audit_log_events_disabledAUDIT_LOG_EVENTS_DISABLED空跳过指定操作事件的日志格式如create_user,delete_usergdpr_audit_logsGDPR_AUDIT_LOGSfalse用户删除后其审计日志是否按 GDPR 匿名化处理这些配置可以在管理界面配置管理中查看部分需通过环境变量在部署时指定。合理组合这些开关可在完整审计与降低日志存储开销之间取得平衡。八、总结通过本文的端到端流程你已经掌握了 Harbor 在db_auth模式下日志审计功能的完整验证方法从 Docker CLI 产生 push/pull/delete 操作到管理员在 UI 中查看与多条件过滤日志再到理解底层audit_log表的字段语义与 API 权限模型。这一能力不仅用于回归测试如本用例也适用于日常安全审计——任何用户对镜像库的读写与删除行为都能被精确追踪与回溯。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor 审计日志（Audit Log）实战：DB 认证模式下管理员查看与筛选操作日志
Harbor 审计日志Audit Log实战DB 认证模式下管理员查看与筛选操作日志【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本指南基于 Harbor 开源仓库中的测试用例 4-03-DB-admin-view-logs.md 展开系统讲解在db_auth本地数据库认证模式下管理员如何查看与检索用户操作日志包括日志的生成来源push / pull / delete / create 等操作、底层audit_log表结构与查询接口实现、UI 端过滤条件的含义以及完整的端到端验证步骤。读完本文你将掌握 Harbor 日志审计功能的原理与标准验证方法能够独立复现该场景并排查日志缺失或过滤异常问题。一、测试用例定位Group4-logging 与日志审计该用例位于 tests/testcases/Group4-logging/ 目录下属于 Harbor 日志logging主题的测试组编号 4-03。它验证的核心场景是当 Harbor 以本地数据库DB modeauth_mode db_auth管理用户时管理员能够在 UI 中查看并筛选普通用户的全部操作日志。在该模式下用户数据保存在 Harbor 自身的 PostgreSQL 数据库中登录时由本地数据库进行认证这是 Harbor 开箱即用的默认认证方式也是验证日志审计功能最简单的环境前提。二、前置环境要求根据用例的 Environment 一节复现该场景需要满足三个条件Harbor 实例已启动并可用可通过 make/harbor.yml.tmpl 生成harbor.yml后执行安装脚本启动认证模式为db_auth即auth_mode配置为db_auth用户数据存储于本地数据库。这是 Harbor 默认认证模式一台装有 Docker CLI 的 Linux 主机用于执行docker login、docker push、docker pull等 Registry 操作。说明auth_mode在配置文件harbor.yml的auth段配置本文所述日志审计与认证模式本身解耦——只要操作发生并被写入audit_log管理员即可检索但db_auth是最简单、最不依赖外部认证源LDAP / OIDC / UAA的验证环境。三、日志从哪来审计日志的写入机制要理解为什么这些操作会被记录需要先看 Harbor 的审计日志实现。审计日志的模型与存储位于 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 }对应数据库表audit_log其建表语句位于 make/migrations/postgresql/0030_2.0.0_schema.up.sql字段类型说明idSERIAL PRIMARY KEY主键project_idint NOT NULL操作所属项目operationvarchar(20) NOT NULL操作类型push/pull/delete/createresource_typevarchar(255) NOT NULL资源类型project/artifact等resourcevarchar(1024) NOT NULL资源标识如仓库名或repo:tagusernamevarchar(255) NOT NULL操作者用户名op_timetimestamp default CURRENT_TIMESTAMP操作时间值得注意的迁移细节从 Harbor 2.0 起旧的access_log表被迁移为audit_log且操作类型发生了规范化——旧日志中的push在迁移时被改写为createresource_type 为artifactresource 拼接为repo:tagpull保持为pull镜像删除记录为delete。因此当前版本中镜像推送对应的 operation 是create而 UI 上显示的推送到镜像库是 create 操作这一点在理解日志过滤结果时非常关键见下文第四节。从源码结构看写入审计日志的入口为 src/pkg/audit/manager.go 中的Create方法它在写入数据库前会检查两个配置——若配置了AuditLogForwardEndpoint审计日志转发端点则同时向 syslog 等外部端点转发若设置了SkipAuditLogDatabase跳过数据库写入则直接返回。也就是说日志的落库行为可以通过这两个配置项控制。四、管理员如何查看与检索API 与权限模型日志查询的对外入口是 REST API。在 src/server/v2.0/handler/auditlog.go 中checkPermissionAndBuildQuery实现了权限过滤逻辑请求者必须已认证否则返回 401 Unauthorized若用户具备系统级listaudit_log资源权限即管理员则查询所有项目的日志否则系统会枚举该用户所属的全部项目仅保留其拥有项目日志查看权限listlog资源的项目将其ProjectID集合构造成OrList注入查询——这正是普通用户看不到其他项目日志的权限边界。查询链路为Handler 调用auditMgr.Count与auditMgr.List见 src/pkg/audit/manager.go底层 DAO 通过 beego ORM 执行带关键词过滤的查询见 src/pkg/audit/dao/dao.go支持按操作类型、时间范围、资源等条件过滤并按op_time默认倒序返回。为加速按时间与项目维度的检索数据库还建有索引idx_audit_log_op_time0060_2.3.0_schema.up.sql和idx_audit_log_project_id_optime0090_2.6.0_schema.up.sql。此外管理端还支持审计日志清理PurgeDAO 层通过DELETE FROM audit_log WHERE op_time NOW() - ? * interval 1 hour按保留时长清理过期日志并限定可清理的操作类型pull / create / delete支持 dry-run 预演见 src/pkg/audit/dao/dao.go可帮助控制日志表体积。UI 上的日志页面即调用上述GET /audit-logs接口管理员选择项目后可查看该项目的全部操作记录。五、完整验证步骤端到端实操以下步骤完整还原测试用例可在你的测试环境直接执行。第 1 步非管理员用户登录 Docker CLI在装有 Docker CLI 的主机上使用项目中创建的普通用户登录docker login harbor_host输入非管理员用户的用户名与密码。登录成功的前提是 Harbor 已配置db_auth且该用户已通过 UI 或 API 创建在本地数据库中。第 2 步产生 push / pull 操作向某项目推送镜像再从该项目拉取镜像# 为本地镜像打上 Harbor 仓库标签并推送 docker tag local_image harbor_host/project/repo:tag docker push harbor_host/project/repo:tag # 从 Harbor 拉取镜像 docker pull harbor_host/project/repo:tag可以多推几个 tag、多拉几次制造足够多的日志条目便于后续验证过滤效果。第 3 步以非管理员登录 UI浏览器访问 Harbor UI使用同一非管理员账号登录进入对应项目。第 4 步删除若干镜像在项目的镜像列表中删除几个镜像可同时删除多个 tag。删除操作会在审计日志中记录为delete操作。第 5 步切换为管理员退出非管理员账号使用admin或具备系统管理权限的账号登录 UI。第 6 步查看非管理员用户的日志管理员进入日志页面选择非管理员用户所在的项目应能看到该用户在第 2、4 步产生的全部操作记录。逐条核对**操作时间op_time**是否与实际操作时刻吻合操作类型是否正确推送对应 create、拉取对应 pull、删除对应 delete**操作者username**是否为该非管理员用户**资源resource**是否指向正确的项目/仓库:tag。第 7 步验证过滤条件在日志页面使用以下过滤组合逐一确认结果正确过滤条件预期结果push only仅拉取/推送的推送到镜像库操作只显示 create推送类记录pull only只显示 pull 类记录pull and push同时显示 pull 与 create推送记录delete only只显示 delete 类记录all显示该项目的全部日志push and delete只显示 create推送与 delete 记录不同日期范围时间过滤生效仅返回该区间内记录日期范围 push时间与操作类型双重过滤生效提示由于 Harbor 2.0 后推送操作在audit_log中统一记录为create见第三节迁移说明UI 过滤条件中的推送到镜像库push实际匹配的是 operation 为create的记录而 docker 客户端的docker pull对应 operation 为pull。若发现push 过滤结果为空请优先检查该版本 UI 过滤语义与底层 operation 值的对应关系。六、预期结果与判定标准Step 2 4 的全部操作均被记录非管理员用户的 push、pull、delete 操作都应出现在审计日志中且记录完整项目、操作类型、资源、用户、时间。Step 6 日志可查看且信息正确时间与操作内容与实际执行情况一致。Step 7 过滤可用上述 8 类过滤组合均返回正确结果无遗漏、无多余。若某类操作未出现在日志中可按下述顺序排查确认操作确实成功执行push/pull 无报错、删除在 UI 上成功确认当前账号是管理员或具备该项目的日志查看权限见第四节权限模型检查是否存在配置项影响写入如SKIP_LOG_AUDIT_DATABASEtrue会跳过数据库写入见 src/lib/config/metadata/metadatalist.go若日志量很大检查是否存在清理任务Purge按保留时长删除了旧日志。七、扩展审计日志相关配置项与日志审计直接相关的配置项定义在 src/lib/config/metadata/metadatalist.go 中供运维参考配置项EnvKey默认值说明audit_log_forward_endpointAUDIT_LOG_FORWARD_ENDPOINT空审计日志转发端点如 syslog配置后日志会同步转发skip_log_audit_databaseSKIP_LOG_AUDIT_DATABASEfalse是否跳过数据库写入审计日志pull_audit_log_disablePULL_AUDIT_LOG_DISABLEfalse是否关闭 pull 操作的审计日志audit_log_events_disabledAUDIT_LOG_EVENTS_DISABLED空跳过指定操作事件的日志格式如create_user,delete_usergdpr_audit_logsGDPR_AUDIT_LOGSfalse用户删除后其审计日志是否按 GDPR 匿名化处理这些配置可以在管理界面配置管理中查看部分需通过环境变量在部署时指定。合理组合这些开关可在完整审计与降低日志存储开销之间取得平衡。八、总结通过本文的端到端流程你已经掌握了 Harbor 在db_auth模式下日志审计功能的完整验证方法从 Docker CLI 产生 push/pull/delete 操作到管理员在 UI 中查看与多条件过滤日志再到理解底层audit_log表的字段语义与 API 权限模型。这一能力不仅用于回归测试如本用例也适用于日常安全审计——任何用户对镜像库的读写与删除行为都能被精确追踪与回溯。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考