Sigstore 署名チェックを使用する

プレビュー

このプロダクトまたは機能には、サービス固有の利用規約の「一般的なサービス規約」の「pre-GA サービス規約」が適用されます。 一般提供前のプロダクトと機能は「現状のまま」ご利用いただけますが、サポートが制限される場合があります。 詳しくは、リリース ステージの説明をご覧ください。

このページでは、Binary Authorization の継続的検証（CV）で Sigstore 署名チェックの使用方法について説明します。このチェックでは、CV が有効になっている Google Kubernetes Engine（GKE）クラスタで実行される Pod に関連付けられたコンテナ イメージの Sigstore で生成された署名を検証します。このチェックと単純な署名証明書チェックの主な違いは、Sigstore 署名ワークフローでは Artifact Analysis のメモを使用して署名とイメージをリンクしない点です。すべての署名は、署名したイメージと一緒に保存されます。

このチェックは、Artifact Registry リポジトリのみをサポートします。

費用

このガイドでは、次の Google Cloud サービスを使用します。

• Binary Authorization。ただし、CV はプレビュー ステージの間は無料です。
• GKE
• Cloud Key Management Service
• Artifact Registry

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。

始める前に

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
2. Google Cloud CLI をインストールします。

3. gcloud CLI を初期化するには:

   gcloud init

   注: すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して、最新バージョンがインストールされていることを確認してください。

4. Google Cloud プロジェクトを作成または選択します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   • Google Cloud プロジェクトを作成します。

     gcloud projects create PROJECT_ID

     PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。

   • 作成した Google Cloud プロジェクトを選択します。

     gcloud config set project PROJECT_ID

     PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

5. Google Cloud プロジェクトで課金が有効になっていることを確認します。

6. Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry API を有効にします。

   gcloud services enable binaryauthorization.googleapis.comcloudkms.googleapis.comcontainer.googleapis.comartifactregistry.googleapis.com

7. Google Cloud CLI をインストールします。

8. gcloud CLI を初期化するには:

   gcloud init

   注: すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して、最新バージョンがインストールされていることを確認してください。

9. Google Cloud プロジェクトを作成または選択します。

   注: この手順で作成するリソースをそのまま保持する予定でない場合、既存のプロジェクトを選択するのではなく、新しいプロジェクトを作成してください。チュートリアルの終了後にそのプロジェクトを削除すれば、プロジェクトに関連するすべてのリソースを削除できます。

   • Google Cloud プロジェクトを作成します。

     gcloud projects create PROJECT_ID

     PROJECT_ID は、作成する Google Cloud プロジェクトの名前に置き換えます。

   • 作成した Google Cloud プロジェクトを選択します。

     gcloud config set project PROJECT_ID

     PROJECT_ID は、実際の Google Cloud プロジェクト名に置き換えます。

10. Google Cloud プロジェクトで課金が有効になっていることを確認します。

11. Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry API を有効にします。

    gcloud services enable binaryauthorization.googleapis.comcloudkms.googleapis.comcontainer.googleapis.comartifactregistry.googleapis.com

12. gcloud CLI が最新バージョンであることを確認します。
13. kubectl コマンドライン ツールをインストールします。
14. Binary Authorization ポリシーと GKE クラスタが別々のプロジェクトにある場合は、両方のプロジェクトで Binary Authorization が有効になっていることを確認します。
15. cosign コマンドライン ツールをインストールします。

必要なロール

このセクションでは、このチェックに必要なロールの設定方法について説明します。

概要

このガイドに記載されているプロダクトをすべて同じプロジェクトで実行する場合、権限を設定する必要はありません。Binary Authorization を有効にすると、ロールが正しく構成されます。複数のプロジェクトでプロダクトを実行する場合は、このセクションの説明に従ってロールを設定する必要があります。

各プロジェクトの Binary Authorization サービス エージェントに CV Sigstore 署名チェックの評価に必要な権限を付与するには、各プロジェクトの Binary Authorization サービス エージェントに次の IAM ロールを付与するよう管理者に依頼します。

• クラスタ プロジェクトがポリシー プロジェクトと異なる場合: クラスタ プロジェクトの Binary Authorization サービス エージェントに対する Binary Authorization ポリシー評価者（roles/binaryauthorization.policyEvaluator）
• イメージ リポジトリ プロジェクトがポリシー プロジェクトと異なる場合: ポリシー プロジェクトの Binary Authorization サービス エージェントに対する Artifact Registry 読み取り（roles/artifactregistry.reader）

