SLSA チェックを使用する

このページでは、Binary Authorization の継続的検証（CV）の SLSA チェックの使用方法について説明します。このチェックでは、CV が有効になっている Google Kubernetes Engine（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.

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

gcloud CLI を初期化するには:

gcloud init

注: すでに gcloud CLI をインストールしている場合は、

gcloud components
      update

を実行して、最新バージョンがインストールされていることを確認してください。

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 プロジェクト名に置き換えます。

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

Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories API を有効にします。

gcloud services enable artifactregistry.googleapis.combinaryauthorization.googleapis.comcloudbuild.googleapis.comcontainer.googleapis.comsourcerepo.googleapis.com

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

gcloud CLI を初期化するには:

gcloud init

注: すでに gcloud CLI をインストールしている場合は、

gcloud components
      update

を実行して、最新バージョンがインストールされていることを確認してください。

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 プロジェクト名に置き換えます。

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

Artifact Registry, Binary Authorization, Cloud Build, GKE, Cloud Source Repositories API を有効にします。

gcloud services enable artifactregistry.googleapis.combinaryauthorization.googleapis.comcloudbuild.googleapis.comcontainer.googleapis.comsourcerepo.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 サービスエージェントに、ポリシープロジェクトのポリシーへのアクセスを許可する必要があります。
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 に置き換えます。
ポリシープロジェクトのサービスエージェントに証明書へのアクセスを許可します。
1. ポリシープロジェクトに関連付けられた 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 に置き換えます。
2. ロールを付与します。
```
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 することを許可します。
1. クラスタプロジェクトに関連付けられた 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 に置き換えます。
2. ロールを付与します。
```
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
ソースファイル、構成ファイル、ビルドファイルを作成する手順は次のとおりです。
1. イメージソースを作成します。
```
cat > quickstart.sh <<EOF
#!/bin/sh
echo "Hello, world! The time is $(date)."
sleep infinity
EOF
```
2. ファイルを実行可能にします。
```
chmod +x quickstart.sh
```
3. Dockerfile 構成ファイルを作成します。
```
cat > Dockerfile <<EOF
FROM alpine
COPY quickstart.sh /
CMD ["/quickstart.sh"]
EOF
```
4. 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 アーティファクトを保存するプロジェクトの ID
  - ARTIFACT_REPO_NAME: Artifact Registry リポジトリ名（例: slsa-check-test-repo）
  - DIRECTORY: ディレクトリ（例: slsa-check）
  - IMAGE: イメージのパス（例: slsa-check-image）
5. ファイルを 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: アーティファクトプロジェクト ID
- LOCATION: 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 プロジェクト ID
- LOCATION: ロケーション
このガイドの前半で作成したファイルを push して、ビルドをトリガーします。
```
git push
```
イメージが正常にビルドされると、Cloud Build が来歴を生成し、イメージを Artifact Registry リポジトリにアップロードします。
最新のイメージを確認してダイジェストを取得するには、次の手順を行います。
1. 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: アーティファクトのプロジェクト ID
  - ARTIFACT_REPO_NAME: リポジトリ名
  - DIRECTORY: ディレクトリ
2. 最新のイメージのダイジェストをコピーします。ダイジェストは 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: アーティファクトのプロジェクト ID
LOCATION: 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
    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-buildimageAllowlist ブロックは、このプラットフォームポリシーに含まれているため、来歴がないイメージがプラットフォームポリシーに違反しないように除外できます。これらのイメージからの違反をログに記録する場合は、このブロックを省略します。
- 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。
プラットフォームポリシーを作成します。

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

イメージをデプロイする

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 エントリのログを表示する

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

SLSA チェックを使用する

費用

始める前に

必要なロール

概要

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

省略可: サンプル イメージをビルドしてアップロードする

サンプル リポジトリを作成する

サンプル イメージをビルドしてアップロードする

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

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 エントリのログを表示する

チェックの種類

サンプルログ

クリーンアップ

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

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

ポリシーを削除する

次のステップ

省略可: サンプルイメージをビルドしてアップロードする

サンプルリポジトリを作成する

サンプルイメージをビルドしてアップロードする

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

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