このページでは、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
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
始める前に
- Google Cloud アカウントにログインします。 Google Cloudを初めて使用する場合は、 アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。
-
Google Cloud CLI をインストールします。
-
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
-
gcloud CLI を初期化するには、次のコマンドを実行します。
gcloud init -
Google Cloud プロジェクトを作成または選択します。
プロジェクトの選択または作成に必要なロール
- プロジェクトを選択する: プロジェクトの選択に特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトであれば、どのプロジェクトでも選択できます。
-
プロジェクトを作成する: プロジェクトを作成するには、
resourcemanager.projects.create権限を含むプロジェクト作成者ロール（roles/resourcemanager.projectCreator）が必要です。ロールを付与する方法を確認する。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、 Google Cloud プロジェクトの名前に置き換えます。
Binary Authorization、Cloud Key Management Service、Google Kubernetes Engine、Artifact Registry API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限を含む Service Usage 管理者 IAM ロール（roles/serviceusage.serviceUsageAdmin）が必要です。ロールを付与する方法を確認する。gcloud services enable binaryauthorization.googleapis.com
cloudkms.googleapis.com container.googleapis.com artifactregistry.googleapis.com -
Google Cloud CLI をインストールします。
-
外部 ID プロバイダ（IdP）を使用している場合は、まず連携 ID を使用して gcloud CLI にログインする必要があります。
-
gcloud CLI を初期化するには、次のコマンドを実行します。
gcloud init -
Google Cloud プロジェクトを作成または選択します。
プロジェクトの選択または作成に必要なロール
- プロジェクトを選択する: プロジェクトの選択に特定の IAM ロールは必要ありません。ロールが付与されているプロジェクトであれば、どのプロジェクトでも選択できます。
-
プロジェクトを作成する: プロジェクトを作成するには、
resourcemanager.projects.create権限を含むプロジェクト作成者ロール（roles/resourcemanager.projectCreator）が必要です。ロールを付与する方法を確認する。
-
Google Cloud プロジェクトを作成します。
gcloud projects create PROJECT_ID
PROJECT_IDは、作成する Google Cloud プロジェクトの名前に置き換えます。 -
作成した Google Cloud プロジェクトを選択します。
gcloud config set project PROJECT_ID
PROJECT_IDは、 Google Cloud プロジェクトの名前に置き換えます。
Binary Authorization、Cloud Key Management Service、Google Kubernetes Engine、Artifact Registry API を有効にします。
API を有効にするために必要なロール
API を有効にするには、
serviceusage.services.enable権限を含む Service Usage 管理者 IAM ロール（roles/serviceusage.serviceUsageAdmin）が必要です。ロールを付与する方法を確認する。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 サービス エージェントに付与します。
クラスタ プロジェクトの 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 に置き換えます。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 サービス エージェントがリポジトリ内の署名にアクセスできるようにします。
ポリシー プロジェクトの 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 に置き換えます。ロールを付与します。
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: プロジェクト IDKMS_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}公開鍵の場所を記録します。
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: プロジェクト IDKMS_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}) EOFPOLICY_PATHは、ポリシー ファイルのパスに置き換えます。プラットフォーム ポリシーを作成します。
後述のコマンドデータを使用する前に、次のように置き換えます。
- POLICY_ID: 選択したプラットフォーム ポリシー ID。ポリシーが別のプロジェクトにある場合、完全なリソース名
projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_IDを使用できます。 - POLICY_PATH: ポリシー ファイルのパス。
- POLICY_PROJECT_ID: ポリシー プロジェクト ID。
次のコマンドを実行します。
Linux、macOS、Cloud Shell
gcloud beta container binauthz policy create POLICY_ID \ --platform=gke \ --policy-file=POLICY_PATH \ --project=POLICY_PROJECT_ID
Windows（PowerShell）
gcloud beta container binauthz policy create POLICY_ID ` --platform=gke ` --policy-file=POLICY_PATH ` --project=POLICY_PROJECT_ID
Windows（cmd.exe）
gcloud beta container binauthz policy create POLICY_ID ^ --platform=gke ^ --policy-file=POLICY_PATH ^ --project=POLICY_PROJECT_ID
- POLICY_ID: 選択したプラットフォーム ポリシー ID。ポリシーが別のプロジェクトにある場合、完全なリソース名
CV を有効にする
チェックベースのプラットフォーム ポリシーで CV モニタリングを使用するように、新しいクラスタを作成するか、既存のクラスタを更新します。
CV モニタリングを使用するクラスタを作成する
このセクションでは、チェックベースのプラットフォーム ポリシーで CV モニタリングのみを使用するクラスタを作成します。
後述のコマンドデータを使用する前に、次のように置き換えます。
CLUSTER_NAME: クラスタ名。LOCATION: ロケーション。例:us-central1、asia-south1POLICY_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-south1POLICY_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: ポリシーが保存されているプロジェクトの IDPOLICY_ID: ポリシー IDCLUSTER_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: ポリシーが保存されているプロジェクトの IDPOLICY_ID: ポリシー IDCLUSTER_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 コンソール
Google Cloud コンソールの [Artifact Registry] ページに移動します。
リポジトリ リストで、イメージを含むリポジトリの名前をクリックします。
署名したイメージの名前をクリックします。
署名を含むアイテムを探します。このアイテムには
sha256-[image digest].sigタグが付いています。タグ付きのアイテムは 1 つだけにしてください。[マニフェスト] をクリックします。
さまざまなフィールドを含む 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 の仕様をご覧ください。
コマンドライン
正しいアーティファクトを見つけます。
イメージとともに保存されているアイテムのリストを出力します。
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タグの付いたアーティファクトのマニフェスト内に署名が含まれます。マニフェストを取得する
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: リポジトリが含まれているプロジェクトの IDREPOSITORY_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}検証が成功した場合、コマンド出力に
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 に関連するログエントリを生成しません。
未署名のイメージをデプロイする
このセクションでは、未署名のイメージをデプロイします。
ポリシーでは証明書が必須になっていますが、このイメージには証明書がないため、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 はチェックを示します。各チェックの値は次のとおりです。
ImageFreshnessCheckSigstoreSignatureCheckSimpleSigningAttestationCheckSlsaCheckTrustedDirectoryCheckVulnerabilityCheck
サンプルログ
次の 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: ポリシーの IDPOLICY_PROJECT_ID: ポリシー プロジェクト ID
次のステップ
- イメージの鮮度チェックを使用する
- シンプルな署名証明書チェックを使用する
- Sigstore 署名チェックを使用する
- SLSA チェックを使用する
- 信頼できるディレクトリのチェックを使用する
- 脆弱性チェックを使用する
- CV ログを表示する