このページは Cloud Translation API によって翻訳されました。

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

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

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

費用

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

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

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

始める前に

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.

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

Install the Google Cloud CLI.

To initialize the gcloud CLI, run the following command:

gcloud init

Note: If you installed the gcloud CLI previously, make sure you have the latest version by running

gcloud components
      update

Create or select a Google Cloud project.

Create a Google Cloud project:
```
gcloud projects create PROJECT_ID
```
Replace PROJECT_ID with a name for the Google Cloud project you are creating.
Select the Google Cloud project that you created:
```
gcloud config set project PROJECT_ID
```
Replace PROJECT_ID with your Google Cloud project name.

Make sure that billing is enabled for your Google Cloud project.

Enable the Binary Authorization, Cloud Key Management Service, Google Kubernetes Engine, Artifact Registry APIs:

gcloud services enable binaryauthorization.googleapis.com cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com

gcloud CLI が最新バージョンであることを確認します。
kubectl コマンドラインツールをインストールします。
Binary Authorization ポリシーと GKE クラスタが別々のプロジェクトにある場合は、両方のプロジェクトで Binary Authorization が有効になっていることを確認します。
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 ロールを付与します。

クラスタプロジェクトのポリシーにアクセスするための権限をクラスタプロジェクトの Binary Authorization サービスエージェントに付与します。
1. クラスタプロジェクトの Binary Authorization サービスエージェントを取得します。
```
PROJECT_NUMBER=$(gcloud projects list --filter="projectId:CLUSTER_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
CLUSTER_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
  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 に置き換えます。
ポリシープロジェクトの Binary Authorization サービスエージェントがリポジトリ内の署名にアクセスできるようにします。
1. ポリシープロジェクトの Binary Authorization サービスエージェントを取得します。
```
PROJECT_NUMBER=$(gcloud projects list \
  --filter="projectId:POLICY_PROJECT_ID" \
  --format="value(PROJECT_NUMBER)")
SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
  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

鍵ペアの作成に必要な環境変数を設定します。これを行うには、次のプレースホルダを入力して、コマンドを実行することをおすすめします。
```
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 鍵の名前
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 コマンドの実行が必要になる場合があります。
公開鍵の場所を記録します。

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

PKIX Cloud KMS gcloud

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

鍵ペアの作成に必要な環境変数を設定します。これを行うには、次のプレースホルダを入力して、コマンドを実行することをおすすめします。
```
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 鍵の名前

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

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

鍵を作成します。

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}

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

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}

ローカル鍵

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

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

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

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

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 は、ポリシーファイルのパスに置き換えます。

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

後述のコマンドデータを使用する前に、次のように置き換えます。
- 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

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）

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）

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

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）

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）

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

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）

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）

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

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）

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）

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 に記録されます。

イメージに署名する

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

イメージの署名に使用する変数を作成します。
```
IMAGE_PATH=IMAGE_PATH
IMAGE_DIGEST=sha256:IMAGE_DIGEST_SHA
IMAGE_TO_SIGN="${IMAGE_PATH}@${IMAGE_DIGEST}"
```
次のように置き換えます。
- IMAGE_PATH: イメージのパス
- IMAGE_DIGEST_SHA: イメージのダイジェストの SHA ハッシュ
イメージに署名し、その署名を 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}
```
共同署名プロンプトに応答する:

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

署名を手動で検証する

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

署名が 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 の仕様をご覧ください。
署名を手動で検証します。

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 と表示されます。

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

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

kubectl を構成します。
```
gcloud container clusters get-credentials CLUSTER_NAME \
    --location=LOCATION \
    --project=CLUSTER_PROJECT_ID
```
次のように置き換えます。
- CLUSTER_NAME: クラスタの名前
- LOCATION: クラスタのロケーション
- CLUSTER_PROJECT_ID: クラスタプロジェクト ID
イメージをデプロイして、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 エントリのログを表示する

Cloud Logging のエントリを検索して、CV 構成エラーと CV プラットフォームポリシーの検証違反を確認できます。

CV は、エラーと違反を 24 時間以内に Cloud Logging に記録します。通常は数時間以内にエントリを確認できます。

CV 構成エラーログを表示する

CV 構成エラーログを表示するには、次のコマンドを実行します。

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

次の出力は、CV プラットフォームポリシーが見つからない構成エラーを示しています。

{
  "insertId": "141d4f10-72ea-4a43-b3ec-a03da623de42",
  "jsonPayload": {
    "@type": "type.googleapis.com/google.cloud.binaryauthorization.v1beta1.ContinuousValidationEvent",
    "configErrorEvent": {
      "description": "Cannot monitor cluster 'us-central1-c.my-cluster': Resource projects/123456789/platforms/gke/policies/my-policy does not exist."
    }
  },
  "resource": {
    "type": "k8s_cluster",
    "labels": {
      "cluster_name": "my-cluster",
      "location": "us-central1-c",
      "project_id": "my-project"
    }
  },
  "timestamp": "2024-05-28T15:31:03.999566Z",
  "severity": "WARNING",
  "logName": "projects/my-project/logs/binaryauthorization.googleapis.com%2Fcontinuous_validation",
  "receiveTimestamp": "2024-05-28T16:30:56.304108670Z"
}

CV プラットフォームポリシーの検証違反を表示する

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

過去 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 署名チェックを使用する

費用

始める前に

必要なロール

概要

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

鍵ペアを作成する

PKIX Cloud KMS Cosign

PKIX Cloud KMS gcloud

ローカル鍵

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

Linux、macOS、Cloud Shell

Windows（PowerShell）

Windows（cmd.exe）

CV を有効にする

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

Linux、macOS、Cloud Shell

Windows（PowerShell）

Windows（cmd.exe）

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

Linux、macOS、Cloud Shell

Windows（PowerShell）

Windows（cmd.exe）

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

Linux、macOS、Cloud Shell

Windows（PowerShell）

Windows（cmd.exe）

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

Linux、macOS、Cloud Shell

Windows（PowerShell）

Windows（cmd.exe）

CV をテストする

イメージに署名する

PKIX Cloud KMS

ローカル鍵

署名を手動で検証する

Google Cloud コンソール

コマンドライン

PKIX Cloud KMS

ローカル鍵

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

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

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

CV 構成エラーログを表示する

CV プラットフォーム ポリシーの検証違反を表示する

チェックの種類

サンプルログ

クリーンアップ

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

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

ポリシーを削除する

次のステップ

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

CV プラットフォームポリシーの検証違反を表示する

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