ロールの付与の詳細については、アクセス権の管理をご覧ください。

管理者は、カスタムロールや他の事前定義ロールを使用して、各プロジェクトの Binary Authorization サービス エージェントに必要な権限を割り当てることもできます。

gcloud CLI を使用してロールを付与する

各プロジェクトの Binary Authorization サービス エージェントに CV の Sigstore 署名チェックの評価に必要な権限を付与するには、各プロジェクトの Binary Authorization サービス エージェントに次の IAM ロールを付与します。

1. クラスタ プロジェクトのポリシーにアクセスするための権限をクラスタ プロジェクトの Binary Authorization サービス エージェントに付与します。

   1. クラスタ プロジェクトの Binary Authorization サービス エージェントを取得します。

      PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      CLUSTER_SERVICE_ACCOUNT="service-$[e-mail]"
      

      CLUSTER_PROJECT_ID は、クラスタのプロジェクト ID に置き換えます。

   2. CV にクラスタのポリシーの評価を許可します。

      gcloud projects add-iam-policy-binding POLICY_PROJECT_ID \
          --member="serviceAccount:$CLUSTER_SERVICE_ACCOUNT" \
          --role='roles/binaryauthorization.policyEvaluator'
      

      POLICY_PROJECT_ID は、ポリシーを含むプロジェクトの ID に置き換えます。

2. ポリシー プロジェクトの Binary Authorization サービス エージェントがリポジトリ内の署名にアクセスできるようにします。

   1. ポリシー プロジェクトの Binary Authorization サービス エージェントを取得します。

      PROJECT_NUMBER=$(gcloud projects list \
        --filter="projectId:POLICY_PROJECT_ID" \
        --format="value(PROJECT_NUMBER)")
      SERVICE_ACCOUNT="service-$[e-mail]"
      

      POLICY_PROJECT_ID は、ポリシーを含むプロジェクトの ID に置き換えます。

   2. ロールを付与します。

      gcloud projects add-iam-policy-binding REPOSITORY_PROJECT_ID \
          --member="serviceAccount:$SERVICE_ACCOUNT" \
          --role='roles/artifactregistry.reader'
      

      REPOSITORY_PROJECT_ID は、リポジトリを含むプロジェクトの ID に置き換えます。

鍵ペアを作成する

このセクションでは、楕円曲線デジタル署名アルゴリズム（ECDSA）の非対称鍵ペアを作成します。

秘密鍵を使用してイメージに署名します。これにより、証明書が作成されます。公開鍵は、プラットフォーム ポリシーに含まれています。CV は証明書を確認するときに、公開鍵を使用して証明書を検証します。

Cloud Key Management Service（Cloud KMS）またはローカル鍵のいずれかを使用できますが、本番環境には Cloud KMS 鍵を使用することをおすすめします。

PKIX Cloud KMS Cosign

1. 鍵ペアの作成に必要な環境変数を設定します。これを行うには、次のプレースホルダを入力して、コマンドを実行することをおすすめします。

   KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
   KMS_KEYRING_NAME=KMS_KEYRING_NAME
   KMS_KEY_NAME=KMS_KEY_NAME
   KMS_KEY_LOCATION=global
   KMS_KEY_PURPOSE=asymmetric-signing
   KMS_KEY_ALGORITHM=ec-sign-p256-sha256
   KMS_PROTECTION_LEVEL=software
   KMS_KEY_VERSION=1
   

   次のように置き換えます。

   • KMS_KEY_PROJECT_ID: プロジェクト ID
   • KMS_KEYRING_NAME: Cloud KMS キーリングの名前
   • KMS_KEY_NAME: Cloud KMS 鍵の名前

2. Cosign CLI を使用して鍵を生成します。

   cosign generate-key-pair \
     --kms gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME}
   

   注: 認証情報を正しく構成するために、gcloud auth application-default login コマンドの実行が必要になる場合があります。

3. 公開鍵の場所を記録します。

   Cosign は、生成された公開鍵を cosign.pub として generate-key-pair コマンドが実行されたディレクトリに自動的に保存します。今後のコマンドに備えて、このファイルの場所を変数に保存します。

   PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
   

