Cosign 容器与二进制制品签名指南：基于 Sigstore 的密钥无感签名与透明日志验证实践-北京尧图网络

Cosign 容器与二进制制品签名指南基于 Sigstore 的密钥无感签名与透明日志验证实践【免费下载链接】cosignCode signing and transparency for containers and binaries项目地址: https://gitcode.com/GitHub_Trending/co/cosign导读cosign 是 sigstore 项目旗下的容器签名工具核心使命是让软件签名成为隐形基础设施invisible infrastructure开发者无需维护复杂密钥体系即可对 OCI 容器镜像乃至任意二进制制品完成签名、存储与验证。本文以 README.md 为骨架结合仓库内签名规范与核心命令源码完整讲解 cosign 的安装、keyless 签名、公钥签名、离线验证、通用制品发布、签名存储机制与设计取舍帮助读者从命令实操深入到存储与密码学原理。项目概览cosign 是什么cosign 定位为 Signing OCI containers (and other artifacts) using Sigstore。它让签名对使用者透明默认签名流程不再要求用户事先持有密钥而是通过 Sigstore 公共设施Fulcio 证书机构 Rekor 透明日志按需签发短期证书完成签名。README 明确列出的核心能力包括Keyless signing默认使用 Sigstore 公共 Fulcio 证书机构和 Rekor 透明日志无需自备密钥硬件与 KMS 签名支持 YubiKey 等硬件令牌与云 KMScosign 生成密钥对使用 cosign 生成的加密私钥/公钥对签名OCI 注册表集成容器签名、验证与存储在 OCI 注册表中完成自带 PKIBring-your-own PKI可接入自有证书体系。从源码结构看cosign 以 Cobra 命令框架组织全部 CLI根命令定义于 cmd/cosign/cli/commands.go主入口位于 cmd/cosign/main.go。main.go 还静态导入了 AWS、Azure、GCP、HashiCorp Vault 四个 KMS 插件包对应 README 中硬件与 KMS 签名的能力声明。CLI 根命令描述即为 A tool for Container Signing, Verification and Storage in an OCI registry与项目自我定位一致。安装方式快速安装README 提供的安装渠道包括Homebrew、Arch、Nix、GitHub Action、Kubernetes官方安装文档说明各平台安装步骤Linux/macOS 二进制从 GitHub release 资产下载对应平台二进制。需要注意cosign 的 GCS 桶发布渠道已于 2023 年 7 月 31 日弃用应优先使用 GitHub release 资产。开发者源码安装要求 Go 1.22仓库 go.mod 声明了模块路径github.com/sigstore/cosign/v3$ git clone https://github.com/sigstore/cosign $ cd cosign $ go install ./cmd/cosign $ $(go env GOPATH)/bin/cosignDocker 镜像内使用通过官方镜像ghcr.io/sigstore/cosign/cosign可将 cosign 静态复制进自定义镜像FROM ghcr.io/sigstore/cosign/cosign:v2.4.1 as cosign-bin # Source: https://github.com/chainguard-images/images/tree/main/images/static FROM cgr.dev/chainguard/static:latest COPY --fromcosign-bin /ko-app/cosign /usr/local/bin/cosign ENTRYPOINT [ cosign ]快速上手keyless 容器签名与验证签名容器镜像并把签名存进注册表keyless 签名只需一条命令默认模式无需--keycosign sign $IMAGE Generating ephemeral keys... Retrieving signed certificate... Note that there may be personally identifiable information associated with this signed artifact. This may include the email address associated with the account with which you authenticate. This information will be used for signing this artifact and will be stored in public transparency logs and cannot be removed later. By typing y, you attest that you grant (or have permission to grant) and agree to have this information stored permanently in transparency logs. Are you sure you would like to continue? [y/N] y Your browser will now be opened to: https://oauth2.sigstore.dev/auth/auth?access_typeonlineclient_idsigstorecode_challengeOrXitVKUZm2lEWHVt1oQWR4HZvn0rSlKhLcltglYxCYcode_challenge_methodS256nonce2KvOWeTFxYfxyzHtssvlIXmY6Jkredirect_urihttp%3A%2F%2Flocalhost%3A57102%2Fauth%2Fcallbackresponse_typecodescopeopenidemailstate2KvOWfbQJ1caqScgjwibzK2qJmb Successfully verified SCT... tlog entry created with index: 12086900 Pushing signature to: $IMAGE必须注意README 反复强调签名时应基于镜像摘要digestsha256:...而非 tag:latest否则可能签名了并非本意的内容。流程原理README 说明源码印证cosign 生成本次会话的临时ephemeral密钥对通过 OIDC 交互用户以邮箱身份登录cosign 从 Fulcio 证书机构申请短期代码签名证书证书 subject 与登录邮箱一致签名与证书写入 Rekor 透明日志输出tlog entry created with index: ...签名对象作为独立 OCI 对象推送到镜像所在注册表。源码侧cosign sign的实际签名流程由 cmd/cosign/cli/sign/sign.go 的SignCmd驱动它先解析 OCI 引用、按需解析附件如 sbom、计算实体 digest然后调用signDigest完成签名。其中 signDigest 依次完成构造 Simple Signing 载荷sigPayload.Cosign→ 获取密钥/证书 → 调用cbundle.SignData生成包含签名、证书与 Rekor 条目的 bundle → 提取 base64 签名与 PEM 证书 → 构造static.NewSignatureOCI 签名对象 → 通过ociremote.WriteSignatures推送到注册表。签名对象最终经mutate.AttachSignatureToEntity附加并发布sign.go。签名过程的隐私提示同样有据可查源码在确认是否上传透明日志前调用signcommon.ConfirmPrivacyStatementsign.go即上面输出中那段 PII 告知与[y/N]确认的出处。验证容器镜像验证时需要显式声明期望的证书主体与签发者cosign verify $IMAGE --certificate-identity$IDENTITY --certificate-oidc-issuer$OIDC_ISSUER--certificate-identity与--certificate-oidc-issuer也可使用正则变体--certificate-identity-regexp与--certificate-oidc-issuer-regexp便于批量匹配例如 GitHub Actions 工作流身份。cosign CLI 还做了历史 flag 归一化将--cert-identity、--cert-oidc-issuer等旧写法自动映射到新 flag见 commands.go。用公钥验证容器镜像如果使用cosign generate-key-pair生成的密钥对签名则可用公钥验证$ cosign verify --key cosign.pub $IMAGE_URI:1h The following checks were performed on these signatures: - The cosign claims were validated - The signatures were verified against the specified public key {Critical:{Identity:{docker-reference:},Image:{Docker-manifest-digest:sha256:87ef60f558bad79beea6425a3b28989f01dd417164150ab3baab98dcbf04def8},Type:cosign container image signature},Optional:null}该命令在找到至少一个匹配公钥的 cosign 格式签名时返回退出码0所有有效载荷以 JSON 打印到 stdout。注意载荷中嵌入了镜像 digest——这正是分离式detached签名确实覆盖了正确镜像的保证机制。离线air-gapped环境验证验证前置条件离线验证依赖签名 bundlebundle 通常作为镜像 manifest 的 annotation 分发规范见 specs/SIGNATURE_SPEC.md只要该 annotation 存在即可完全离线验证。keyless 签名默认总是携带 bundle annotation因此默认cosign sign产物已包含离线验证所需的全部材料。注意绝大多数验证工作流需要周期性从 TUF 仓库获取服务密钥。使用公共 good 实例做离线验证时需预先从生产 TUF 仓库取得 trusted root 文件内容会无通知变更并在离线环境自行维护其更新机制。README 同时标注该章节已过时请结合最新版本文档确认细节。保存镜像到本地文件系统镜像与签名需在本地文件系统可用。先在联网环境执行cosign initialize # This will pull in the latest TUF root cosign save $IMAGE_NAME --dir ./path/to/dircosign initialize拉取最新 TUF 信任根cosign save把镜像连同签名材料落到本地目录。离线验证命令cosign verify \ --certificate-identity $CERT_IDENTITY \ --certificate-oidc-issuer $CERT_OIDC_ISSUER \ --offlinetrue \ --new-bundle-formatfalse \ # for artifacts signed without the new protobuf bundle format --trusted-root ~/.sigstore/root/tuf-repo-cdn.sigstore.dev/targets/trusted_root.json \ # default location of trusted root --local-image ./path/to/dir$CERT_IDENTITY与$CERT_OIDC_ISSUER需填入期望值。若用密钥对签名且公钥材料已在本地cosign verify --key cosign.pub --offline --local-image ./path/to/dir身份型 blob 签名与验证keyless 方案同样适用于任意二进制文件。不带--key使用cosign sign-blob验证时声明期望签名者身份$ cosign sign-blob artifact --bundle artifact.sigstore.json --yes $ cosign verify-blob artifact \ --bundle artifact.sigstore.json \ --certificate-identity https://github.com/ORG/REPO/.github/workflows/release.ymlrefs/heads/main \ --certificate-oidc-issuer https://token.actions.githubusercontent.com这个场景是 CI 流水线签发的典型用法GitHub Actions 的 OIDC token 身份即https://github.com/ORG/REPO/.github/workflows/filerefs/heads/branch签发者为https://token.actions.githubusercontent.com。blob 签名入口为 cmd/cosign/cli/sign/sign_blob.go 的SignBlobCmd它支持从文件或 stdin-读取载荷并边读边计算哈希。故障排查支持的版本范围Cosign 项目积极支持最新 release 以及 v2 系列的最后一个 release遇到问题应首先确认版本是否够新。常见问题与对策验证报failed to verify timestamps: threshold not met for verified log entry integrated timestamps: 0 1说明签名要求 RFC3161 时间戳支持。对策升级到最新 cosign或在 Cosign 2.6.x 使用--use-signed-timestamps验证报no signatures found可能是签名要求 Rekor v2 透明日志支持。对策升级到最新 cosign签名时 HTTP 错误签名依赖多个 Sigstore 在线服务Fulcio、Rekor 等服务故障时重试是可行办法也欢迎针对具体故障提交 issue。其他问题可在仓库提交 issue 或在 sigstore Slack 频道提问。使用 OCI 注册表发布其他制品OCI 注册表不止能存容器镜像还能承载二进制、脚本、配置文件等通用制品并天然与 Sigstore 生态集成。本节全部命令均来自 README 原文。Blob 上传、下载与签名上传$ echo my first artifact artifact $ BLOB_SUM$(shasum -a 256 artifact | cut -d -f 1) echo $BLOB_SUM c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626 $ BLOB_NAMEmy-artifact-$(uuidgen | head -c 8 | tr A-Z a-z) $ BLOB_URIttl.sh/$BLOB_NAME:1h $ BLOB_URI_DIGEST$(cosign upload blob -f artifact $BLOB_URI) echo $BLOB_URI_DIGEST Uploading file from [artifact] to [ttl.sh/my-artifact-f42c22e0:5m] with media type [text/plain] File [artifact] is available directly at [ttl.sh/v2/my-artifact-f42c22e0/blobs/sha256:c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626] Uploaded image to: ttl.sh/my-artifact-f42c22e0sha256:790d47850411e902aabebc3a684eeb78fcae853d4dd6e1cc554d70db7f05f99f源码层面cmd/cosign/cli/upload/blob.go 的BlobCmd解析目标引用、按字节流探测 media type也可用命令行参数覆盖然后调用cremote.UploadFiles上传并返回 content-addressable 的 digest 地址。用户下载digest 直接烘焙进 URL可用 curl/wget 直接拉取并校验$ curl -L ttl.sh/v2/$BLOB_NAME/blobs/sha256:$BLOB_SUM artifact-fetched $ cat artifact-fetched | shasum -a 256 c69d72c98b55258f9026f984e4656f0e9fd3ef024ea3fac1d7e5c7e6249f1626 -签名使用普通cosign sign命令与 flag$ cosign sign --key cosign.key $BLOB_URI_DIGEST Enter password for private key: Pushing signature to: ttl.sh/my-artifact-f42c22e0同样必须用 digest 引用要签名的对象确保签名目标正确。Tekton BundlesTekton bundle 是存于 OCI 注册表的一组 Tekton 资源规范见 Tekton 官方文档可用tkn bundle push上传后用 cosign 签名$ tkn bundle push us.gcr.io/dlorenc-vmtest2/pipeline:latest -f task-output-image.yaml Creating Tekton Bundle: - Added TaskRun: to image Pushed Tekton Bundle to us.gcr.io/dlorenc-vmtest2/pipelinesha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155 $ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/pipelinesha256:124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155 Enter password for private key: tlog entry created with index: 5086 Pushing signature to: us.gcr.io/dlorenc-vmtest2/demo:sha256-124e1fdee94fe5c5f902bc94da2d6e2fea243934c74e76c2368acdc8d3ac7155.sigWASM 模块WebAssembly 模块可按规范存于 OCI 注册表通过cosign upload wasm上传后签名$ cosign upload wasm -f hello.wasm us.gcr.io/dlorenc-vmtest2/wasm $ cosign sign --key cosign.key us.gcr.io/dlorenc-vmtest2/wasmsha256:9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812 Enter password for private key: tlog entry created with index: 5198 Pushing signature to: us.gcr.io/dlorenc-vmtest2/wasm:sha256-9e7a511fb3130ee4641baf1adc0400bed674d4afc3f1b81bb581c3c8f613f812.sigeBPF 模块eBPF 程序也可存于 OCI 注册表用bee工具构建/推送cosign 可对其签名与验证$ bee build ./examples/tcpconnect/tcpconnect.c localhost:5000/tcpconnect:test $ bee push localhost:5000/tcpconnect:test $ cosign sign --key cosign.key localhost:5000/tcpconnectsha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6 Enter password for private key: Pushing signature to: localhost:5000/tcpconnect $ cosign verify --key cosign.pub localhost:5000/tcpconnect:test Verification for localhost:5000/tcpconnect:test -- The following checks were performed on each of these signatures: - The cosign claims were validated - The signatures were verified against the specified public key [{critical:{identity:{docker-reference:localhost:5000/tcpconnect},image:{docker-manifest-digest:sha256:7a91c50d922925f152fec96ed1d84b7bc6b2079c169d68826f6cf307f22d40e6},type:cosign container image signature},optional:null}]In-Toto Attestationcosign 内置 in-toto attestation 支持可从本地 predicate 文件创建并签名$ cosign attest --predicate file --key cosign.key $IMAGE_URI_DIGEST所有标准密钥管理系统均受支持载荷按 DSSE 签名规范签名。验证$ cosign verify-attestation --key cosign.pub $IMAGE_URI注册表支持与兼容性说明cosign 通过 go-containerregistry 与注册表交互兼容性良好但部分注册表存在细节差异。README 列出已经过测试的注册表包括AWS Elastic Container RegistryGCP Artifact Registry / Container RegistryDocker HubAzure Container RegistryJFrog Artifactory Container RegistryCNCF distribution/distribution RegistryGitLab Container RegistryGitHub Container RegistryCNCF Harbor RegistryDigital Ocean Container RegistrySonatype Nexus Container RegistryAlibaba Cloud Container RegistryRed Hat Quay Container Registry 3.6 / quay.ioElastic Container RegistryIBM Cloud Container RegistryCloudsmith Container RegistryCNCF zot RegistryOVHcloud Managed Private Registry对于尚未完全支持 OCI media type 的注册表可设置环境变量COSIGN_DOCKER_MEDIA_TYPES1回退到旧版 Docker 等价 media typeCOSIGN_DOCKER_MEDIA_TYPES1 cosign sign --key cosign.key legacy-registry.example.com/my/image$DIGEST已知取舍Caveats有意缺失的功能cosign只生成 ECDSA-P256 密钥并使用 SHA256 哈希无论是临时 keyless 签名还是托管密钥签名密钥以 PEM 编码的 PKCS8 格式存储。但 cosign 可以存储和检索任何算法、任何格式的签名。载荷格式cosign 仅支持 Red Hat Simple Signing 格式的载荷形如{ critical: { identity: { docker-reference: testing/manifest }, image: { Docker-manifest-digest: sha256:20be...fe55 }, type: cosign container image signature }, optional: { creator: Bob the Builder, timestamp: 1458239713 } }该载荷可由cosign generate $IMAGE_URI_DIGEST直接生成。签名规范 specs/SIGNATURE_SPEC.md 对此格式补充了语义media type 固定为application/vnd.dev.cosign.simplesigning.v1jsoncritical.type固定为cosign container image signaturecritical.identity.docker-reference字段被忽略用户自定义声明可放入Optional段。这正是cosign sign -a keyvalue注解写入的位置如 Tag Signing 一节所示。注册表存储细节cosign 签名以独立 OCI 对象存储在注册表中与所签对象之间只有弱引用关系注册表并不理解这种关联镜像被删除时签名不会被级联删除或回收签名可以方便地在环境间复制但这不是自动的。多签名以列表形式存储目前存在竞态追加签名是读-追加-写操作并发竞争时最后写入者胜出见 specs/SIGNATURE_SPEC.md 对多签名竞态的说明。指定签名仓库默认签名存放在与镜像相同的仓库。可用COSIGN_REPOSITORY环境变量重定向$ export COSIGN_REPOSITORYgcr.io/my-new-repo $ cosign sign --key cosign.key $IMAGE_URI_DIGEST则gcr.io/dlorenc-vmtest2/demo的签名被存到gcr.io/my-new-repo/demo:sha256-DIGEST.sig。源码中该变量定义于 pkg/oci/remote/options.goRepoOverrideEnvKey COSIGN_REPOSITORY并在 sign.go 通过ociremote.GetEnvTargetRepository()读取以决定推送目标。不同注册表对repository格式要求不同GCRgcr.io/$REPO即可如上例Artifact Registry必须给完整镜像名$LOCATION-docker.pkg.dev/$PROJECT/$REPO/$STORAGE_IMAGE例如$ export COSIGN_REPOSITORYus-docker.pkg.dev/my-new-repo/demo $ cosign sign --key cosign.key $IMAGE_URI_DIGEST仅指定$LOCATION-docker.pkg.dev/$PROJECT/$REPO在 Artifact Registry 中不可用。options_test.go的测试也印证COSIGN_REPOSITORY必须是registry 加路径的完整仓库形式仅含 registry 名会解析失败见 pkg/oci/remote/options_test.go。签名格式规范与密钥存储cosign 的设计受 minisign 与 signify 启发。私钥以 PEM 格式存储使用 scrypt 作为 KDF、nacl/secretbox 加密PEM 头为ENCRYPTED SIGSTORE PRIVATE KEY-----BEGIN ENCRYPTED SIGSTORE PRIVATE KEY----- ... -----END ENCRYPTED SIGSTORE PRIVATE KEY-----公钥以 PEM 编码的标准 PKIX 格式存盘头为PUBLIC KEY-----BEGIN PUBLIC KEY----- MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAELigCnlLNKgOglRTx1D7JhI7eRw99 QolE9Jo4QUxnbMy5nUuBLUZF9qqfm/Dg1BNeHRThHzWh2ki9vAEgWEDOw -----END PUBLIC KEY-----存储规范签名如何定位cosign 把签名存放在 OCI 注册表采用基于 sha256 的 tag 命名约定定位签名索引。README 原文图示见 images/signatures.dot.svgreg.example.com/ubuntusha256:703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715的签名位于reg.example.com/ubuntu:sha256-703218c0465075f4425e58fac086e09e1de5c340b12976ab9eb8ad26615c3715.sig。粗略的换算规则忽略主机名端口s/:/-/g且s//:/g。规范文档 specs/SIGNATURE_SPEC.md 给出了精确的四步tag 先解析为 digest再将sha256:abcdef...中的:替换为-并追加.sig后缀。一个签名对象OCI Image Manifest中可嵌入多条签名载荷 blob 以application/vnd.dev.cosign.simplesigning.v1jsonmedia type 上传digest 通过 Descriptor 写入 manifest 的 layerbase64 签名、PEM 证书与证书链则作为 layer annotation键分别为dev.cosignproject.cosign/signature、dev.cosignproject.cosign/certificate、dev.cosignproject.cosign/chain存储。keyless 场景还会附加bundle含 Rekor SET 与日志条目字段用于离线验证与可选的rfc3161timestamp时间戳机构响应详见 specs/SIGNATURE_SPEC.md。该签名关系是两跳链式哈希Sign(sha256(SimpleSigningPayload(sha256(Image Manifest))))签名与目标镜像的绑定完全由 payload 内嵌的镜像 sha256 digest 保证签名本身必须与注册表使用相同的哈希算法以此削减攻击面详见 specs/SIGNATURE_SPEC.md。KMS 支持cosign 支持用 KMS 提供商生成和签名密钥目前内置 HashiCorp Vault、AWS KMS、GCP KMS、Azure Key Vault其他 KMS 提供商可作为外部插件接入。KMS 能力同样可从入口源码印证cmd/cosign/main.go 静态导入了四个 KMS 包aws/azure/gcp/hashivault。签名任意 OCI 制品以 cosign 签 cosignOCI 制品不限于镜像可用 oras 推送后由 cosign 签名、再用 cosign 验证——README 中签 cosign 自己的完整示例$ oras push us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact ./cosign Uploading f53604826795 cosign Pushed us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact Digest: sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef$ cosign sign --key cosign.key us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifactsha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef Enter password for private key: Pushing signature to: us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifact:sha256-551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef.sig$ cosign verify --key cosign.pub us-central1-docker.pkg.dev/dlorenc-vmtest2/test/artifactsha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef The following checks were performed on each of these signatures: - The cosign claims were validated - The claims were present in the transparency log - The signatures were integrated into the transparency log when the certificate was valid - The signatures were verified against the specified public key - The code-signing certificate was verified using trusted certificate authority certificates {Critical:{Identity:{docker-reference:},Image:{Docker-manifest-digest:sha256:551e6cce7ed2e5c914998f931b277bc879e675b74843e6f29bc17f3b5f692bef},Type:cosign container image signature},Optional:null}进阶使用场景Tag Signing签名 tag→digest 映射签名保护的是注册表对象的 digest。cosign sign的-a注解 flag 可把额外数据写入被签名的载荷例如声明某个 tag 指向某个 digest$ docker push $IMAGE_URI The push refers to repository [dlorenc/demo] 994393dc58e7: Pushed 5m: digest: sha256:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870 size: 528 $ TAGsign-me $ cosign sign --key cosign.key -a tag$TAG $IMAGE_URI_DIGEST Enter password for private key: Pushing signature to: dlorenc/demo:1304f174557314a7ed9eddb4eab12fed12cb0cd9809e4c28f29af86979a3c870.sig验证时用-a同时校验注解值$ cosign verify --key cosign.pub -a tag$TAG $IMAGE_URI | jq . { Critical: { Identity: { docker-reference: }, Image: { Docker-manifest-digest: 97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36 }, Type: cosign container image signature }, Optional: { tag: sign-me } }Counter-Signing对签名再签名签名对象本身也是注册表制品可以被再次签名形成counter-signature从而既保护原签名集合、又保护被引用的制品充当对签名本身的证明$ cosign sign --key cosign.key -a sigoriginal $IMAGE_URI_DIGEST Enter password for private key: Pushing signature to: dlorenc/demo:sha256-97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36.sig $ cosign verify --key cosign.pub dlorenc/demo | jq . { Critical: { Identity: { docker-reference: }, Image: { Docker-manifest-digest: 97fc222cee7991b5b061d4d4afdb5f3428fcb0c9054e1690313786befa1e4e36 }, Type: cosign container image signature }, Optional: { sig: original } }$ crane tag $(cosign triangulate $IMAGE_URI) mysignature 2021/02/15 20:22:55 dlorenc/demo:mysignature: digest: sha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e size: 556 $ cosign sign --key cosign.key -a sigcounter dlorenc/demo:mysignature Enter password for private key: Pushing signature to: dlorenc/demo:sha256-71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e.sig $ cosign verify --key cosign.pub dlorenc/demo:mysignature {Critical:{Identity:{docker-reference:},Image:{Docker-manifest-digest:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e},Type:cosign container image signature},Optional:{sig:counter}}$ crane manifest dlorenc/demosha256:71f70e5d29bde87f988740665257c35b1c6f52dafa20fab4ba16b3b1f4c6ba0e { schemaVersion: 2, config: { mediaType: application/vnd.oci.image.config.v1json, size: 233, digest: sha256:3b25a088710d03f39be26629d22eb68cd277a01673b9cb461c4c24fbf8c81c89 }, layers: [ { mediaType: application/vnd.oci.descriptor.v1json, size: 217, digest: sha256:0e79a356609f038089088ec46fd95f4649d04de989487220b1a0adbcc63fadae, annotations: { dev.sigstore.cosign/signature: 5uNZKEP9rm8zxAL0VVX7McMmyArzLqtxMTNPjPO2ns5GJpBeXgi9ILUWjmGAKBCqiexTxzLC1/nkOzD4cDA } } ] }设计需求与未来方向README 明确的设计需求包括签名存储、查询与检索不依赖外部服务尽量广泛的注册表支持一切通过注册表 API 完成完全不要求 PGP用户必须能发现镜像的全部签名签名者可在 push 之后签名多个实体可签同一镜像签名不改变镜像本身纯 Go 实现。未来方向README 原文提及的构想并非已实现能力注册表 API 若演进可改进命名约定与 read-modify-write 更新模式可签名注册表中的任何对象多平台 Index、Helm Charts、Tekton Pipelines 等在签名注解中承载 tag→digest 映射以支持 TUF 式冻结攻击防护对基础镜像层签名以约束派生镜像的构建来源。FAQ为什么不用 Notary v2README 引用了一篇 Notary V2 与 Cosign 的对比文章并欢迎补充更多对比内容为什么不用 containers/image signingcontainers/image签名与 cosign 接近且复用相同的载荷格式差异在于 cosign 用 ECDSA-P256 而非 PGP并把签名存进注册表为什么不用 TUF作者认为两者互补、可协同使用甚至可复用注册表做 TUF 存储。版本与发布节奏cosign 按需发布patch release 修复小 bugminor release 在积累多个修复或特性后定期发布major release 在有破坏性变更时发布。发布资产中附带 GoReleaser 签名 cosign blob 时产生的 Sigstore bundle 文件该文件不参与 cosign 自身运行仅供用户自行校验 release 二进制完整性。延伸阅读签名格式与存储规范specs/SIGNATURE_SPEC.md签名命令核心实现cmd/cosign/cli/sign/sign.goblob 签名实现cmd/cosign/cli/sign/sign_blob.goblob 上传实现cmd/cosign/cli/upload/blob.go仓库覆盖环境变量实现pkg/oci/remote/options.goCLI 根命令与子命令注册cmd/cosign/cli/commands.go签名存储结构示意图images/signatures.dot.svg【免费下载链接】cosignCode signing and transparency for containers and binaries项目地址: https://gitcode.com/GitHub_Trending/co/cosign创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

