cosignとSigstoreでコンテナイメージ署名を本番フローに組み込む｜鍵管理とポリシー適用の設計判断

なぜ今コンテナ署名が求められるのか ― サプライチェーン攻撃の実態

コンテナイメージのサプライチェーン攻撃は、2021年のSolarWinds事件以降、クラウドネイティブ環境でも現実的な脅威として認識されるようになりました。攻撃者はビルドパイプラインやレジストリへの不正アクセスを通じて悪意あるコードをイメージに混入させ、本番クラスタまで到達させます。タグの一致だけでは「そのイメージが意図したビルドから生成されたか」を証明できないため、署名による来歴（プロベナンス）の保証が必要になります。

NIST SP 800-204CやCNCFのソフトウェアサプライチェーンBest Practicesも、イメージ署名を基本コントロールとして明記しています。規制対応の観点からも、金融・医療・公共インフラの運用現場では署名の導入が事実上の標準要件になりつつあります。

Sigstoreとcosignのアーキテクチャを理解する

Sigstoreは、Linux Foundationの傘下で開発されているOSSのサプライチェーンセキュリティプロジェクトです。主要なコンポーネントとして、署名ツールのcosign、公開鍵基盤のFulcio（証明書認証局）、改ざん検知のための監査ログRekorの3つで構成されています。

従来のGPG署名と比較したときのSigstoreの最大の特徴は「キーレス署名」を実現している点です。署名者はOIDCプロバイダ（GitHub Actions、Google、Microsoft等）でのIDトークンを使ってFulcioから短命証明書を取得し、その証明書で署名します。秘密鍵を長期保管しないため、鍵漏洩リスクが構造的に低くなります。署名と証明書はRekorの追記専用ログに記録されるため、後から改ざんすることは困難です。

cosignはOCI（Open Container Initiative）仕様に従い、署名をイメージと同じレジストリ内に別タグとして保存します。sha256-[ダイジェスト].sigという命名規則で付随するため、イメージダイジェストと署名を1対1で追跡できます。

本番フローへの組み込み ― 署名から検証までの実装手順

鍵管理の選択：KMS署名 vs キーレス署名

本番導入にあたって最初に決める設計判断が「鍵をどう管理するか」です。選択肢は大きく2つあります。

• KMS署名：AWS KMS、Google Cloud KMS、HashiCorp Vaultなどに秘密鍵を保存し、cosignから呼び出す方式。自社管理のCI/CDやオンプレ環境と相性がよく、鍵のローテーションポリシーを組織側で制御できます。cosign sign --key awskms:///arn:aws:kms:…のように参照します。
• キーレス署名（Fulcio OIDC）：GitHub ActionsなどのCI上でIDトークンを使って短命証明書を取得する方式。鍵の管理インフラが不要なため、クラウドネイティブなCIとの統合がシンプルです。パブリックRekorへの記録が必須になる点（ログが公開される）は留意が必要です。

機密性の高い業務システムではキーレス署名のログ公開が問題になることがあります。その場合はRekorのプライベートインスタンスを立てるか、KMS署名と組み合わせる設計が現実解です。

GitHub ActionsでのCI署名ステップ

キーレス署名をGitHub Actionsに組み込む場合、ワークフローに以下の要素を追加します。

permissions:
  id-token: write
  contents: read

steps:
  - name: Install cosign
    uses: sigstore/cosign-installer@v3

  - name: Build and push image
    id: build
    uses: docker/build-push-action@v5
    with:
      push: true
      tags: ghcr.io/org/app:${{ github.sha }}

  - name: Sign image
    env:
      DIGEST: ${{ steps.build.outputs.digest }}
    run: |
      cosign sign --yes \
        ghcr.io/org/app@${DIGEST}

id-token: write権限が必要な点に注意してください。このパーミッションなしではFulcioへのOIDCトークン送信が失敗します。また、--yesフラグはCI環境での対話プロンプトをスキップするためのものです。署名対象にはタグではなくダイジェスト（@sha256:…）を使うことで、タグの上書きによる署名バイパスを防げます。

Kubernetesクラスタでのポリシー適用

署名を生成するだけでは不十分です。クラスタ側で「署名済みイメージしかデプロイできない」というポリシーを強制しなければ、攻撃者が署名なしイメージを直接プッシュした場合に無意味になります。

Sigstoreが提供するPolicy Controller（旧称Cosign Admission Webhook）は、Kubernetes Admission Webhookとして動作し、Pod作成時にイメージの署名を検証します。HelmでPolicy Controllerをインストールした後、ClusterImagePolicyリソースで検証ルールを定義します。

apiVersion: policy.sigstore.dev/v1beta1
kind: ClusterImagePolicy
metadata:
  name: require-signed-images
spec:
  images:
    - glob: "ghcr.io/org/**"
  authorities:
    - keyless:
        url: https://fulcio.sigstore.dev
        identities:
          - issuer: https://token.actions.githubusercontent.com
            subjectRegExp: "https://github.com/org/.*"

