このページでは、Binary Authorization の継続的検証(CV)の SLSA チェックの使用方法について説明します。このチェックでは、CV が有効な GKE クラスタで実行されている Pod のコンテナ イメージについて SLSA 準拠の来歴をチェックします。
このチェックを使用するには、SLSA 準拠の来歴を生成する Cloud Build でイメージをビルドする必要があります。
このガイドの例では、ソースコード リポジトリに Cloud Source Repositories、イメージ レジストリに Artifact Registry を使用し、イメージをビルドして来歴を生成します。
SLSA チェックがサポートする信頼できるビルダーは Cloud Build のみです。
費用
このガイドでは、次の Google Cloud サービスを使用します。
- Artifact Registry
- Binary Authorization。ただし、CV はプレビュー ステージの間は無料です。
- Cloud Build
- Cloud Source Repositories
- GKE
料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。
始める前に
- 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
-
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 プロジェクト名に置き換えます。
-
-
Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs:
gcloud services enable artifactregistry.googleapis.com
binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com - Install the Google Cloud CLI.
-
To initialize the gcloud CLI, run the following command:
gcloud init
-
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 プロジェクト名に置き換えます。
-
-
Enable the Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories APIs:
gcloud services enable artifactregistry.googleapis.com
binaryauthorization.googleapis.com cloudbuild.googleapis.com container.googleapis.com sourcerepo.googleapis.com - gcloud CLI が最新バージョンであることを確認します。
kubectl
コマンドライン ツールをインストールします。- Binary Authorization ポリシーと GKE クラスタが別々のプロジェクトにある場合は、両方のプロジェクトで Binary Authorization が有効になっていることを確認します。
必要なロール
このセクションでは、このチェックに必要なロールの設定方法について説明します。
概要
このガイドに記載されているプロダクトをすべて同じプロジェクトで実行する場合、権限を設定する必要はありません。Binary Authorization を有効にすると、ロールが正しく構成されます。複数のプロジェクトでプロダクトを実行する場合は、このセクションの説明に従ってロールを設定する必要があります。
各プロジェクトの Binary Authorization サービス エージェントに CV の SLSA チェックの評価に必要な権限を付与するには、各プロジェクトの Binary Authorization サービス エージェントに次の IAM ロールを付与するよう管理者に依頼します。
-
クラスタ プロジェクトの Compute Engine サービス アカウントに対する Artifact Registry 読み取り(
roles/artifactregistry.reader
) -
クラスタ プロジェクトがポリシー プロジェクトと異なる場合: ポリシー プロジェクトにアクセスするために、クラスタ プロジェクトの Binary Authorization サービス エージェントに Binary Authorization ポリシー評価者(
roles/binaryauthorization.policyEvaluator
)ロールが必要です。 - 証明書プロジェクトがポリシー プロジェクトと異なる場合: 証明書プロジェクトにアクセスするため、ポリシー プロジェクトの Binary Authorization サービス エージェントに Container Analysis のオカレンスの閲覧者(
roles/containeranalysis.occurrences.viewer
)ロールが必要です。
ロールの付与の詳細については、アクセス権の管理をご覧ください。
管理者は、カスタムロールや他の事前定義ロールを使用して、各プロジェクトの Binary Authorization サービス エージェントに必要な権限を割り当てることもできます。
gcloud CLI を使用してロールを付与する
各プロジェクトのサービス アカウントにこのチェックの評価に必要な権限を付与するには、各プロジェクトのサービス アカウントに次の 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 サービス エージェントを取得します。
PROJECT_NUMBER=$(gcloud projects list \ --filter="projectId:POLICY_PROJECT_ID" \ --format="value(PROJECT_NUMBER)") POLICY_PROJECT_SERVICE_ACCOUNT="service-$PROJECT_NUMBER@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
POLICY_PROJECT_ID
は、ポリシーを含むプロジェクトの ID に置き換えます。ロールを付与します。
gcloud projects add-iam-policy-binding ATTESTATION_PROJECT_ID \ --member="serviceAccount:$POLICY_PROJECT_SERVICE_ACCOUNT" \ --role='roles/containeranalysis.occurrences.viewer'
ATTESTATION_PROJECT_ID
は、証明書を含むプロジェクトの ID に置き換えます。
デフォルトの Compute Engine サービス アカウントに、リポジトリからイメージを pull することを許可します。
クラスタ プロジェクトに関連付けられた Compute Engine サービス アカウントを取得します。
PROJECT_NUMBER=$(gcloud projects list \ --filter="projectId:CLUSTER_PROJECT_ID" \ --format="value(PROJECT_NUMBER)") COMPUTE_ENGINE_SERVICE_ACCOUNT="$PROJECT_NUMBER-compute@developer.gserviceaccount.com"
CLUSTER_PROJECT_ID
は、ポリシーを含むクラスタ プロジェクトの ID に置き換えます。ロールを付与します。
gcloud projects add-iam-policy-binding ARTIFACT_PROJECT_ID \ --member="serviceAccount:$COMPUTE_ENGINE_SERVICE_ACCOUNT" \ --role='roles/artifactregistry.reader'
ARTIFACT_PROJECT_ID
は、デプロイするイメージを保存する Artifact Registry プロジェクトの ID に置き換えます。
省略可: サンプル イメージをビルドしてアップロードする
このセクションは、SLSA 準拠の来歴を使用してサンプル イメージを作成する方法を示すためのものです。来歴は、このガイドの後半でチェックについて説明する際に使用します。詳しくは、Cloud Build の来歴をご確認ください。
サンプル リポジトリを作成する
Cloud Source Repositories でリポジトリを作成する手順は次のとおりです。
リポジトリを作成してローカルでクローンを作成します。
gcloud source repos create SOURCE_REPO_NAME \ --project=SOURCE_REPO_PROJECT_ID && \ gcloud source repos clone SOURCE_REPO_NAME \ --project=SOURCE_REPO_PROJECT_ID && \ cd SOURCE_REPO_NAME
次のように置き換えます。
SOURCE_REPO_NAME
: ソースコード リポジトリの名前(例:slsa-check-test-repo
)SOURCE_REPO_PROJECT_ID
: リポジトリ プロジェクト ID
ソースファイル、構成ファイル、ビルドファイルを作成する手順は次のとおりです。
イメージソースを作成します。
cat > quickstart.sh <<EOF #!/bin/sh echo "Hello, world! The time is $(date)." sleep infinity EOF
ファイルを実行可能にします。
chmod +x quickstart.sh
Dockerfile 構成ファイルを作成します。
cat > Dockerfile <<EOF FROM alpine COPY quickstart.sh / CMD ["/quickstart.sh"] EOF
Cloud Build
cloudbuild.yaml
ファイルを作成します。このファイルは、Artifact Registry に push します。cat > cloudbuild.yaml <<EOF steps: - name: 'gcr.io/cloud-builders/docker' args: [ 'build', '-t', 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE', '.' ] options: requestedVerifyOption: VERIFIED images: - 'LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE' EOF
次のように置き換えます。
LOCATION
: Artifact Registry のロケーション(us-west2
、europe-central2
、asia-east1
など)ARTIFACT_PROJECT_ID
: Artifact Registry アーティファクトを保存するプロジェクトの IDARTIFACT_REPO_NAME
: Artifact Registry リポジトリ名(例:slsa-check-test-repo
)DIRECTORY
: ディレクトリ(例:slsa-check
)IMAGE
: イメージのパス(例:slsa-check-image
)
ファイルを Cloud Source Repositories に commit します。
git add . git commit -a
サンプル イメージをビルドしてアップロードする
このガイドでの作業を簡単にするため、SOURCE_REPO_PROJECT_ID と ARTIFACT_PROJECT_ID には同じプロジェクトを使用することをおすすめします。異なるプロジェクトを使用すると、追加の IAM 権限の設定が必要になる場合があります。Artifact Registry アクセス制御の詳細をご覧ください。Cloud Build の詳細については、Cloud Build の概要をご覧ください。
リポジトリを作成する方法は次のとおりです。
Artifact Registry リポジトリを作成します。
gcloud artifacts repositories create ARTIFACT_REPO_NAME \ --project=ARTIFACT_PROJECT_ID \ --repository-format=docker \ --location=LOCATION \ --description="Docker repository"
次のように置き換えます。
ARTIFACT_REPO_NAME
: リポジトリの名前ARTIFACT_PROJECT_ID
: アーティファクト プロジェクト IDLOCATION
: Artifact Registry のロケーション(us-west2
、europe-central2
、asia-east1
など)
Cloud Build ビルドトリガーを作成します。
gcloud beta builds triggers create cloud-source-repositories \ --project=SOURCE_REPO_PROJECT_ID \ --repo=SOURCE_REPO_NAME \ --region=LOCATION \ --branch-pattern=.* \ --build-config=cloudbuild.yaml
次のように置き換えます。
SOURCE_REPO_NAME
: ソースコード リポジトリ名SOURCE_REPO_PROJECT_ID
: Cloud Build プロジェクト IDLOCATION
: ロケーション
このガイドの前半で作成したファイルを push して、ビルドをトリガーします。
git push
イメージが正常にビルドされると、Cloud Build が来歴を生成し、イメージを Artifact Registry リポジトリにアップロードします。
最新のイメージを確認してダイジェストを取得するには、次の手順を行います。
Cloud Build でイメージがビルドされたことを確認します。
gcloud artifacts docker images list LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/REPO_NAME/DIRECTORY \ --project=ARTIFACT_PROJECT_ID \ --sort-by=create_time
次のように置き換えます。
LOCATION
: Artifact Registry のロケーションARTIFACT_PROJECT_ID
: アーティファクトのプロジェクト IDARTIFACT_REPO_NAME
: リポジトリ名DIRECTORY
: ディレクトリ
最新のイメージのダイジェストをコピーします。ダイジェストは
sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59
のようになります。
(省略可)イメージの来歴を表示します。
gcloud artifacts docker images describe \ LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST \ --project=ARTIFACT_PROJECT_ID \ --show-provenance
次のように置き換えます。
ARTIFACT_PROJECT_ID
: アーティファクトのプロジェクト IDLOCATION
: Artifact Registry のロケーションARTIFACT_REPO_NAME
: アーティファクト リポジトリ名DIRECTORY
: ディレクトリIMAGE
: イメージのパスDIGEST
: イメージに関連付けられたダイジェスト
コマンドの出力は次のようになります。
image_summary: digest: sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59 fully_qualified_digest: us-west2-docker.pkg.dev/my-project/slsa-check-repo/slsa-check-image@sha256:9432f747bd058b33de33bb5314d6eec1ac357d664e04c76824bb7072a9218d59 registry: us-west2-docker.pkg.dev repository: slsa-check-repo slsa_build_level: 3 provenance_summary: provenance: - build: intotoStatement: _type: https://in-toto.io/Statement/v0.1 predicateType: https://slsa.dev/provenance/v0.1 slsaProvenance: builder: id: https://cloudbuild.googleapis.com/GoogleHostedWorker materials: - digest: sha1: de4e4227fff1d00d6f7785a827608627e4a369ea uri: git+https://source.cloud.google.com/my-project/slsa-check-source-repo metadata: ... envelope: payload: eyJfdHlwZSI6I ... taW1hZ2U6dGFnMSJ9XX0= payloadType: application/vnd.in-toto+json signatures: - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/provenanceSigner/cryptoKeyVersions/1 sig: MEQCIBCCkho_re4EfAT-NBSSmAXOZlv4lU_vWzEru97tU8KmAiAKcAa99umWngzNQADmPixqYjbKjLOKQEUvrI5chSrf7g== - keyid: projects/verified-builder/locations/global/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1 sig: MEUCIFOEq_7RpiZAB4vUlit3hkZ2yI0n37-5Y87l0JbU-EZSAiEA9TNZZcv_MnzKffTnswHWZR2DSLmYiklr5twWfIec-zo=
SLSA チェックを実行するには、この出力に
provenance_summary
ブロックが含まれている必要があります。出力にブロックが含まれていない場合は、Cloud Build がビルドトリガーによって呼び出されていることを確認します。手動でトリガーされた場合、Cloud Build は来歴情報を生成しません。
プラットフォーム ポリシーを作成する
来歴を生成するには、サンプル イメージをビルドしてアップロードするで説明されているように、Cloud Build トリガーを使用してイメージをビルドする必要があります。
SLSA チェックを使用してプラットフォーム ポリシーを作成するには、次の操作を行います。
プラットフォーム ポリシーの YAML ファイルを作成します。
cat > POLICY_PATH <<EOF gkePolicy: checkSets: - checks: - displayName: My SLSA check imageAllowlist: # This policy exempts images that are in the following artifact registry allowPattern: - ARTIFACT_LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/EXEMPT_IMAGE_PATH/** slsaCheck: rules: - attestationSource: containerAnalysisAttestationProjects: - projects/ATTESTATION_PROJECT_ID configBasedBuildRequired: true trustedBuilder: GOOGLE_CLOUD_BUILD trustedSourceRepoPatterns: - source.cloud.google.com/SOURCE_REPO_PROJECT_ID/SOURCE_REPO_NAME customConstraints: - CEL_EXPRESSION displayName: My check set EOF
次のように置き換えます。
POLICY_PATH
: ポリシー ファイルのパス。ARTIFACT_LOCATION
: Artifact Registry 内のリポジトリの場所。ARTIFACT_PROJECT_ID
: アーティファクトを含むプロジェクトの ID。ARTIFACT_REPO_NAME
: イメージを含むリポジトリ。EXEMPT_IMAGE_PATH
: 1 つ以上の除外イメージへのパス(省略可)。例:not-built-by-cloud-build
imageAllowlist
ブロックは、このプラットフォーム ポリシーに含まれているため、来歴がないイメージがプラットフォーム ポリシーに違反しないように除外できます。これらのイメージからの違反をログに記録する場合は、このブロックを省略します。ATTESTATION_PROJECT_ID
: Cloud Build によって作成された証明書を保存するプロジェクト ID。SOURCE_REPO_PROJECT_ID
: ソースコードを含むプロジェクトの ID。SOURCE_REPO_NAME
: イメージを含むリポジトリ。ここでは、説明のため、このチェックに対する違反を強制的に発生させます。SOURCE_REPO_NAME
は、イメージが存在するソースコード リポジトリに設定します。POLICY_PROJECT_ID
: CV ポリシーを含むプロジェクトの ID。POLICY_ID
: このポリシーの ID。CEL_EXPRESSION
: SLSA ポリシーに追加の制約を提供する CEL 式。たとえば、イメージが特定のディレクトリ パスから取得されるようにカスタム制約を追加するには、CEL_EXPRESSION
を次の式に置き換えます。payload.predicate.externalParameters.buildConfigSource.path != "" && payload.predicate.externalParameters.buildConfigSource.repository.contains("github.com/my-repo/my-production-repo")
プラットフォーム ポリシーを作成します。
後述のコマンドデータを使用する前に、次のように置き換えます。
- 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-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
: ポリシーが保存されているプロジェクトの 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
イメージをデプロイする
kubectl
を構成します。gcloud container clusters get-credentials CLUSTER_NAME \ --location=LOCATION \ --project=CLUSTER_PROJECT_ID
次のように置き換えます。
CLUSTER_NAME
: クラスタの名前LOCATION
: クラスタのロケーションCLUSTER_PROJECT_ID
: クラスタ プロジェクト ID
Pod をデプロイします。
kubectl run hello-app \ --image='LOCATION-docker.pkg.dev/ARTIFACT_PROJECT_ID/ARTIFACT_REPO_NAME/DIRECTORY/IMAGE@DIGEST'
Pod がデプロイされました。来歴が確認され、信頼できるソースコード リポジトリからビルドされているため、このイメージは CV SLSA チェックに違反していません。このため、ログエントリは生成されていません。
SLSA チェックに強制的に違反させるには、イメージが存在する場所以外のソースコード レポジトリを
SOURCE_REPO_NAME
に設定します。ビルドを手動でトリガーすることで、来歴の生成をスキップできます。次に、ログエントリを確認します。
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
: ポリシーの IDPOLICY_PROJECT_ID
: ポリシー プロジェクト ID
次のステップ
- イメージの鮮度チェックを使用する
- シンプルな署名証明書チェックを使用する
- Sigstore 署名チェックを使用する
- SLSA チェックを使用する
- 信頼できるディレクトリのチェックを使用する
- 脆弱性チェックを使用する
- CV ログを表示する