PKIX Cloud KMS gcloud

Cloud KMS で鍵ペアを作成する手順は次のとおりです。

1. 鍵ペアの作成に必要な環境変数を設定します。これを行うには、次のプレースホルダを入力して、コマンドを実行することをおすすめします。

   KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
   KMS_KEYRING_NAME=KMS_KEYRING_NAME
   KMS_KEY_NAME=KMS_KEY_NAME
   KMS_KEY_LOCATION=global
   KMS_KEY_PURPOSE=asymmetric-signing
   KMS_KEY_ALGORITHM=ec-sign-p256-sha256
   KMS_PROTECTION_LEVEL=software
   KMS_KEY_VERSION=1
   

   次のように置き換えます。

   • KMS_KEY_PROJECT_ID: プロジェクト ID
   • KMS_KEYRING_NAME: Cloud KMS キーリングの名前
   • KMS_KEY_NAME: Cloud KMS 鍵の名前

2. キーリングを作成します。

   gcloud kms keyrings create ${KMS_KEYRING_NAME} \
       --location=${KMS_KEY_LOCATION} \
       --project=${KMS_KEY_PROJECT_ID}
   

3. 鍵を作成します。

   gcloud kms keys create ${KMS_KEY_NAME} \
       --location=${KMS_KEY_LOCATION} \
       --keyring=${KMS_KEYRING_NAME}  \
       --purpose=${KMS_KEY_PURPOSE} \
       --default-algorithm=${KMS_KEY_ALGORITHM} \
       --protection-level=${KMS_PROTECTION_LEVEL} \
       --project=${KMS_KEY_PROJECT_ID}
   

4. 公開鍵マテリアルをファイルにエクスポートします。

   PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
   gcloud kms keys versions get-public-key 1 \
       --key=${KMS_KEY_NAME} \
       --keyring=${KMS_KEYRING_NAME} \
       --location=${KMS_KEY_LOCATION} \
       --output-file=${PUBLIC_KEY_FILE} \
       --project=${KMS_KEY_PROJECT_ID}
   

ローカル鍵

警告: セキュリティ リスクがあるため、ローカルで生成された鍵ペアを本番環境で使用することはおすすめしません。代わりに、Cloud Key Management Service の使用をおすすめします。この例は説明のみを目的としています。

鍵ペアをローカルで作成する手順は次のとおりです。

  cosign generate-key-pair
  PUBLIC_KEY_FILE="$(pwd)/cosign.pub"
  PRIVATE_KEY_FILE="$(pwd)/cosign.key"

プラットフォーム ポリシーを作成する

Sigstore 署名チェックを使用して CV プラットフォーム ポリシーを作成するには、次の操作を行います。

1. Sigstore 署名チェック プラットフォーム ポリシー ファイルを作成します。

   cat > POLICY_PATH <<EOF
   gkePolicy:
     checkSets:
     - checks:
       - displayName: sigstore-signature-check
         sigstoreSignatureCheck:
           sigstoreAuthorities:
           - displayName: sigstore-authority
             publicKeySet:
               publicKeys:
                 publicKeyPem: |
   $(awk '{printf "                %s\n", $0}' ${PUBLIC_KEY_FILE})
   EOF
   

   POLICY_PATH は、ポリシー ファイルのパスに置き換えます。

