Harbor 中删除已签名镜像的完整验证指南基于 Docker Content Trust 与 Notary 的 9-05 测试用例深度解析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harborHarbor 作为支持内容信任Content Trust的开源云原生镜像仓库其已签名镜像不可被轻易删除的安全设计是众多运维同学必须理解的关键机制。本文以 Harbor 官方测试用例9-05 User delete signed images (DB mode)为骨架完整还原推送签名镜像 → 删除被拒 → 清理 Notary 签名标签 → 再次删除成功的全流程并结合仓库源码揭示其底层原理帮助你掌握在启用 Docker Content Trust 的 Harbor 环境中管理签名镜像的实战技能。测试用例定位与核心目标本测试用例位于 tests/testcases/Group9-Content-trust/9-05-DB-user-delete-signed-images.md属于 Harbor 测试体系中的Group9-Content-trust内容信任专项。其核心目的是验证普通用户是否能够删除已经过签名的镜像Signed Images。与同组的 9-01DB 用户推送签名镜像、9-02DB 用户推送未签名镜像、9-03DB 用户拉取签名镜像、9-04DB 用户拉取未签名镜像等用例共同构成了一套围绕内容信任的完整功能验证矩阵。9-05 关注的不是能不能推或能不能拉而是删除权限与签名状态之间的联动关系——这是很多用户在实际运维中才会踩到的坑。环境要求与准备工作按照用例声明执行本验证至少需要以下环境组件要求Harbor 实例一个运行中且可访问的 Harbor 实例DB 认证模式Docker 客户端一台安装了 Docker CLI 的 Linux 主机内容信任服务Harbor 内置的 Notary 服务对应内容信任功能端口 4443用例中特别强调了一个关键前提如果你使用的是自签名证书必须将 CA 根证书分别拷贝到以下两个位置否则 Docker 客户端与 Harbor/Notary 之间的 TLS 握手会失败/etc/docker/certs.d/harbor_ip$HOME/.docker/tls/harbor_ip:4443/其中harbor_ip应替换为你实际的 Harbor 地址IP 或 FQDN。第二个路径中的4443正是 Harbor 内容信任服务Notary server的默认监听端口Docker Content Trust 客户端需要通过该端口与 Notary 服务通信来完成签名元数据的存储与查询。完整测试步骤详解步骤 1创建项目登录 Harbor Web UI创建一个用于本次验证的项目。建议使用独立的测试项目避免与其他业务镜像混淆。项目创建完成后记下项目名称后续推送镜像时需要用到。步骤 2在 Docker 客户端启用内容信任并登录在 Docker 客户端主机上执行以下两条环境变量导出命令export DOCKER_CONTENT_TRUST1 export DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443DOCKER_CONTENT_TRUST1开启 Docker 的内容信任机制此后docker push/docker pull会自动附加签名流程DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443指定 Notary 服务地址。必须显式设置因为 Docker 默认只会查找https://registry_hostname作为 Notary 端点而 Harbor 的 Notary 服务监听在独立的4443端口上。然后执行docker login harbor_ip登录 Harbor输入用户名与密码完成认证。步骤 3推送一个签名镜像docker tag your-image:tag harbor_ip/project-name/image:tag docker push harbor_ip/project-name/image:tag由于DOCKER_CONTENT_TRUST1已生效本次docker push会触发双重流程将镜像内容推送至 Harbor 的 Registry镜像存储将镜像的签名元数据信任数据推送至 Notary 服务。推送完成后该镜像即成为已签名镜像在 Harbor UI 的项目视图下可以看到该镜像带有签名状态标识。步骤 4尝试删除该镜像预期失败在 Harbor UI 中对该已签名镜像执行删除操作。预期结果删除失败。这是整个用例的核心断言之一——Harbor 会阻止用户直接删除带有签名元数据的镜像。步骤 5删除 Notary 签名标签根据步骤 4 中 UI 给出的提示信息进入内容信任相关界面Notary tag 管理删除该镜像对应的签名标签signed tag / Notary tag。这一操作的本质是从 Notary 服务中清除该 tag 的信任元数据使镜像不再是已签名状态。步骤 6再次删除该镜像预期成功删除签名标签后重新对镜像执行删除操作。预期结果删除成功。此时 Harbor 不再受签名保护机制的约束镜像及其关联的 blob 可以被正常清理。为什么先删签名、后删镜像——底层原理剖析签名保护机制的实现逻辑从用例的预期结果可以清晰推导出 Harbor 的签名保护策略用户请求删除镜像 │ ▼ Harbor 检查该镜像 tag 是否存在于 Notary 信任数据中 │ ┌───┴───┐ │ 是 │ │ 否 ▼ ▼ 拒绝删除 允许删除 需先删签名标签也就是说删除操作与签名状态是强耦合的只要镜像的某个 tag 仍带有 Notary 签名元数据Harbor 就会拒绝删除该镜像只有当签名标签被清除后删除请求才能通过。这一设计保证了签名镜像的完整性——防止用户绕过签名直接删掉镜像从而破坏供应链的可追溯性。镜像、签名与信任数据的分工理解这一机制需要区分三个层次的数据镜像内容Image Manifest存储在 Harbor 的 Registry 中即镜像本身的层与配置签名元数据Trust Data存储在 Notary 服务中记录了哪个 tag 由哪个密钥签名的信任链信息签名标签Notary TagNotary 信任库中的条目是镜像 tag 与签名元数据之间的映射。从源码中也能印证 Harbor 对内容信任相关资源的建模在 src/pkg/token/claims/v2/claims.go 中注释明确指出 Harbor 签发的 JWT token 中的 claims 是为registry/notary 资源服务的说明 Registry 与 Notary 在 Harbor 的权限与令牌体系中是并列的两类受保护资源。与普通镜像删除的差异对比同组的 9-02推送未签名镜像用例可以推断未签名镜像DOCKER_CONTENT_TRUST未开启时推送的镜像不产生 Notary 信任数据因此删除时不会触发签名保护可以直接删除。9-05 所验证的正是签名镜像相对普通镜像在删除流程上的额外门槛。版本演进说明Notary 在 Harbor 中的现状需要特别说明的是Notary 功能在当前仓库版本中已被弃用并移除。证据来自 make/install.shPlease do NOT set --with-notary, as notary has been deprecated and removed.也就是说在当前版本中安装脚本已不再接受--with-notary参数内容信任基于 Notary功能整体下线。因此本文描述的 9-05 用例适用于集成 Notary 的 Harbor 历史版本例如 2.x 早期版本在历史版本中harbor.yml会包含notary相关的配置段。仓库的迁移模板中保留了历史痕迹例如 make/photon/prepare/migrations/version_1_10_0/harbor.yml.jinja 中注释掉的notary_signer/notary_server外部数据库配置以及 version_1_9_0 模板中的完整 notary 数据库配置项可作历史参考如果你仍在使用带 Notary 的旧版本 Harbor请将上述测试流程中的项目级内容信任开关一并纳入验证可参考同目录下 9-30-Project-level-content-trust.md。常见问题与排查建议现象可能原因排查方向推送时签名失败 / Notary 报错DOCKER_CONTENT_TRUST_SERVER未设置或端口错误确认环境变量指向https://harbor_ip:4443TLS 握手失败自签名 CA 未安装到 Docker 信任目录按用例要求将 CA 拷贝到/etc/docker/certs.d/harbor_ip与$HOME/.docker/tls/harbor_ip:4443/步骤 4 删除失败属于预期行为签名保护生效不要强行绕过先执行步骤 5 删除 Notary tagUI 未显示签名状态项目未开启内容信任或镜像推送时 DCT 未生效检查项目级内容信任开关与DOCKER_CONTENT_TRUST环境变量总结通过 9-05 测试用例我们可以完整掌握 Harbor 内容信任机制下签名镜像不可直接删除的安全策略及其正确的操作路径先清理 Notary 签名标签再删除镜像本体。这一机制确保了签名镜像的生命周期始终处于可控状态是 Harbor 供应链安全能力的重要组成部分。同时也要牢记该机制基于已被弃用的 Notary 组件在评估当前或未来版本 Harbor 的安全能力时应关注其替代方案如基于 OCI 规范的 Cosign、Notation 等签名体系相关图标可参考 icons 目录的演进。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Harbor 中删除已签名镜像的完整验证指南：基于 Docker Content Trust 与 Notary 的 9-05 测试用例深度解析
Harbor 中删除已签名镜像的完整验证指南基于 Docker Content Trust 与 Notary 的 9-05 测试用例深度解析【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harborHarbor 作为支持内容信任Content Trust的开源云原生镜像仓库其已签名镜像不可被轻易删除的安全设计是众多运维同学必须理解的关键机制。本文以 Harbor 官方测试用例9-05 User delete signed images (DB mode)为骨架完整还原推送签名镜像 → 删除被拒 → 清理 Notary 签名标签 → 再次删除成功的全流程并结合仓库源码揭示其底层原理帮助你掌握在启用 Docker Content Trust 的 Harbor 环境中管理签名镜像的实战技能。测试用例定位与核心目标本测试用例位于 tests/testcases/Group9-Content-trust/9-05-DB-user-delete-signed-images.md属于 Harbor 测试体系中的Group9-Content-trust内容信任专项。其核心目的是验证普通用户是否能够删除已经过签名的镜像Signed Images。与同组的 9-01DB 用户推送签名镜像、9-02DB 用户推送未签名镜像、9-03DB 用户拉取签名镜像、9-04DB 用户拉取未签名镜像等用例共同构成了一套围绕内容信任的完整功能验证矩阵。9-05 关注的不是能不能推或能不能拉而是删除权限与签名状态之间的联动关系——这是很多用户在实际运维中才会踩到的坑。环境要求与准备工作按照用例声明执行本验证至少需要以下环境组件要求Harbor 实例一个运行中且可访问的 Harbor 实例DB 认证模式Docker 客户端一台安装了 Docker CLI 的 Linux 主机内容信任服务Harbor 内置的 Notary 服务对应内容信任功能端口 4443用例中特别强调了一个关键前提如果你使用的是自签名证书必须将 CA 根证书分别拷贝到以下两个位置否则 Docker 客户端与 Harbor/Notary 之间的 TLS 握手会失败/etc/docker/certs.d/harbor_ip$HOME/.docker/tls/harbor_ip:4443/其中harbor_ip应替换为你实际的 Harbor 地址IP 或 FQDN。第二个路径中的4443正是 Harbor 内容信任服务Notary server的默认监听端口Docker Content Trust 客户端需要通过该端口与 Notary 服务通信来完成签名元数据的存储与查询。完整测试步骤详解步骤 1创建项目登录 Harbor Web UI创建一个用于本次验证的项目。建议使用独立的测试项目避免与其他业务镜像混淆。项目创建完成后记下项目名称后续推送镜像时需要用到。步骤 2在 Docker 客户端启用内容信任并登录在 Docker 客户端主机上执行以下两条环境变量导出命令export DOCKER_CONTENT_TRUST1 export DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443DOCKER_CONTENT_TRUST1开启 Docker 的内容信任机制此后docker push/docker pull会自动附加签名流程DOCKER_CONTENT_TRUST_SERVERhttps://harbor_ip:4443指定 Notary 服务地址。必须显式设置因为 Docker 默认只会查找https://registry_hostname作为 Notary 端点而 Harbor 的 Notary 服务监听在独立的4443端口上。然后执行docker login harbor_ip登录 Harbor输入用户名与密码完成认证。步骤 3推送一个签名镜像docker tag your-image:tag harbor_ip/project-name/image:tag docker push harbor_ip/project-name/image:tag由于DOCKER_CONTENT_TRUST1已生效本次docker push会触发双重流程将镜像内容推送至 Harbor 的 Registry镜像存储将镜像的签名元数据信任数据推送至 Notary 服务。推送完成后该镜像即成为已签名镜像在 Harbor UI 的项目视图下可以看到该镜像带有签名状态标识。步骤 4尝试删除该镜像预期失败在 Harbor UI 中对该已签名镜像执行删除操作。预期结果删除失败。这是整个用例的核心断言之一——Harbor 会阻止用户直接删除带有签名元数据的镜像。步骤 5删除 Notary 签名标签根据步骤 4 中 UI 给出的提示信息进入内容信任相关界面Notary tag 管理删除该镜像对应的签名标签signed tag / Notary tag。这一操作的本质是从 Notary 服务中清除该 tag 的信任元数据使镜像不再是已签名状态。步骤 6再次删除该镜像预期成功删除签名标签后重新对镜像执行删除操作。预期结果删除成功。此时 Harbor 不再受签名保护机制的约束镜像及其关联的 blob 可以被正常清理。为什么先删签名、后删镜像——底层原理剖析签名保护机制的实现逻辑从用例的预期结果可以清晰推导出 Harbor 的签名保护策略用户请求删除镜像 │ ▼ Harbor 检查该镜像 tag 是否存在于 Notary 信任数据中 │ ┌───┴───┐ │ 是 │ │ 否 ▼ ▼ 拒绝删除 允许删除 需先删签名标签也就是说删除操作与签名状态是强耦合的只要镜像的某个 tag 仍带有 Notary 签名元数据Harbor 就会拒绝删除该镜像只有当签名标签被清除后删除请求才能通过。这一设计保证了签名镜像的完整性——防止用户绕过签名直接删掉镜像从而破坏供应链的可追溯性。镜像、签名与信任数据的分工理解这一机制需要区分三个层次的数据镜像内容Image Manifest存储在 Harbor 的 Registry 中即镜像本身的层与配置签名元数据Trust Data存储在 Notary 服务中记录了哪个 tag 由哪个密钥签名的信任链信息签名标签Notary TagNotary 信任库中的条目是镜像 tag 与签名元数据之间的映射。从源码中也能印证 Harbor 对内容信任相关资源的建模在 src/pkg/token/claims/v2/claims.go 中注释明确指出 Harbor 签发的 JWT token 中的 claims 是为registry/notary 资源服务的说明 Registry 与 Notary 在 Harbor 的权限与令牌体系中是并列的两类受保护资源。与普通镜像删除的差异对比同组的 9-02推送未签名镜像用例可以推断未签名镜像DOCKER_CONTENT_TRUST未开启时推送的镜像不产生 Notary 信任数据因此删除时不会触发签名保护可以直接删除。9-05 所验证的正是签名镜像相对普通镜像在删除流程上的额外门槛。版本演进说明Notary 在 Harbor 中的现状需要特别说明的是Notary 功能在当前仓库版本中已被弃用并移除。证据来自 make/install.shPlease do NOT set --with-notary, as notary has been deprecated and removed.也就是说在当前版本中安装脚本已不再接受--with-notary参数内容信任基于 Notary功能整体下线。因此本文描述的 9-05 用例适用于集成 Notary 的 Harbor 历史版本例如 2.x 早期版本在历史版本中harbor.yml会包含notary相关的配置段。仓库的迁移模板中保留了历史痕迹例如 make/photon/prepare/migrations/version_1_10_0/harbor.yml.jinja 中注释掉的notary_signer/notary_server外部数据库配置以及 version_1_9_0 模板中的完整 notary 数据库配置项可作历史参考如果你仍在使用带 Notary 的旧版本 Harbor请将上述测试流程中的项目级内容信任开关一并纳入验证可参考同目录下 9-30-Project-level-content-trust.md。常见问题与排查建议现象可能原因排查方向推送时签名失败 / Notary 报错DOCKER_CONTENT_TRUST_SERVER未设置或端口错误确认环境变量指向https://harbor_ip:4443TLS 握手失败自签名 CA 未安装到 Docker 信任目录按用例要求将 CA 拷贝到/etc/docker/certs.d/harbor_ip与$HOME/.docker/tls/harbor_ip:4443/步骤 4 删除失败属于预期行为签名保护生效不要强行绕过先执行步骤 5 删除 Notary tagUI 未显示签名状态项目未开启内容信任或镜像推送时 DCT 未生效检查项目级内容信任开关与DOCKER_CONTENT_TRUST环境变量总结通过 9-05 测试用例我们可以完整掌握 Harbor 内容信任机制下签名镜像不可直接删除的安全策略及其正确的操作路径先清理 Notary 签名标签再删除镜像本体。这一机制确保了签名镜像的生命周期始终处于可控状态是 Harbor 供应链安全能力的重要组成部分。同时也要牢记该机制基于已被弃用的 Notary 组件在评估当前或未来版本 Harbor 的安全能力时应关注其替代方案如基于 OCI 规范的 Cosign、Notation 等签名体系相关图标可参考 icons 目录的演进。【免费下载链接】harborAn open source trusted cloud native registry project that stores, signs, and scans content.项目地址: https://gitcode.com/GitHub_Trending/ha/harbor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考