Skip to content
Latchkey

Cosign vs GPG: artifact とコンテナへの署名

どちらも artifact に署名しますが、異なる時代のためのものです。GPG は自分で管理する長寿命の鍵を持つ、長年使われてきた汎用署名ツールで、Cosign (Sigstore) はコンテナとサプライチェーンのために作られ、OIDC 経由の keyless 署名と公開の透明性ログを備えます。

Cosign と GPG はどちらも、artifact があなたから来て改ざんされていないことを証明します。GPG は汎用的で成熟していますが鍵管理をあなたに委ねます。Cosign はコンテナイメージと OCI artifact を対象とし、長寿命の鍵を保持せずに署名できます。ここでは率直な比較を示します。

CosignGPG
対象コンテナ、OCI artifact、サプライチェーン汎用の署名/暗号化
keyless (OIDC) または鍵ペア自分で管理する長寿命の鍵ペア
透明性ログあり (Rekor)なし
コンテナサポート第一級 (digest でイメージに署名)手動、コンテナネイティブではない
鍵管理の負担keyless では低い高い (ローテーション、配布)
成熟度より新しく、広く採用数十年前から、ユビキタス

鍵管理 vs keyless

GPG は、生成、保護、ローテーション、配布を行う長寿命の秘密鍵に依存します。これは強力ですが運用上重く、特に署名鍵の保管がリスクとなる短命の CI runner ではなおさらです。Cosign の keyless 署名は OIDC アイデンティティ (例えば CI ジョブのアイデンティティ) に紐づいた短命の証明書を使うため、漏洩する長寿命の secret がなく、各署名は Rekor 透明性ログに記録されます。

設計からしてコンテナネイティブ

Cosign は digest でコンテナイメージに署名・検証し、registry 内でイメージと並べて署名を保存します。これは GPG が決して設計されていなかったことです。OCI イメージとサプライチェーンの attestation (SBOM、provenance) には Cosign が自然な選択です。GPG は従来のワークフローでのリリース、コミット、パッケージへの署名に依然として優れています。

CI では

Cosign の keyless 署名は CI と完璧に組み合わさります。runner の OIDC token が署名者のアイデンティティとなり、管理すべき secret がなく、検証ポリシーは deploy 前に署名を要求できます。すでに GPG でリリースに署名しているなら、それを並行して続けられます。

結論

コンテナイメージとサプライチェーンの artifact への署名、特に CI での keyless 署名と透明性ログには Cosign を、汎用署名、リリース artifact、コミットには GPG を維持しましょう。両者は異なるニーズに対応し、しばしば共存します。

関連ガイド