identitiesフィールドで発行者（issuer）とサブジェクト（subject）を絞り込むことが重要です。Fulcioの証明書に含まれるこれらのクレームを検証することで「どのCI実行から署名されたか」まで確認できます。これを省略すると、任意のGitHubユーザーが署名したイメージを受け入れてしまいます。

設計判断のポイント ― 運用コストとセキュリティのトレードオフ

本番導入で現場がつまずきやすいのは、署名フローそのものよりも「署名検証失敗時の影響範囲の設計」です。Policy ControllerはデフォルトでWarnモード（ポリシー違反でもデプロイは通す）とEnforceモード（違反でデプロイを拒否）を切り替えられます。段階的導入ではWarnモードから始め、全イメージに署名が付与されていることをログで確認してからEnforceに切り替える進め方が安全です。

Rekorのパブリックログに記録される情報はビルドのメタデータ（コミットSHA、ワークフロー名、リポジトリURL等）であり、ソースコードそのものは含まれません。ただし、プライベートリポジトリのワークフロー名やコミットSHAが公開ログに残ることを問題視する組織は、プライベートRekorインスタンスの構築を検討してください。Sigstoreのすべてのコンポーネントはセルフホストが可能です。

マルチテナントクラスタでは名前空間ごとに異なるポリシーを適用する場合があります。ClusterImagePolicyはクラスタ全体に適用されますが、mode: warnやmatchフィールドで名前空間スコープを絞ることができます。開発・ステージング・本番で署名要件を段階的に厳しくする設計がよく取られます。

切り戻しと障害シナリオへの備え

署名フローが本番で障害を起こしたときの切り戻し手順をあらかじめ設計しておくことが、安定運用の前提です。代表的な障害パターンと対処を整理します。

• Fulcio/Rekorへのネットワーク疎通不可：パブリックSigstoreエンドポイントへの接続が一時的に失われた場合、キーレス署名のCI署名ステップが失敗します。KMS署名をフォールバックとして併用するか、Rekorのミラーエンドポイントを設定しておくことで影響を軽減できます。
• Policy Controllerの誤設定でデプロイ全停止：EnforceモードのPolicy ControllerはWebhookが落ちると全Podの作成を拒否します。WebhookのfailurpolicyをIgnoreに設定しておくことで、Policy Controller自体の障害時にはポリシーが無効化されてデプロイは通る設計にできます。セキュリティ要件によってはこの選択が許容されない場合もあるため、組織のリスク許容度に合わせて判断してください。
• 古い署名済みイメージの再デプロイ：証明書の有効期限（Fulcioは10分）が切れても署名はRekorログで検証可能です。cosignの検証はログエントリを参照するため、証明書期限は検証に影響しません。

切り戻しが必要になった場合、Policy ControllerのClusterImagePolicyをkubectl deleteすることでポリシー強制を即座に解除できます。ただしこの操作はGitOpsリポジトリで管理しておき、削除操作自体が監査ログに残るよう設計することが推奨されます。

2026年の現行環境差分 ― Sigstore v2系とエコシステムの成熟

2025年後半から2026年にかけて、Sigstoreのエコシステムは安定フェーズに移行しています。主な変化点を確認しておきましょう。

• cosign v2系のBundle形式：cosign v2以降では署名・証明書・Rekorエントリをひとつのバンドル（.sigstore拡張子）にまとめる形式が標準化されました。旧来の.sigタグと.att（Attestation）タグの分散管理よりも検証が簡便になっています。
• OCI 1.1仕様への対応：OCI Distribution Spec 1.1のReferrers APIが普及し、署名をイメージの「参照アーティファクト」として扱えるレジストリが増えています。GitHub Container Registry（ghcr.io）、Amazon ECR、Azure Container Registryはいずれも対応済みです。
• Policy Controllerの安定版：Sigstore Policy ControllerはGA（一般提供）に達しており、Kyverno・OPA Gatekeeperとの役割分担が整理されてきています。既存のKyvernoユーザーはKyvernoのSigstore検証プラグインを使う選択肢もあります。
• SLSA Level 2/3への統合：SLSA（Supply-chain Levels for Software Artifacts）のLevel 2以上を取得するためのProvenance生成ツール（slsa-github-generator）がcosign/Sigstoreと統合されており、Attestationとして付与できます。ガバナンス要件が厳しい環境ではSLSAレベルの達成とセットで設計することが増えています。

一方で、プライベートRekorのセルフホストはSigstoreの各コンポーネントをKubernetesクラスタ内で動かす必要があり、インフラ維持コストが発生します。2026年時点では、パブリックSigstoreインフラの可用性は実績として安定しており、厳格な規制要件がない限りはパブリックインフラを活用する判断が運用コストの観点から合理的です。

cosignとSigstoreは、コンテナイメージの来歴保証をGPGの複雑さなしに実現できる現在最も実用的なOSSツールです。鍵管理の方針とポリシー強制のタイミングを最初に設計し、Warnモードで稼働確認してからEnforceに移行するアプローチが、本番導入のリスクを最小化する定石といえます。