尧图网站建设 
Harbor 内容信任Content Trust实战在 DB 模式下推送签名镜像的测试与原理剖析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文以 Harbor 仓库 tests/testcases/Group9-Content-trust/9-01-DB-user-push-signed-images.md 这一官方测试用例为骨架完整还原在 DB 认证模式下普通用户开启 Docker Content Trust 并推送签名镜像的验证流程并结合仓库源码剖析签名状态在 UI 中如何呈现、项目级内容信任策略如何在拉取链路中被强制执行。读完本文你将能够复现签名/未签名镜像的推送验证理解DOCKER_CONTENT_TRUST系列环境变量、Notary/签名服务端点配置方式以及 Harbor 底层基于 cosign/notation 签名附件Accessory的信任校验机制。1. 用例背景与测试目标内容信任Content Trust用于确保从仓库拉取的镜像确实是发布者构建并签名过的内容防止镜像被篡改或在传输过程中被替换。在 Harbor 中这一能力通过接入 Docker Content Trust 体系实现Docker 客户端在开启信任后推送镜像时会先对镜像进行签名再将镜像与签名一并推送到 Harbor。测试用例 9-01 属于 Group9-Content-trust 测试组目标非常明确验证在 DB本地数据库认证模式下普通用户可以开启内容信任并成功推送签名镜像同时验证签名结果能够在 Harbor UI 上被直观标识出来绿色对勾。仓库中同一测试组还包含 LDAP 模式9-11-LDAP-user-push-signed-images.md与管理员模式9-21-admin-push-signed-images.md的等价用例三者的核心步骤完全一致区别仅在于认证体系与用户身份印证了该流程在不同认证模式下的通用性。2. 测试环境要求环境项要求Harbor 实例一台正在运行且可访问的 Harbor 实例DB 认证模式客户端一台装有 Docker CLIDocker 客户端的 Linux 主机3. 测试前置证书与信任端点说明用例原文给出了两条关键前置说明直接影响命令能否执行成功文中的harbor_ip需要替换为 Harbor 的实际 IP 或 FQDN如果使用自签名证书必须把 CA 根证书复制到以下两个位置/etc/docker/certs.d/harbor_ip/Docker 客户端验证 Harbor 镜像仓库 TLS 证书的可信根目录$HOME/.docker/tls/harbor_ip:4443/Docker Content Trust 客户端Notary 客户端验证签名服务端证书的可信根目录其中4443是签名服务Notary Server的默认 HTTPS 端口。注意本仓库当前版本已将 Notary 从安装链路中移除见 make/install.sh 中的提示notary has been deprecated and removed。该端口配置源自用例编写时的 Notary 时代在后续源码剖析小节中你会看到当前 Harbor 的信任校验已演进为基于 cosign/notation 签名附件实现但从 Docker 客户端视角看开启 Content Trust 并推送签名镜像的交互流程与验证语义依然保持一致。4. 测试步骤推送签名镜像DB 模式步骤 1登录 UI 并创建项目通过浏览器登录 Harbor Web 界面创建一个新项目下文以project_name指代。项目创建后即获得一个独立的命名空间用于存放镜像。步骤 2在 Docker 客户端启用内容信任并登录在 Linux Docker 客户端上执行export DOCKER_CONTENT_TRUST1 export DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443参数说明环境变量作用DOCKER_CONTENT_TRUST1开启 Docker 客户端的 Content Trust 功能此后所有push/pull操作都会附带签名行为DOCKER_CONTENT_TRUST_SERVER指定签名服务端点Notary Server 地址Docker 会将签名上传到该服务随后登录 Harbordocker login harbor_ip输入具有该项目推送权限的用户名与密码完成认证。步骤 3推送镜像将镜像推送到步骤 1 创建的项目docker tag local_image harbor_ip/project_name/image_name:tag docker push harbor_ip/project_name/image_name:tag在DOCKER_CONTENT_TRUST1生效的情况下Docker 客户端会在推送前自动对镜像进行签名首次推送会引导你设置签名密钥的密码短语随后生成根密钥与仓库密钥并将签名上传到DOCKER_CONTENT_TRUST_SERVER指定的签名服务。5. 期望结果签名镜像的 UI 标识用例的 Expected Outcome 只有一条但信息量很大步骤 3 中Docker 客户端会完成签名与推送UI 上会显示一个绿色对勾green tick。这个绿色对勾来自 Harbor Portal 的制品Artifact列表页面。从仓库前端源码可以看到签名列co-signed-column会根据制品签名状态渲染不同图标artifact-list-tab.component.html 中按artifact.signed状态分支显示true渲染signed图标绿色对勾、false渲染未签名标识红色叉、checking显示检测中的状态artifact-list-tab.component.ts 中签名的判定逻辑是通过查询制品的Accessories附件判断是否存在 cosign / notation 类型的签名附件进而设置signed状态。也就是说UI 上的绿勾/红叉并非简单由推送方式推断而是后端根据制品实际携带的签名附件实时计算得出的这正是签名状态可信的底层原因。6. 对照实验未签名镜像显示红色叉为验证 UI 能够区分签名与未签名镜像同一测试组提供了对照组用例 9-02-DB-user-push-unsigned-images.md登录 UI 并创建项目在 Docker 客户端不设置DOCKER_CONTENT_TRUST即保持未开启状态或执行unset DOCKER_CONTENT_TRUST登录 Harbor向项目推送一个镜像。期望结果该镜像在 UI 的签名列下会显示红色叉red cross。这一正反对照表明Harbor 能够通过制品的签名附件实时标识其签名状态为项目级信任策略的可视化决策提供依据。7. 进阶项目级内容信任策略9-30仅显示状态还不够Harbor 还支持在项目维度强制内容信任。用例 9-30-Project-level-content-trust.md 验证了该策略登录 UI 创建项目先向项目推送一个未签名镜像在 Docker 客户端设置DOCKER_CONTENT_TRUST1与DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443登录后再推送一个签名镜像在项目配置页面启用项目级内容信任对应 UI 中的 Content Trust 开关分别拉取第 2 步未签名与第 4 步签名推送的镜像。期望结果拉取未签名镜像失败策略拒绝拉取签名镜像成功。这说明项目级内容信任策略作用于拉取pull链路一旦启用未签名制品将无法被拉取从而在消费侧强制保证镜像来源可信。8. 源码剖析内容信任如何被强制执行理解了 UI 表现与项目级策略后再看 Harbor 后端如何落地这一机制。8.1 项目元数据中的信任开关项目级内容信任由两个元数据键控制定义于 src/pkg/project/models/pro_meta.go元数据键含义enable_content_trust启用内容信任要求制品存在 notation 类型签名enable_content_trust_cosign启用 cosign 内容信任要求制品存在 cosign 类型签名对应读取逻辑在 src/pkg/project/models/project.go 的ContentTrustEnabled()与ContentTrustCosignEnabled()中实现——从项目 Metadata 中取值并解析布尔值。前端项目配置页同样以enable_content_trust/enable_content_trust_cosign读写该开关见 project-policy-config.component.ts。8.2 拉取请求上的 ContentTrust 中间件强制校验的核心实现在 src/server/middleware/contenttrust/contentrust.go 的ContentTrust()中间件中。它的执行流程是从请求上下文取出制品信息lib.ArtifactInfo若缺失则直接返回 404按项目名取出项目实体若项目启用了 cosign 信任ContentTrustCosignEnabled()调用signatureChecking校验制品是否带有cosign类型签名若项目启用了内容信任ContentTrustEnabled()校验制品是否带有notation类型签名任一校验失败返回PROJECTPOLICYVIOLATION错误并携带明确提示信息如The image is not signed by cosign./The image is not signed by notation.。signatureChecking的判定逻辑contentrust.go非常直观通过artifact.Ctl.GetByReference获取制品携带 Accessories遍历其附件列表只要存在与目标签名类型一致的附件即判定为已签名若制品没有任何附件或附件类型不匹配则判定为违反项目策略。值得注意的是校验前会调用util.SkipPolicyChecking做白名单放行例如扫描器拉取、cosign 客户端自身拉取签名等场景避免误伤合法请求。8.3 中间件在注册表路由上的挂载点该中间件被挂载到 OCI 分发 API 的 manifest 读取路径上见 src/server/registry/route.goGET /v2/*/manifests/:reference与HEAD /v2/*/manifests/:reference两条路由都会经过contenttrust.ContentTrust()。这从路由层面印证了第 7 节的结论内容信任策略拦截的是 manifest 的拉取GET/HEAD请求推送PUT路径不受此策略限制——因此用例 9-30 中未签名镜像能推不能拉。8.4 单测对行为的印证contentrust_test.go 通过 mock 了 project/artifact/accessory 三类控制器覆盖了中间件的关键分支与用例期望完全吻合项目未启用信任时拉取返回200 OKTestContentTrustDisabled启用 cosign 信任但制品无签名附件时认证用户拉取返回412 Precondition FailedTestAuthenticatedUserPulling制品带有 cosign 签名附件时放行返回200 OKTestCosignSignaturePulling制品带有 notation 签名附件且启用enable_content_trust时放行TestNotationSignaturePulling两类信任同时启用且两种签名附件齐全时放行TestBothSignaturePulling。这些测试用例直接对应 9-30 用例中未签名不可拉、签名可拉的两种结局形成了黑盒行为测试 → 白盒单元测试 → 源码实现的完整证据链。9. 版本演进提示与适用前提需要特别说明的是本仓库当前版本见 VERSION与用例文档写作时存在演进Notary 已弃用make/install.sh明确提示不要设置--with-notary因为 Notary 已被废弃并移除make/photon/prepare/migrations中的harbor.yml.jinja也仅以注释形式保留notary_server/notary_signer等历史配置片段签名体系已切换当前仓库的签名校验以cosign与notation两类签名附件Accessory为核心accessory/modelcontenttrust中间件对两种签名分别校验。因此本文中关于DOCKER_CONTENT_TRUST_SERVER4443 端口与 Notary 的内容属于用例历史语义在现行版本中做实验时更贴近当前架构的做法是使用 cosign / notation 工具为镜像签名仓库 icons 目录中的 cosign.png 与 notation.png 图标也表明这两者已成为 Harbor 支持的签名体系在项目配置页开启对应的内容信任开关复用 9-01/9-30 的验证思路签名镜像在 UI 显示绿色对勾、未签名镜像显示红色叉、启用项目级策略后未签名镜像无法拉取。10. 小结与排障要点以用例 9-01 为核心本文串起了 Harbor 内容信任的完整验证链路。作为快速排障清单请重点检查证书未就绪自签名环境下务必同时配置/etc/docker/certs.d/harbor_ip/与$HOME/.docker/tls/harbor_ip:4443/否则签名服务握手失败环境变量作用域DOCKER_CONTENT_TRUST1与DOCKER_CONTENT_TRUST_SERVER需在同一 shell 会话中生效且export要在docker push之前执行项目级策略的副作用开启内容信任后所有未签名镜像含历史推送的都将无法拉取需先完成签名再启用策略这正是 9-30 先推未签名、再推签名、最后开策略的编排原因签名状态口径UI 绿勾基于制品附件实时计算若使用旧版本签名工具或绕过签名直接推送UI 将如实显示未签名且无法通过项目级策略的拉取校验。相关仓库资源便于进一步深挖测试用例目录、ContentTrust 中间件、注册表路由注册、项目元数据定义、项目配置前端实现、制品签名列前端实现。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Harbor 内容信任（Content Trust）实战：在 DB 模式下推送签名镜像的测试与原理剖析
Harbor 内容信任Content Trust实战在 DB 模式下推送签名镜像的测试与原理剖析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor本文以 Harbor 仓库 tests/testcases/Group9-Content-trust/9-01-DB-user-push-signed-images.md 这一官方测试用例为骨架完整还原在 DB 认证模式下普通用户开启 Docker Content Trust 并推送签名镜像的验证流程并结合仓库源码剖析签名状态在 UI 中如何呈现、项目级内容信任策略如何在拉取链路中被强制执行。读完本文你将能够复现签名/未签名镜像的推送验证理解DOCKER_CONTENT_TRUST系列环境变量、Notary/签名服务端点配置方式以及 Harbor 底层基于 cosign/notation 签名附件Accessory的信任校验机制。1. 用例背景与测试目标内容信任Content Trust用于确保从仓库拉取的镜像确实是发布者构建并签名过的内容防止镜像被篡改或在传输过程中被替换。在 Harbor 中这一能力通过接入 Docker Content Trust 体系实现Docker 客户端在开启信任后推送镜像时会先对镜像进行签名再将镜像与签名一并推送到 Harbor。测试用例 9-01 属于 Group9-Content-trust 测试组目标非常明确验证在 DB本地数据库认证模式下普通用户可以开启内容信任并成功推送签名镜像同时验证签名结果能够在 Harbor UI 上被直观标识出来绿色对勾。仓库中同一测试组还包含 LDAP 模式9-11-LDAP-user-push-signed-images.md与管理员模式9-21-admin-push-signed-images.md的等价用例三者的核心步骤完全一致区别仅在于认证体系与用户身份印证了该流程在不同认证模式下的通用性。2. 测试环境要求环境项要求Harbor 实例一台正在运行且可访问的 Harbor 实例DB 认证模式客户端一台装有 Docker CLIDocker 客户端的 Linux 主机3. 测试前置证书与信任端点说明用例原文给出了两条关键前置说明直接影响命令能否执行成功文中的harbor_ip需要替换为 Harbor 的实际 IP 或 FQDN如果使用自签名证书必须把 CA 根证书复制到以下两个位置/etc/docker/certs.d/harbor_ip/Docker 客户端验证 Harbor 镜像仓库 TLS 证书的可信根目录$HOME/.docker/tls/harbor_ip:4443/Docker Content Trust 客户端Notary 客户端验证签名服务端证书的可信根目录其中4443是签名服务Notary Server的默认 HTTPS 端口。注意本仓库当前版本已将 Notary 从安装链路中移除见 make/install.sh 中的提示notary has been deprecated and removed。该端口配置源自用例编写时的 Notary 时代在后续源码剖析小节中你会看到当前 Harbor 的信任校验已演进为基于 cosign/notation 签名附件实现但从 Docker 客户端视角看开启 Content Trust 并推送签名镜像的交互流程与验证语义依然保持一致。4. 测试步骤推送签名镜像DB 模式步骤 1登录 UI 并创建项目通过浏览器登录 Harbor Web 界面创建一个新项目下文以project_name指代。项目创建后即获得一个独立的命名空间用于存放镜像。步骤 2在 Docker 客户端启用内容信任并登录在 Linux Docker 客户端上执行export DOCKER_CONTENT_TRUST1 export DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443参数说明环境变量作用DOCKER_CONTENT_TRUST1开启 Docker 客户端的 Content Trust 功能此后所有push/pull操作都会附带签名行为DOCKER_CONTENT_TRUST_SERVER指定签名服务端点Notary Server 地址Docker 会将签名上传到该服务随后登录 Harbordocker login harbor_ip输入具有该项目推送权限的用户名与密码完成认证。步骤 3推送镜像将镜像推送到步骤 1 创建的项目docker tag local_image harbor_ip/project_name/image_name:tag docker push harbor_ip/project_name/image_name:tag在DOCKER_CONTENT_TRUST1生效的情况下Docker 客户端会在推送前自动对镜像进行签名首次推送会引导你设置签名密钥的密码短语随后生成根密钥与仓库密钥并将签名上传到DOCKER_CONTENT_TRUST_SERVER指定的签名服务。5. 期望结果签名镜像的 UI 标识用例的 Expected Outcome 只有一条但信息量很大步骤 3 中Docker 客户端会完成签名与推送UI 上会显示一个绿色对勾green tick。这个绿色对勾来自 Harbor Portal 的制品Artifact列表页面。从仓库前端源码可以看到签名列co-signed-column会根据制品签名状态渲染不同图标artifact-list-tab.component.html 中按artifact.signed状态分支显示true渲染signed图标绿色对勾、false渲染未签名标识红色叉、checking显示检测中的状态artifact-list-tab.component.ts 中签名的判定逻辑是通过查询制品的Accessories附件判断是否存在 cosign / notation 类型的签名附件进而设置signed状态。也就是说UI 上的绿勾/红叉并非简单由推送方式推断而是后端根据制品实际携带的签名附件实时计算得出的这正是签名状态可信的底层原因。6. 对照实验未签名镜像显示红色叉为验证 UI 能够区分签名与未签名镜像同一测试组提供了对照组用例 9-02-DB-user-push-unsigned-images.md登录 UI 并创建项目在 Docker 客户端不设置DOCKER_CONTENT_TRUST即保持未开启状态或执行unset DOCKER_CONTENT_TRUST登录 Harbor向项目推送一个镜像。期望结果该镜像在 UI 的签名列下会显示红色叉red cross。这一正反对照表明Harbor 能够通过制品的签名附件实时标识其签名状态为项目级信任策略的可视化决策提供依据。7. 进阶项目级内容信任策略9-30仅显示状态还不够Harbor 还支持在项目维度强制内容信任。用例 9-30-Project-level-content-trust.md 验证了该策略登录 UI 创建项目先向项目推送一个未签名镜像在 Docker 客户端设置DOCKER_CONTENT_TRUST1与DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443登录后再推送一个签名镜像在项目配置页面启用项目级内容信任对应 UI 中的 Content Trust 开关分别拉取第 2 步未签名与第 4 步签名推送的镜像。期望结果拉取未签名镜像失败策略拒绝拉取签名镜像成功。这说明项目级内容信任策略作用于拉取pull链路一旦启用未签名制品将无法被拉取从而在消费侧强制保证镜像来源可信。8. 源码剖析内容信任如何被强制执行理解了 UI 表现与项目级策略后再看 Harbor 后端如何落地这一机制。8.1 项目元数据中的信任开关项目级内容信任由两个元数据键控制定义于 src/pkg/project/models/pro_meta.go元数据键含义enable_content_trust启用内容信任要求制品存在 notation 类型签名enable_content_trust_cosign启用 cosign 内容信任要求制品存在 cosign 类型签名对应读取逻辑在 src/pkg/project/models/project.go 的ContentTrustEnabled()与ContentTrustCosignEnabled()中实现——从项目 Metadata 中取值并解析布尔值。前端项目配置页同样以enable_content_trust/enable_content_trust_cosign读写该开关见 project-policy-config.component.ts。8.2 拉取请求上的 ContentTrust 中间件强制校验的核心实现在 src/server/middleware/contenttrust/contentrust.go 的ContentTrust()中间件中。它的执行流程是从请求上下文取出制品信息lib.ArtifactInfo若缺失则直接返回 404按项目名取出项目实体若项目启用了 cosign 信任ContentTrustCosignEnabled()调用signatureChecking校验制品是否带有cosign类型签名若项目启用了内容信任ContentTrustEnabled()校验制品是否带有notation类型签名任一校验失败返回PROJECTPOLICYVIOLATION错误并携带明确提示信息如The image is not signed by cosign./The image is not signed by notation.。signatureChecking的判定逻辑contentrust.go非常直观通过artifact.Ctl.GetByReference获取制品携带 Accessories遍历其附件列表只要存在与目标签名类型一致的附件即判定为已签名若制品没有任何附件或附件类型不匹配则判定为违反项目策略。值得注意的是校验前会调用util.SkipPolicyChecking做白名单放行例如扫描器拉取、cosign 客户端自身拉取签名等场景避免误伤合法请求。8.3 中间件在注册表路由上的挂载点该中间件被挂载到 OCI 分发 API 的 manifest 读取路径上见 src/server/registry/route.goGET /v2/*/manifests/:reference与HEAD /v2/*/manifests/:reference两条路由都会经过contenttrust.ContentTrust()。这从路由层面印证了第 7 节的结论内容信任策略拦截的是 manifest 的拉取GET/HEAD请求推送PUT路径不受此策略限制——因此用例 9-30 中未签名镜像能推不能拉。8.4 单测对行为的印证contentrust_test.go 通过 mock 了 project/artifact/accessory 三类控制器覆盖了中间件的关键分支与用例期望完全吻合项目未启用信任时拉取返回200 OKTestContentTrustDisabled启用 cosign 信任但制品无签名附件时认证用户拉取返回412 Precondition FailedTestAuthenticatedUserPulling制品带有 cosign 签名附件时放行返回200 OKTestCosignSignaturePulling制品带有 notation 签名附件且启用enable_content_trust时放行TestNotationSignaturePulling两类信任同时启用且两种签名附件齐全时放行TestBothSignaturePulling。这些测试用例直接对应 9-30 用例中未签名不可拉、签名可拉的两种结局形成了黑盒行为测试 → 白盒单元测试 → 源码实现的完整证据链。9. 版本演进提示与适用前提需要特别说明的是本仓库当前版本见 VERSION与用例文档写作时存在演进Notary 已弃用make/install.sh明确提示不要设置--with-notary因为 Notary 已被废弃并移除make/photon/prepare/migrations中的harbor.yml.jinja也仅以注释形式保留notary_server/notary_signer等历史配置片段签名体系已切换当前仓库的签名校验以cosign与notation两类签名附件Accessory为核心accessory/modelcontenttrust中间件对两种签名分别校验。因此本文中关于DOCKER_CONTENT_TRUST_SERVER4443 端口与 Notary 的内容属于用例历史语义在现行版本中做实验时更贴近当前架构的做法是使用 cosign / notation 工具为镜像签名仓库 icons 目录中的 cosign.png 与 notation.png 图标也表明这两者已成为 Harbor 支持的签名体系在项目配置页开启对应的内容信任开关复用 9-01/9-30 的验证思路签名镜像在 UI 显示绿色对勾、未签名镜像显示红色叉、启用项目级策略后未签名镜像无法拉取。10. 小结与排障要点以用例 9-01 为核心本文串起了 Harbor 内容信任的完整验证链路。作为快速排障清单请重点检查证书未就绪自签名环境下务必同时配置/etc/docker/certs.d/harbor_ip/与$HOME/.docker/tls/harbor_ip:4443/否则签名服务握手失败环境变量作用域DOCKER_CONTENT_TRUST1与DOCKER_CONTENT_TRUST_SERVER需在同一 shell 会话中生效且export要在docker push之前执行项目级策略的副作用开启内容信任后所有未签名镜像含历史推送的都将无法拉取需先完成签名再启用策略这正是 9-30 先推未签名、再推签名、最后开策略的编排原因签名状态口径UI 绿勾基于制品附件实时计算若使用旧版本签名工具或绕过签名直接推送UI 将如实显示未签名且无法通过项目级策略的拉取校验。相关仓库资源便于进一步深挖测试用例目录、ContentTrust 中间件、注册表路由注册、项目元数据定义、项目配置前端实现、制品签名列前端实现。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考