Cosign 容器与二进制制品签名指南：基于 Sigstore 的密钥无感签名与透明日志验证实践

相关推荐

Lance 项目贡献指南：从 Conventional Commits 到格式规范投票的完整参与路径

使用 TanStack Form 与 Lit 构建简单表单：从零到可运行的实战指南

极空间NAS部署Wiki.js知识库：Docker与PostgreSQL完整实战指南

更多资讯

华为硬件岗机试本质：信号完整性与电源鲁棒性工程思维考核

QMK 固件中 Morgan65 的完整移植解析：USB/蓝牙双模 65% 键盘的构建、矩阵与自定义蓝牙驱动

SEO优化实战：关键词研究与内容创作全攻略

E2B生产级架构：预热池、MinIO分层存储与AI运维实践

rust-libp2p 的 Kademlia 协议栈演进史：从 0.20 到 0.49 的 API 变迁与配置实践

基于.NET与微信小程序的市容监察管理系统设计与实现

今日更新

AWS无服务器应用开发指南：从Lambda到SAM的架构与实践

SpringBoot+Vue人事系统实战：解决HR数据断点与事务一致性

MATLAB手写紧束缚模型计算石墨烯能带结构

本周精选

AI驱动的自动化专利分析平台技术解析

LeetCode-Go 题解：1252. Cells with Odd Values in a Matrix（奇数值单元格计数）双解法剖析

在线答疑系统Java毕设实战：Spring Boot前后端分离与状态流转

本月热门

基于YOLO的焊缝缺陷检测：从数据标注到工业部署全流程实践

分布式服务的决策记录

创业产品的首版范围

读完文章，想聊聊您的网站？