2. プラットフォーム ポリシーを作成します。

   後述のコマンドデータを使用する前に、次のように置き換えます。

   • POLICY_ID: 選択したプラットフォーム ポリシー ID。ポリシーが別のプロジェクトにある場合、完全なリソース名 projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID を使用できます。
   • POLICY_PATH: ポリシー ファイルのパス。
   • POLICY_PROJECT_ID: ポリシー プロジェクト ID。

   次のコマンドを実行します。

   Linux、macOS、Cloud Shell

   注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

   gcloud beta container binauthz policy create POLICY_ID \
       --platform=gke \
       --policy-file=POLICY_PATH \
       --project=POLICY_PROJECT_ID
   

   Windows（PowerShell）

   注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

   gcloud beta container binauthz policy create POLICY_ID `
       --platform=gke `
       --policy-file=POLICY_PATH `
       --project=POLICY_PROJECT_ID
   

   Windows（cmd.exe）

   注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

   gcloud beta container binauthz policy create POLICY_ID ^
       --platform=gke ^
       --policy-file=POLICY_PATH ^
       --project=POLICY_PROJECT_ID
   

CV を有効にする

チェックベースのプラットフォーム ポリシーで CV モニタリングを使用するように、新しいクラスタを作成するか、既存のクラスタを更新します。

CV モニタリングを使用するクラスタを作成する

このセクションでは、チェックベースのプラットフォーム ポリシーで CV モニタリングのみを使用するクラスタを作成します。

後述のコマンドデータを使用する前に、次のように置き換えます。

• CLUSTER_NAME: クラスタ名。
• LOCATION: ロケーション。例: us-central1、asia-south1
• POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID。
• POLICY_ID: ポリシー ID。
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID。

次のコマンドを実行します。

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

適用と CV モニタリングを使用するクラスタを作成する

このセクションでは、プロジェクト シングルトン ポリシーの適用と、チェックベースのプラットフォーム ポリシーを使用した CV モニタリングの両方を使用するクラスタを作成します。

後述のコマンドデータを使用する前に、次のように置き換えます。

• CLUSTER_NAME: クラスタ名。
• LOCATION: ロケーション。例: us-central1、asia-south1
• POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID。
• POLICY_ID: ポリシー ID。
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID。

次のコマンドを実行します。

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters create CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

CV モニタリングを使用するようにクラスタを更新する

このセクションでは、チェックベースのプラットフォーム ポリシーでのみ CV モニタリングを使用するようにクラスタを更新します。クラスタでプロジェクトのシングルトン ポリシーの適用がすでに有効になっている場合、このコマンドを実行すると、クラスタの適用が無効になります。代わりに、適用と CV モニタリングを有効にしてクラスタを更新することを検討してください。

後述のコマンドデータを使用する前に、次のように置き換えます。

• CLUSTER_NAME: クラスタ名
• LOCATION: ロケーション（例: us-central1、asia-south1）
• POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID
• POLICY_ID: ポリシー ID
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

次のコマンドを実行します。

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

適用と CV モニタリングを使用するようにクラスタを更新する

このセクションでは、チェックベースのプラットフォーム ポリシーを使用して、プロジェクト シングルトン ポリシーの適用と CV モニタリングの両方を使用するようにクラスタを更新します。

後述のコマンドデータを使用する前に、次のように置き換えます。

• CLUSTER_NAME: クラスタ名
• LOCATION: ロケーション（例: us-central1、asia-south1）
• POLICY_PROJECT_ID: ポリシーが保存されているプロジェクトの ID
• POLICY_ID: ポリシー ID
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

次のコマンドを実行します。

Linux、macOS、Cloud Shell

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE \
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID \
    --project=CLUSTER_PROJECT_ID

Windows（PowerShell）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME `
    --location=LOCATION `
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE `
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID `
    --project=CLUSTER_PROJECT_ID

Windows（cmd.exe）

注: 認証とプロジェクトを使用して Google Cloud CLI を初期化するには、gcloud init、gcloud auth login、または gcloud config set project のいずれかを実行します。

gcloud beta container clusters update CLUSTER_NAME ^
    --location=LOCATION ^
    --binauthz-evaluation-mode=POLICY_BINDINGS_AND_PROJECT_SINGLETON_POLICY_ENFORCE ^
    --binauthz-policy-bindings=name=projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID ^
    --project=CLUSTER_PROJECT_ID

CV をテストする

このセクションでは、署名付きイメージをデプロイして CV をテストします。この場合、CV Sigstore 署名チェックで署名は検証されますが、ログエントリは生成されません。

次に、未署名の別のイメージをデプロイしてみます。この場合、CV チェックで有効な署名が検出されないため、違反が Cloud Logging に記録されます。

イメージに署名する

このチェックを行うには、イメージに有効な署名が必要です。署名を作成する手順は次のとおりです。

1. イメージの署名に使用する変数を作成します。

   IMAGE_PATH=IMAGE_PATH
   IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
   IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
   

   次のように置き換えます。

   • IMAGE_PATH: イメージのパス
   • IMAGE_DIGEST_SHA: イメージのダイジェストの SHA ハッシュ

2. イメージに署名し、その署名を Artifact Registry に push します。

   PKIX Cloud KMS

   Cloud KMS でホストされている鍵でイメージに署名し、その署名を Artifact Registry に push します。

   cosign sign \
       --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
       ${IMAGE_TO_SIGN}
   

   ローカル鍵

   ローカル秘密鍵でイメージに署名し、その署名を Artifact Registry に push します。

   cosign sign --key ${PRIVATE_KEY_FILE} ${IMAGE_TO_SIGN}
   

3. 共同署名プロンプトに応答する:

   cosign sign コマンドを実行すると、Cosign は署名を透過的なログである Rekor にアップロードするかどうかを尋ねます。プロンプトで「y」または「n」と応答します。Rekor の詳細については、Rekor のドキュメントをご覧ください。

署名を手動で検証する

署名を手動で検証する手順は次のとおりです。

1. 署名が Artifact Registry に存在することを確認します。

   Google Cloud コンソール

   1. Google Cloud コンソールの [Artifact Registry] ページに移動します。

      Artifact Registry に移動

   2. リポジトリ リストで、イメージを含むリポジトリの名前をクリックします。

   3. 署名したイメージの名前をクリックします。

   4. 署名を含むアイテムを探します。このアイテムには sha256-[image digest].sig タグが付いています。タグ付きのアイテムは 1 つだけにしてください。

   5. [マニフェスト] をクリックします。

   6. さまざまなフィールドを含む JSON 形式のファイルが表示されます。各署名は、annotations マップの layers リストの 1 つの要素に存在します。署名はキー dev.cosignproject.cosign/signature の場所にあります。

      次にマニフェストの例を示します。

     {
           "schemaVersion": 2,
           "mediaType": "application/vnd.oci.image.manifest.v1+json",
           "config": {
               "mediaType": "application/vnd.oci.image.config.v1+json",
               "size": SIZE_OF_LAYERS,
               "digest": "DIGEST_OF_LAYERS"
           },
           "layers": [
               {
                   "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                   "size": SIZE_OF_ANNOTATIONS,
                   "digest": "DIGEST_OF_ANNOTATIONS",
                   "annotations": {
                       "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                       "dev.sigstore.cosign/bundle": "BUNDLE"
                   }
               }
           ]
     }
   

   マニフェストの例には次のものが含まれます。

   • SIZE_OF_LAYERS: layers 配列のサイズ（バイト単位）
   • DIGEST_OF_LAYERS: layers 配列のダイジェスト
   • SIZE_OF_ANNOTATIONS: annotations 辞書のサイズ（バイト単位）
   • DIGEST_OF_ANNOTATIONS: annotations 辞書のダイジェスト
   • BASE64_SIGNATURE: base64 形式でエンコードされた未加工の署名。これは検証に使用される署名です
   • BUNDLE: Sigstore 固有のメタデータ

   マニフェスト形式について詳しくは、Sigstore の cosign Signature の仕様をご覧ください。

   コマンドライン

   1. 正しいアーティファクトを見つけます。

      イメージとともに保存されているアイテムを一覧表示します。

      gcloud artifacts docker tags list ${IMAGE_PATH}
      

      出力例を以下に示します。

      Listing items under project PROJECT_ID, location REPOSITORY_LOCATION, repository REPOSITORY_NAME.
      TAG                         IMAGE                                                         DIGEST
      latest                      us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:abc123
      sha256-abc123.sig           us-east1-docker.pkg.dev/my-project/my-repo/my-image           sha256:def456
      

      出力では、sha256-abc123.sig タグの付いたアーティファクトのマニフェスト内に署名が含まれます。

   2. マニフェストを取得する

      sha256-IMAGE_DIGEST_SHA.sig タグの付いたアーティファクトのマニフェストを取得するには、次のコマンドを実行します。

      curl -X GET -H "Content-Type: application/json" \
                  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
                  -H "X-Goog-User-Project: REPOSITORY_PROJECT_ID" \
                  "https://REPOSITORY_LOCATION-docker.pkg.dev/v2/REPOSITORY_PROJECT_ID/REPOSITORY_NAME/IMAGE_NAME/manifests/sha256-IMAGE_DIGEST_SHA.sig"
      

      次のように置き換えます。

      • REPOSITORY_PROJECT_ID: リポジトリが含まれているプロジェクトの ID
      • REPOSITORY_LOCATION: リポジトリのロケーション
      • REPOSITORY_NAME: リポジトリの名前
      • IMAGE_NAME: イメージの名前

      さまざまなフィールドを含む JSON 形式のファイルが表示されます。各署名は、annotations マップの layers リストの 1 つの要素に存在します。署名はキー dev.cosignproject.cosign/signature の場所にあります。

      以下に、マニフェストの例を示します。

      {
          "schemaVersion": 2,
          "mediaType": "application/vnd.oci.image.manifest.v1+json",
          "config": {
              "mediaType": "application/vnd.oci.image.config.v1+json",
              "size": SIZE_OF_LAYERS,
              "digest": "DIGEST_OF_LAYERS"
          },
          "layers": [
              {
                  "mediaType": "application/vnd.dev.cosign.simplesigning.v1+json",
                  "size": SIZE_OF_ANNOTATIONS,
                  "digest": "DIGEST_OF_ANNOTATIONS",
                  "annotations": {
                      "dev.cosignproject.cosign/signature": "BASE64_SIGNATURE",
                      "dev.sigstore.cosign/bundle": "BUNDLE"
                  }
              }
          ]
      }
      

   マニフェストの例には次のものが含まれます。

   • SIZE_OF_LAYERS: layers 配列のサイズ（バイト単位）
   • DIGEST_OF_LAYERS: layers 配列のダイジェスト
   • SIZE_OF_ANNOTATIONS: annotations 辞書のサイズ（バイト単位）
   • DIGEST_OF_ANNOTATIONS: annotations 辞書のダイジェスト
   • BASE64_SIGNATURE: base64 形式でエンコードされた未加工の署名。これは検証に使用される署名です
   • BUNDLE: Sigstore 固有のメタデータ

   マニフェスト形式について詳しくは、Sigstore の cosign Signature の仕様をご覧ください。

2. 署名を手動で検証します。

   cosign verify を使用して、アップロードされた署名を検証します。

   PKIX Cloud KMS

   cosign verify --key gcpkms://projects/${KMS_KEY_PROJECT_ID}/locations/${KMS_KEY_LOCATION}/keyRings/${KMS_KEYRING_NAME}/cryptoKeys/${KMS_KEY_NAME} \
         ${IMAGE_PATH}@${IMAGE_DIGEST}
   

   ローカル鍵

   cosign verify --key {PUBLIC_KEY_FILE} ${IMAGE_PATH}@${IMAGE_DIGEST}
   

   注: 署名を一般公開の透過的なログである Rekor にアップロードしたかどうかによって、--insecure-ignore-tlog コマンドライン フラグを次の順序で追加し、署名を検証する必要があります。

   検証が成功した場合、コマンド出力に The signatures were verified against the specified public key と表示されます。

署名付きイメージをデプロイする

署名付きイメージをデプロイするには、次の操作を行います。

1. kubectl を構成します。

   gcloud container clusters get-credentials CLUSTER_NAME \
       --location=LOCATION \
       --project=CLUSTER_PROJECT_ID
   

   次のように置き換えます。

   • CLUSTER_NAME: クラスタの名前
   • LOCATION: クラスタのロケーション
   • CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

2. イメージをデプロイして、Binary Authorization ポリシーとデプロイを確認します。

   kubectl run hello-app-signed --image=${IMAGE_PATH}@${IMAGE_DIGEST}
   

   Pod がデプロイされました。イメージが署名されているため、CV はこの Pod に関連するログエントリを生成しません。

   注: デプロイ時にエラーが発生した場合は、リポジトリにアクセスするための権限を Compute Engine サービス エージェントに付与する必要があります。Google Cloud SDK のドキュメントをご覧ください。

未署名のイメージをデプロイする

このセクションでは、未署名のイメージをデプロイします。

ポリシーでは証明書が必須になっていますが、このイメージには証明書がないため、CV はコンテナの実行中に定期的に違反を記録します。

イメージをデプロイするには、次のコマンドを実行します。

  kubectl run hello-app-unsigned \
      --image=UNSIGNED_IMAGE_PATH@UNSIGNED_IMAGE_DIGEST

Pod がデプロイされました。イメージに証明書がないため、CV は Pod の実行中にログエントリを生成します。

CV エントリのログを表示する

CV は、プラットフォーム ポリシー違反を 24 時間以内に Cloud Logging に記録します。通常は数時間以内にエントリが表示されます。

有効にしたプラットフォーム ポリシーに違反するイメージがない場合、ログエントリは表示されません。

過去 7 日間の CV ログエントリを表示するには、次のコマンドを実行します。

gcloud logging read \
     --order="desc" \
     --freshness=7d \
     --project=CLUSTER_PROJECT_ID \
    'logName:"binaryauthorization.googleapis.com%2Fcontinuous_validation" "policyName"'

CLUSTER_PROJECT_ID は、クラスタ プロジェクト ID に置き換えます。

チェックの種類

CV では、チェックの違反情報が checkResults に記録されます。エントリで、値 checkType はチェックを示します。各チェックの値は次のとおりです。

• ImageFreshnessCheck
• SigstoreSignatureCheck
• SimpleSigningAttestationCheck
• SlsaCheck
• TrustedDirectoryCheck
• VulnerabilityCheck

サンプルログ

次の CV ロギング エントリの例は、信頼できるディレクトリ チェックに違反する非遵守のイメージを示しています。

{
  "insertId": "637c2de7-0000-2b64-b671-24058876bb74",
  "jsonPayload": {
    "podEvent": {
      "endTime": "2022-11-22T01:14:30.430151Z",
      "policyName": "projects/123456789/platforms/gke/policies/my-policy",
      "images": [
        {
          "result": "DENY",
          "checkResults": [
            {
              "explanation": "TrustedDirectoryCheck at index 0 with display name \"My trusted directory check\" has verdict NOT_CONFORMANT. Image is not in a trusted directory",
              "checkSetName": "My check set",
              "checkSetIndex": "0",
              "checkName": "My trusted directory check",
              "verdict": "NON_CONFORMANT",
              "checkType": "TrustedDirectoryCheck",
              "checkIndex": "0"
            }
          ],
          "image": "gcr.io/my-project/hello-app:latest"
        }
      ],
      "verdict": "VIOLATES_POLICY",
      "podNamespace": "default",
      "deployTime": "2022-11-22T01:06:53Z",
      "pod": "hello-app"
    },
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent"
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "project_id": "my-project",
      "location": "us-central1-a",
      "cluster_name": "my-test-cluster"
    }
  },
  "timestamp": "2022-11-22T01:44:28.729881832Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2022-11-22T03:35:47.171905337Z"
}

クリーンアップ

このセクションでは、このガイドの前半で構成した CV モニタリングをクリーンアップする方法について説明します。

クラスタで CV モニタリングを無効にするか、Binary Authorization と CV の両方を無効にできます。

クラスタで Binary Authorization を無効にする

クラスタで CV と Binary Authorization の両方を無効にするには、次のコマンドを実行します。

gcloud beta container clusters update CLUSTER_NAME \
    --binauthz-evaluation-mode=DISABLED \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID

次のように置き換えます。

• CLUSTER_NAME: クラスタの名前
• LOCATION: クラスタのロケーション
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

クラスタでチェックベースのポリシー モニタリングを無効にする

クラスタでチェックベースのポリシーを使用して CV を無効にし、Binary Authorization 適用ポリシーを使用して適用を再度有効にするには、次のコマンドを実行します。

gcloud beta container clusters update CLUSTER_NAME  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --location=LOCATION \
    --project="CLUSTER_PROJECT_ID"

次のように置き換えます。

• CLUSTER_NAME: クラスタの名前
• LOCATION: クラスタのロケーション
• CLUSTER_PROJECT_ID: クラスタ プロジェクト ID

--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE は、古いフラグ --enable-binauthz と同じです。

ポリシーを削除する

ポリシーを削除するには、次のコマンドを実行します。チェックベースのポリシー監査を無効にするために、チェックベースのプラットフォーム ポリシーを削除する必要はありません。

gcloud beta container binauthz policy delete POLICY_ID \
    --platform=gke \
    --project="POLICY_PROJECT_ID"

次のように置き換えます。

• POLICY_ID: ポリシーの ID
• POLICY_PROJECT_ID: ポリシー プロジェクト ID

次のステップ

• イメージの鮮度チェックを使用する
• シンプルな署名証明書チェックを使用する
• Sigstore 署名チェックを使用する
• SLSA チェックを使用する
• 信頼できるディレクトリのチェックを使用する
• 脆弱性チェックを使用する
• CV ログを表示する