文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文面向 Knative 集群管理员与安全运维人员讲解如何利用 cosign 校验 Knative 官方发布的容器镜像既能验证构建过程的 SLSASupply-chain Levels for Software Artifacts软件工件供应链级别证明也能提取每个镜像的 SBOM软件物料清单从而在安装 Knative Serving、Eventing 等组件前确认镜像的真实性与来源可信度。读完本文你将掌握两条核心命令链——cosign verify-attestation验证构建声明、cosign download sbom拉取架构级物料清单并能将同样的校验逻辑接入 sigstore policy controller 等准入控制器形成自动化供应链安全防线。背景Knative 发布物中的安全元数据Knative 为每个随版本发布的容器镜像同时公开两类供应链安全元数据SLSA 构建证明SLSA provenance采用 in-toto 规范描述的 attestation 文档记录镜像的构建过程、构建环境与来源信息用于回答这个镜像是不是 Knative 官方构建的、以及它是如何构建的。SBOM软件物料清单列出镜像内部包含的每一个软件组件及其版本用于回答这个镜像里到底装了哪些软件。这两类数据在 Knative 构建流程中自动生成并作为 attestation 存储在容器镜像仓库中任何拥有 cosign 工具的人都可以独立读取和验证不依赖对发布页面的信任。其背后的供应链安全定位在 威胁模型文档 中有明确说明对容器镜像与命令行二进制进行签名并附带 SBOM 与 SLSA 证明是为了降低供应链攻击风险让管理员与用户能够确认自己拿到的工件与 Knative 官方构建的一致并验证 SLSA 关于临时构建与可复现构建的安全保证。Knative 的knCLI 客户端二进制同样采用 cosign 签名验证方式记录在 验证客户端二进制文档其使用的签名身份与镜像验证完全一致可作为交叉印证。前置条件验证镜像前需要准备两样东西cosign 工具cosign 是 sigstore 项目提供的容器签名/验证 CLI负责从容器仓库拉取并解析 attestation。安装方式请参考 sigstore 官方文档cosign install或各发行版包管理器。目标镜像引用$IMAGEKnative 发布清单 YAML 中列出的镜像地址例如gcr.io/knative-releases/knative.dev/serving/cmd/controller这类带 tag 的引用。Knative 的签名模式与验证身份KEYLESS无密钥签名模式Knative 的镜像与二进制均采用KEYLESS 签名模式keyless signing不预先管理长期私钥而是在构建/签名时由 CI 流水线向 sigstore 的 Fulcio 证书机构申请短期证书完成签名证书与签名一并写入仓库。验证方无需持有公钥只需校验Subject签名身份signerknative-releases.iam.gserviceaccount.comIssuer证书签发者https://accounts.google.com从发布脚本印证签名身份签名身份在仓库的发布脚本 vendor/knative.dev/hack/release.sh 中被硬编码为两个常量RELEASE_SIGNING_IDENTITYsignerknative-releases.iam.gserviceaccount.com——正式版本签名身份即本文所有命令中使用的 SubjectNIGHTLY_SIGNING_IDENTITYsignerknative-nightly.iam.gserviceaccount.com——每晚构建nightly的签名身份验证 nightly 镜像时应改用该邮箱。在sign_release()函数中release.shCI 通过gcloud auth print-identity-token --audiencessigstore模拟上述服务账号取得短期身份令牌然后执行cosign sign签名镜像与cosign attest附加 SLSA 证明。这意味着凡是你验证通过的镜像其签名链最终都指向 Knative 官方维护的 Google 服务账号而不是某个个人密钥。验证 SLSA 构建证明signed provenance单条验证命令针对发布清单中给定的任一镜像用以下命令验证其构建 attestationcosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE参数说明参数含义--certificate-oidc-issuer校验签名证书的 OIDC 签发者Knative 固定为https://accounts.google.com--certificate-identity校验签名主体SubjectKnative 正式版固定为signerknative-releases.iam.gserviceaccount.com--typeattestation 的 predicate 类型Knative 生成的为 SLSA v0.2 规范即slsaprovenance02$IMAGE要验证的镜像引用当证书链有效、身份与 issuer 匹配、且 attestation 与镜像摘要digest一致时命令返回成功否则会报出证书不匹配或无法提取证明等错误。注意命令会输出全部 attestation你需要逐一确认每一条都满足预期身份条件因为同一镜像可能附带多个签名。用 jq 解码 in-toto 文档attestation 中的 in-toto 文档以 Base64 编码存放在.payload字段中配合jq可以解码出可读的 JSON 构建声明cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq这一连串管道完成了验证签名 → 提取 payload → Base64 解码 → 格式化输出四步。解码后你将看到 in-toto 声明中的builder、buildType、recipe、materials等字段它们描述了镜像由哪个构建系统、在什么环境下、引用了哪些上游源码与依赖构建而成——这正是 SLSA 证明的核心信息可用于审计构建可复现性。验证的工程化落地接入准入控制器验证命令本身可用于手工审计但更常见的生产场景是自动强制校验将 Knative 公开的这些 attestation 信息配置进sigstore policy controller或其他准入控制器admission controller使得集群在拉取/创建 Pod 时自动检查镜像签名与证明不满足策略的镜像直接拒绝部署。这与文档 security-prereqs-images 片段 描述的用法一致——当集群被配置为在 Pod 执行期间校验镜像签名时你就需要本页的镜像验证信息来配置策略。若需在安装前先人工核对镜像来源也可参考 security-prereqs-images 片段 的提示在安装 Knative 前可选地对镜像执行验证再从发布清单进行部署。下载与解析 Knative SBOMSBOM 的生成方式Knative 的每个容器镜像都会发布与之对应的 SBOM且这些 SBOM 是在编译期由ko工具 生成并写入仓库的。因此 SBOM 精确反映了该次构建实际链接进来的软件组件而不是一份静态的预期清单。下载命令使用 cosign 的download sbom子命令即可拉取cosign download sbom $IMAGE多架构镜像的架构级提取Knative 发布清单 YAML 中的镜像引用是多架构multi-arch镜像manifest list。由于不同架构在构建时可能链接不同的底层库SBOM 内容会因架构而异要精确获取某个架构例如linux/amd64的软件组件必须针对架构专属镜像执行下载cosign download sbom $IMAGE-linux-amd64 # 示例带架构后缀的镜像引用实际操作中架构专属镜像的引用形式取决于仓库的命名约定常见为镜像 digest 或带-linux-amd64后缀的 tag你可以先用docker buildx imagetools inspect $IMAGE或crane manifest查看 manifest list 中各个平台对应的 digest再对目标 digest 执行cosign download sbom。拿到 SBOM 后可结合企业漏洞扫描如 Trivy、Grype与 CVE 库比对确认镜像组件版本是否在受影响的范围内。验证完整流程示例端到端将以上环节串起来一次完整的镜像供应链校验流程为# 1. 验证镜像的 SLSA 构建证明 cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE # 2. 解码并审阅构建声明的 payload cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq # 3. 按需下载对应架构的 SBOM 进行成分审计 cosign download sbom $IMAGE三步分别回答三个问题镜像是否由 Knative 官方身份签名构建过程声明了什么镜像由哪些软件组件构成三者叠加即构成来源可信 构建可审计 成分可盘点的完整镜像信任链。补充资料Knative 安全与漏洞披露总览安全团队、漏洞报告渠道与威胁模型入口Knative 威胁模型SLSA 构建与 provenance 缓解的供应链攻击场景system code execution验证客户端二进制与镜像验证同源的 cosign KEYLESS 签名身份可用于校验kn等 CLI 二进制2023 年安全审计博客记录 Knative 自建 provenance-generator 生成 SLSA 兼容证明并纳入发布流程的背景。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐验证 Knative kn CLI 二进制使用 cosign 与 SHA256 校验官方发行物验证 Knative kn CLI 二进制使用 cosign 与 SHA256 校验官方发行物 从 Knative 1.9 版本开始官方使用 cosign文档教程云原生LinuxKit SBoM 软件物料清单构建期生成、合并与 050_sbom 测试验证全解析LinuxKit SBoM 软件物料清单构建期生成、合并与 050_sbom 测试验证全解析 LinuxKit 将若干 OCI 镜像组合为最小化、面向容器场景操作系统云原生容器运行时Beekeeper Studio 配置文件位置速查3 平台路径、3 层优先级一次讲清Beekeeper Studio 配置文件位置速查3 平台路径、3 层优先级一次讲清 改了配置、反复重启Beekeeper Studio 就是没有反应——十桌面应用数据库客户端开发工具上一篇Hermes Agent 配置全解从 3 条命令到多场景定制下一篇智慧教育平台电子课本下载终极指南3步快速获取PDF教材创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Knative 镜像验证指南：使用 cosign 校验 SLSA 构建证明与 SBOM 物料清单
文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载本文面向 Knative 集群管理员与安全运维人员讲解如何利用 cosign 校验 Knative 官方发布的容器镜像既能验证构建过程的 SLSASupply-chain Levels for Software Artifacts软件工件供应链级别证明也能提取每个镜像的 SBOM软件物料清单从而在安装 Knative Serving、Eventing 等组件前确认镜像的真实性与来源可信度。读完本文你将掌握两条核心命令链——cosign verify-attestation验证构建声明、cosign download sbom拉取架构级物料清单并能将同样的校验逻辑接入 sigstore policy controller 等准入控制器形成自动化供应链安全防线。背景Knative 发布物中的安全元数据Knative 为每个随版本发布的容器镜像同时公开两类供应链安全元数据SLSA 构建证明SLSA provenance采用 in-toto 规范描述的 attestation 文档记录镜像的构建过程、构建环境与来源信息用于回答这个镜像是不是 Knative 官方构建的、以及它是如何构建的。SBOM软件物料清单列出镜像内部包含的每一个软件组件及其版本用于回答这个镜像里到底装了哪些软件。这两类数据在 Knative 构建流程中自动生成并作为 attestation 存储在容器镜像仓库中任何拥有 cosign 工具的人都可以独立读取和验证不依赖对发布页面的信任。其背后的供应链安全定位在 威胁模型文档 中有明确说明对容器镜像与命令行二进制进行签名并附带 SBOM 与 SLSA 证明是为了降低供应链攻击风险让管理员与用户能够确认自己拿到的工件与 Knative 官方构建的一致并验证 SLSA 关于临时构建与可复现构建的安全保证。Knative 的knCLI 客户端二进制同样采用 cosign 签名验证方式记录在 验证客户端二进制文档其使用的签名身份与镜像验证完全一致可作为交叉印证。前置条件验证镜像前需要准备两样东西cosign 工具cosign 是 sigstore 项目提供的容器签名/验证 CLI负责从容器仓库拉取并解析 attestation。安装方式请参考 sigstore 官方文档cosign install或各发行版包管理器。目标镜像引用$IMAGEKnative 发布清单 YAML 中列出的镜像地址例如gcr.io/knative-releases/knative.dev/serving/cmd/controller这类带 tag 的引用。Knative 的签名模式与验证身份KEYLESS无密钥签名模式Knative 的镜像与二进制均采用KEYLESS 签名模式keyless signing不预先管理长期私钥而是在构建/签名时由 CI 流水线向 sigstore 的 Fulcio 证书机构申请短期证书完成签名证书与签名一并写入仓库。验证方无需持有公钥只需校验Subject签名身份signerknative-releases.iam.gserviceaccount.comIssuer证书签发者https://accounts.google.com从发布脚本印证签名身份签名身份在仓库的发布脚本 vendor/knative.dev/hack/release.sh 中被硬编码为两个常量RELEASE_SIGNING_IDENTITYsignerknative-releases.iam.gserviceaccount.com——正式版本签名身份即本文所有命令中使用的 SubjectNIGHTLY_SIGNING_IDENTITYsignerknative-nightly.iam.gserviceaccount.com——每晚构建nightly的签名身份验证 nightly 镜像时应改用该邮箱。在sign_release()函数中release.shCI 通过gcloud auth print-identity-token --audiencessigstore模拟上述服务账号取得短期身份令牌然后执行cosign sign签名镜像与cosign attest附加 SLSA 证明。这意味着凡是你验证通过的镜像其签名链最终都指向 Knative 官方维护的 Google 服务账号而不是某个个人密钥。验证 SLSA 构建证明signed provenance单条验证命令针对发布清单中给定的任一镜像用以下命令验证其构建 attestationcosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE参数说明参数含义--certificate-oidc-issuer校验签名证书的 OIDC 签发者Knative 固定为https://accounts.google.com--certificate-identity校验签名主体SubjectKnative 正式版固定为signerknative-releases.iam.gserviceaccount.com--typeattestation 的 predicate 类型Knative 生成的为 SLSA v0.2 规范即slsaprovenance02$IMAGE要验证的镜像引用当证书链有效、身份与 issuer 匹配、且 attestation 与镜像摘要digest一致时命令返回成功否则会报出证书不匹配或无法提取证明等错误。注意命令会输出全部 attestation你需要逐一确认每一条都满足预期身份条件因为同一镜像可能附带多个签名。用 jq 解码 in-toto 文档attestation 中的 in-toto 文档以 Base64 编码存放在.payload字段中配合jq可以解码出可读的 JSON 构建声明cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq这一连串管道完成了验证签名 → 提取 payload → Base64 解码 → 格式化输出四步。解码后你将看到 in-toto 声明中的builder、buildType、recipe、materials等字段它们描述了镜像由哪个构建系统、在什么环境下、引用了哪些上游源码与依赖构建而成——这正是 SLSA 证明的核心信息可用于审计构建可复现性。验证的工程化落地接入准入控制器验证命令本身可用于手工审计但更常见的生产场景是自动强制校验将 Knative 公开的这些 attestation 信息配置进sigstore policy controller或其他准入控制器admission controller使得集群在拉取/创建 Pod 时自动检查镜像签名与证明不满足策略的镜像直接拒绝部署。这与文档 security-prereqs-images 片段 描述的用法一致——当集群被配置为在 Pod 执行期间校验镜像签名时你就需要本页的镜像验证信息来配置策略。若需在安装前先人工核对镜像来源也可参考 security-prereqs-images 片段 的提示在安装 Knative 前可选地对镜像执行验证再从发布清单进行部署。下载与解析 Knative SBOMSBOM 的生成方式Knative 的每个容器镜像都会发布与之对应的 SBOM且这些 SBOM 是在编译期由ko工具 生成并写入仓库的。因此 SBOM 精确反映了该次构建实际链接进来的软件组件而不是一份静态的预期清单。下载命令使用 cosign 的download sbom子命令即可拉取cosign download sbom $IMAGE多架构镜像的架构级提取Knative 发布清单 YAML 中的镜像引用是多架构multi-arch镜像manifest list。由于不同架构在构建时可能链接不同的底层库SBOM 内容会因架构而异要精确获取某个架构例如linux/amd64的软件组件必须针对架构专属镜像执行下载cosign download sbom $IMAGE-linux-amd64 # 示例带架构后缀的镜像引用实际操作中架构专属镜像的引用形式取决于仓库的命名约定常见为镜像 digest 或带-linux-amd64后缀的 tag你可以先用docker buildx imagetools inspect $IMAGE或crane manifest查看 manifest list 中各个平台对应的 digest再对目标 digest 执行cosign download sbom。拿到 SBOM 后可结合企业漏洞扫描如 Trivy、Grype与 CVE 库比对确认镜像组件版本是否在受影响的范围内。验证完整流程示例端到端将以上环节串起来一次完整的镜像供应链校验流程为# 1. 验证镜像的 SLSA 构建证明 cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE # 2. 解码并审阅构建声明的 payload cosign verify-attestation \ --certificate-oidc-issuer https://accounts.google.com \ --certificate-identity signerknative-releases.iam.gserviceaccount.com \ --type slsaprovenance02 \ $IMAGE | jq -r .payload | base64 --decode | jq # 3. 按需下载对应架构的 SBOM 进行成分审计 cosign download sbom $IMAGE三步分别回答三个问题镜像是否由 Knative 官方身份签名构建过程声明了什么镜像由哪些软件组件构成三者叠加即构成来源可信 构建可审计 成分可盘点的完整镜像信任链。补充资料Knative 安全与漏洞披露总览安全团队、漏洞报告渠道与威胁模型入口Knative 威胁模型SLSA 构建与 provenance 缓解的供应链攻击场景system code execution验证客户端二进制与镜像验证同源的 cosign KEYLESS 签名身份可用于校验kn等 CLI 二进制2023 年安全审计博客记录 Knative 自建 provenance-generator 生成 SLSA 兼容证明并纳入发布流程的背景。赞分享文档教程云原生【免费下载链接】docsUser documentation for Knative components.项目地址https://gitcode.com/gh_mirrors/docs1/docs点击查看免费下载相关推荐验证 Knative kn CLI 二进制使用 cosign 与 SHA256 校验官方发行物验证 Knative kn CLI 二进制使用 cosign 与 SHA256 校验官方发行物 从 Knative 1.9 版本开始官方使用 cosign文档教程云原生LinuxKit SBoM 软件物料清单构建期生成、合并与 050_sbom 测试验证全解析LinuxKit SBoM 软件物料清单构建期生成、合并与 050_sbom 测试验证全解析 LinuxKit 将若干 OCI 镜像组合为最小化、面向容器场景操作系统云原生容器运行时Beekeeper Studio 配置文件位置速查3 平台路径、3 层优先级一次讲清Beekeeper Studio 配置文件位置速查3 平台路径、3 层优先级一次讲清 改了配置、反复重启Beekeeper Studio 就是没有反应——十桌面应用数据库客户端开发工具上一篇Hermes Agent 配置全解从 3 条命令到多场景定制下一篇智慧教育平台电子课本下载终极指南3步快速获取PDF教材创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考