マルチプロジェクト設定を構成する

このチュートリアルでは、マルチプロジェクト構成で Binary Authorization を使用する方法について説明します。より単純な単一プロジェクト構成については、Google Cloud CLI の使用を開始する（GKE）をご覧ください。

職掌分散を確立するため、マルチプロジェクト構成で Binary Authorization を設定できます。各プロジェクトの目的については、このチュートリアルで後ほど説明します。

目標

このチュートリアルでは、次のタスクを行います。

職掌分散をサポートするために、デプロイ（GKE）、認証者、証明書管理に異なるプロジェクトを設定します。
証明書を要求するように、Binary Authorization ポリシーのデフォルトのルールを構成します。
証明書に署名して後で検証するための鍵ペアを作成します。
Binary Authorization 施行者が証明書の検証に使用する認証者を作成します。
サンプルイメージに署名し、証明書を作成します。
サンプルイメージをデプロイしてポリシーをテストします。

Identity and Access Management（IAM）を使用して、各プロジェクトの適切なアクセス制御を構成する必要があります。

このチュートリアルで作成したリソースを VPC Service Controls で保護すると、セキュリティを強化できます。詳細については、VPC Service Controls による保護をご覧ください。

費用

このドキュメントでは、Google Cloud の次の課金対象のコンポーネントを使用します。

Artifact Registry または Container Registry
Binary Authorization
GKE
Container Registry
省略可: Cloud Key Management Service

料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを生成できます。新しい Google Cloud ユーザーは無料トライアルをご利用いただける場合があります。

始める前に

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 Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

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

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

gcloud CLI を初期化するには:

gcloud init

Google Cloud Console の [プロジェクトセレクタ] ページで、Google Cloud プロジェクトを選択または作成します。

プロジェクトセレクタに移動

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

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

gcloud CLI を初期化するには:

gcloud init

GKE を操作するために kubectl をインストールします。

デプロイ担当者プロジェクトを設定する

デプロイ担当者プロジェクトでは、イメージをデプロイする Google Kubernetes Engine（GKE）クラスタと、Binary Authorization がデプロイ時に適用する Binary Authorization ポリシーを管理します。環境の規模、複雑さ、その他の要件に応じて、複数のデプロイ担当者プロジェクトを使用できます。

デプロイ担当者プロジェクトを設定するには:

Google Cloud コンソールでプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。
Identity and Access Management に関する注: デプロイ担当者プロジェクトには GKE クラスタが含まれます。このプロジェクトの Identity and Access Management の構成にも、このことが反映されている必要があります。
Google Cloud プロジェクトと番号を格納する環境変数を設定します。
```
DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID
```
DEPLOYER_PROJECT_ID は、Google Cloud プロジェクト ID に置き換えます。
```
DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")
```

API を有効にします。

Container Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  containerregistry.googleapis.com\
  binaryauthorization.googleapis.com

Artifact Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

デプロイ担当者プロジェクトのサービスアカウント名を取得します。
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
サービスアカウント名は、後の手順で認証者に関連付けられた Artifact Analysis メモの権限を構成する際に使用します。

認証者プロジェクトを設定する

認証者プロジェクトには、イメージをデプロイする準備ができていることを確認できる認証者が保存されます。認証プロセスで信頼できる関係者に関する情報を一元的に保管する場所として単一の認証者プロジェクトを作成できます。この場合、認証者の ID を検証するために必要なセキュリティキーを一元管理し、これらの鍵を管理する関係者にのみアクセスを許可できます。

認証者プロジェクトを設定するには:

Google Cloud コンソールでプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。
Identity and Access Management に関する注: このプロジェクトには認証者が含まれているため、セキュリティ担当者にのみ書き込み権限を付与します。
プロジェクト ID と番号を格納する環境変数を設定します。
```
ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
```
ATTESTOR_PROJECT_ID は、認証者プロジェクト ID に置き換えます。
```
ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")
```

Artifact Analysis API と Binary Authorization API を有効にします。

gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

認証者プロジェクトのサービスアカウント名を取得します。
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
サービスアカウント名は、後の手順で認証者に関連付けられた Artifact Analysis メモの権限を構成する際に使用します。

証明書プロジェクトを設定する

証明書プロジェクトとは、イメージの検証で認証者が作成する証明書を保存するプロジェクトです。証明書プロジェクトを別に作成することで、ソフトウェアの準備状況に関する記述をより簡単に整理し、検査できます。

Google Cloud コンソールでプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。
Identity and Access Management に関する注: Binary Authorization に関するすべてのロールに、このプロジェクトの Artifact Analysis のメモとオカレンスに対する読み取り権限が付与されますが、書き込み権限が必要になるのは証明書マネージャーだけです。
プロジェクト名を格納する環境変数を設定します。
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
ATTESTATION_PROJECT_ID は、証明書プロジェクト ID に置き換えます。

Artifact Analysis API と Binary Authorization API を有効にします。

gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

クラスタを作成する

これで、デプロイ担当者プロジェクトに GKE クラスタを作成できます。このクラスタで、デプロイしたコンテナイメージを実行します。クラスタを作成するときに、--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE フラグを gcloud container clusters create コマンドに渡します。

クラスタを作成するには:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

ここでは、GKE ゾーン us-central1-a に test-cluster というクラスタを作成します。

kubectl のインストール用にローカルの kubeconfig ファイルも更新する必要があります。これにより、GKE でクラスタにアクセスするために必要な認証情報とエンドポイント情報が提供されます。

ローカル kubeconfig ファイルを更新するには:

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

認証者を作成する

認証者は、コンテナイメージをデプロイする前に必要なプロセスが完了したことを証明する責任者です。これは、人の場合もあれば、ビルド / テストシステムなどのマシンプロセス、または継続的インテグレーション（CI）とデプロイ（CD）のパイプラインの場合もあります。認証者は認証者プロジェクトに作成します。

認証者を作成するには、次のことを行います。

Artifact Analysis でメモを作成して、認証プロセスで使用される信頼できるメタデータを保存する
認証者プロジェクトで認証者を作成し、作成したメモを関連付ける
デプロイ担当者プロジェクトのサービスアカウントの IAM ロールバインディングを認証者に追加する
Artifact Analysis メモに権限を設定する

このチュートリアルでは、test-attestor という認証者と test-attestor-note という Container Analysis メモを使用しています。実際のシナリオでは、任意の数の認証者を指定できます。各認証者は、イメージの認証プロセスに参加する当事者を表します。

Artifact Analysis メモを作成する

認証者の名前と Artifact Analysis メモを格納する変数を設定します。
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
次のように置き換えます。
- test-attestor: 選択した認証者の名前。
- test-attestor-note: 選択した認証者のメモ名。

Container Analysis メモを記述する JSON ファイルを /tmp/note_payload.json に作成します。

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

HTTP リクエストを Artifact Analysis REST API に送信して、メモを作成します。

curl -X POST \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)"  \
    --data-binary @/tmp/note_payload.json  \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/?noteId=${NOTE_ID}"

メモが作成されたことを確認します。

curl \
-H "Authorization: Bearer $(gcloud auth print-access-token)" \
"https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"

認証者を作成する

これで認証者を作成できます。

Binary Authorization で認証者を作成します。

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors create ${ATTESTOR_NAME} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}

認証者が作成されたことを確認します。

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

作成した認証者は、以下で作成する PKIX 鍵ペアが関連付けられていないため、まだ使用できません。

デプロイ担当者プロジェクトの IAM ロールバインディングを追加する

デプロイ担当者プロジェクトの IAM ロールバインディングを認証者に追加する必要があります。これは、Binary Authorization がポリシーを評価して、関連する証明書にアクセスする権限があるかどうかを判定するときに使用されます。

IAM ロールバインディングを追加するには:

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Artifact Analysis メモに権限を設定する

また、デプロイ担当者プロジェクトと認証者プロジェクトの両方にアクセスできるように、作成した Artifact Analysis メモに権限を設定する必要があります。これを行うには、メモの IAM ポリシーを更新し、プロジェクトサービスアカウントに閲覧者のアクセス権を割り当てます。

メモに IAM ポリシーを設定するために必要な情報を含む JSON ファイルを生成します。

cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

作成したメモのサービスアカウントとリクエストされたアクセスロールを IAM ポリシーに追加します。

curl -X POST  \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    --data-binary @/tmp/iam_request.json \
    "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

PKIX 鍵を設定する

Binary Authorization では、暗号鍵を使用して認証者の ID を安全に確認します。これにより、確認済みの関係者だけがコンテナイメージの認証に参加できます。鍵ペアは、認証者が証明書のデジタル署名に使用する秘密鍵と、Binary Authorization サービスによって保存され、認証者に追加される公開鍵で構成されます。

このチュートリアルでは、鍵ペアの作成に推奨の楕円曲線デジタル署名アルゴリズム（ECDSA）を使用していますが、RSA 鍵または PGP 鍵で署名することもできます。署名アルゴリズムの詳細については、鍵の目的とアルゴリズムをご覧ください。

Cloud Key Management Service（Cloud KMS）によって生成され、保存された非対称鍵は PKIX に準拠しています。PKIX 鍵と Cloud KMS の使用方法については、CLI を使用した認証者の作成をご覧ください。

鍵ペアの生成

PKIX 鍵ペアは、署名者が証明書のデジタル署名に使用する公開鍵と、認証者に追加する公開鍵で構成されます。デプロイ時に、Binary Authorization はこの公開鍵を使用して秘密鍵で署名された証明書を検証します。

秘密鍵を生成します。

新しいローカル非対称 PKIX 鍵ペアを生成してファイルに保存するには:
PKIX（Cloud KMS）
このステップでは、Cloud Key Management Service で生成され、保存されている鍵を使用して認証を行う方法について説明します。
1. Cloud KMS で管理される鍵ペアに関する情報を格納する環境変数を設定します。
  
  すでに鍵ペアがある場合は、これらの環境変数を設定した後、次の手順をスキップできます。
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEY_LOCATION=KMS_KEY_LOCATION
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_VERSION=KMS_KEY_VERSION
```
  次のように置き換えます。
  - KMS_KEY_PROJECT_ID: 鍵が保存されているプロジェクトの ID
  - KMS_KEY_LOCATION: 鍵のロケーション
  - KMS_KEYRING_NAME: キーリングの名前
  - KMS_KEY_NAME: 鍵の名前
  - KMS_KEY_VERSION: 鍵のバージョン
2. （省略可）KMS 鍵を設定します。
  注: すでに KMS 鍵がある場合は、この手順をスキップできます。
  1. KMS 鍵を作成し、その鍵を認証者に保存します。この手順では、以下で使用する環境変数も設定します。
    
    鍵を作成して環境変数を設定するには:
    
    KMS_KEY_PROJECT_ID=${PROJECT_ID} KMS_KEYRING_NAME=my-binauthz-keyring KMS_KEY_NAME=my-binauthz-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
  2. KMS キーリングを作成します。
    
    gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
  3. 鍵を作成します。
    
    gcloud kms keys create ${KMS_KEY_NAME} \ --location ${KMS_KEY_LOCATION} \ --keyring ${KMS_KEYRING_NAME} \ --purpose ${KMS_KEY_PURPOSE} \ --default-algorithm ${KMS_KEY_ALGORITHM} \ --protection-level ${KMS_PROTECTION_LEVEL} \ --project ${KMS_KEY_PROJECT_ID}
    
    KMS 鍵の作成の詳細については、非対称鍵の作成をご覧ください。
3. 認証者に公開鍵を追加します。
```
gcloud --project="${ATTESTOR_PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"
```
PKIX（ローカル鍵）

警告: セキュリティリスクがあるため、ローカルで生成された鍵ペアを本番環境で使用することはおすすめしません。代わりに、Cloud Key Management Service の使用をおすすめします。この例は説明のみを目的としています。
1. 秘密鍵を生成するには、次のコマンドを実行します。
```
PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
```
  PRIVATE_KEY_FILE は、認証者に保存されている秘密鍵を含むファイルの名前です。
2. 秘密鍵から公開鍵を抽出し、ファイルに保存します。
```
PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
```
  PUBLIC_KEY_FILE は、認証者に保存されている公開鍵を含むファイルの名前です。
3. エクスポートした認証者に公開鍵を追加するには、次のコードを実行します。
```
gcloud --project="${ATTESTOR_PROJECT_ID}" \
  container binauthz attestors public-keys add \
  --attestor="${ATTESTOR_NAME}" \
  --pkix-public-key-file=${PUBLIC_KEY_FILE} \
  --pkix-public-key-algorithm=ecdsa-p256-sha256
```
  Binary Authorization は、認証者の公開鍵を使用して証明書を検証します。

ポリシーを構成する

これで、デプロイ担当者プロジェクトでポリシーを構成できます。この手順では、ポリシー YAML ファイルをローカルシステムにエクスポートし、上記で定義した認証者による証明書を要求するようにデフォルトルールを変更します。

ポリシーを構成するには:

Google 管理のシステムイメージを許可する新しいポリシーファイルを作成します。evaluationMode に REQUIRE_ATTESTATION を設定し、作成した認証者を参照するノードを requireAttestationsBy という名前で追加します。

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

ポリシー YAML ファイルを Binary Authorization にインポートします。

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

ポリシーの構成の詳細については、CLI を使用したポリシーの構成をご覧ください。

ポリシーのテスト

このチュートリアルでは、Container Registry と Artifact Registry から一般公開の「Hello World!」イメージなどの証明書を作成します。最初の段階では必要な証明書が存在しないため、施行者はイメージのデプロイをブロックします。

イメージをデプロイするには:

Container Registry

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

Artifact Registry

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0 --port 8080

次に、Binary Authorization でデプロイがブロックされたことを確認します。

kubectl get pods

このコマンドを実行すると、イメージがデプロイされなかったことを示す次のメッセージが出力されます。

No resources found.

次のコマンドによってデプロイの詳細を確認できます。

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

次のようなレスポンスが表示されます。

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by attestor ATTESTOR_NAME: No attestations found

この出力で:

POD_NAME: Pod の名前。
IMAGE_NAME: イメージの名前。
ATTESTOR_NAME: 認証者の名前。

デプロイを削除して次の手順に進みます。

kubectl delete deployment hello-server

証明書を作成する

証明書は、パイプラインで必要なプロセスが完了し、対象のコンテナイメージのデプロイが承認されていることを証明するものです。証明書自体は、コンテナイメージレジストリに保存されているイメージのバージョンのフルパスと、認証者の ID が記録された、デジタル署名付きレコードです。

このチュートリアルでは、イメージのデプロイが承認されていることのみを証明します。証明書プロジェクトで証明書を作成します。

証明書を作成するには:

イメージのレジストリパスとダイジェストを格納する変数を設定します。

Container Registry

IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"

Artifact Registry

IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

証明書を作成する

PKIX Cloud KMS

Cloud KMS 鍵を使用して証明書を作成するには、次のコマンドを実行します。

gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

PKIX（ローカル鍵）

ローカル鍵を使用して証明書を作成する手順は次のとおりです。

証明書ペイロードを生成します。

gcloud --project=${ATTESTATION_PROJECT_ID} \
  container binauthz create-signature-payload \
  --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

ペイロード JSON ファイルの内容は次のとおりです。

Container Registry

{
"critical": {
  "identity": {
    "docker-reference": "gcr.io/google-samples/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

Artifact Registry

{
"critical": {
  "identity": {
    "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
  },
  "type": "Google cloud binauthz container signature"
}
}

ペイロードに署名します。

ローカル PKIX ファイルを使用する場合は、ローカル PKIX 秘密鍵でペイロードに署名して署名ファイルを出力します。
```
openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
```
出力ファイルは、前の手順で作成したペイロード JSON ファイルの署名付きバージョンです。
認証者から公開鍵 ID を取得します。

公開鍵 ID は、gcloud container binauthz attestors describe ATTESTOR_NAME コマンドでいつでも確認できます。

公開鍵 ID を環境変数に格納するには、次のコマンドを入力します。
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
```

証明書を作成して検証します。

gcloud container binauthz attestations create \
  --project="${ATTESTATION_PROJECT_ID}" \
  --artifact-url="${IMAGE_TO_ATTEST}" \
  --attestor="projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
  --signature-file=/tmp/ec_signature \
  --public-key-id="${PUBLIC_KEY_ID}" \
  --validate

validate フラグは、ポリシーで構成した認証者が証明書を検証できることを確認します。

証明書が作成されたことを確認します。

gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_PROJECT_ID

証明書の作成の詳細については、証明書の作成をご覧ください。

ポリシーの再テスト

クラスタにサンプルコンテナイメージをデプロイして、ポリシーをテストします。今回は、Binary Authorization はイメージパスとダイジェストの両方を使用して証明書を検索するため、1.0 や latest などのタグではなく、ダイジェストを使用してイメージをデプロイする必要があります。ここでは、イメージに証明書が関連付けられているため、Binary Authorization によりイメージのデプロイが許可されます。

イメージをデプロイするには:

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

イメージがデプロイされたことを確認するには:

kubectl get pods

このコマンドを実行すると、デプロイが成功したことを示す次のようなメッセージが出力されます。

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

コンテナイメージが正常にデプロイされ、設定が機能していることを確認したら、GKE で作成したクラスタを削除できます。

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

GKE で作成したクラスタを削除します。

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

このチュートリアルで作成した Google Cloud プロジェクトを削除することもできます。

マルチプロジェクト設定を構成する

目標

費用

始める前に

デプロイ担当者プロジェクトを設定する

Container Registry

Artifact Registry

認証者プロジェクトを設定する

証明書プロジェクトを設定する

クラスタを作成する

認証者を作成する

Artifact Analysis メモを作成する

認証者を作成する

デプロイ担当者プロジェクトの IAM ロール バインディングを追加する

Artifact Analysis メモに権限を設定する

PKIX 鍵を設定する

鍵ペアの生成

PKIX（Cloud KMS）

PKIX（ローカル鍵）

ポリシーを構成する

ポリシーのテスト

Container Registry

Artifact Registry

証明書を作成する

Container Registry

Artifact Registry

PKIX Cloud KMS

PKIX（ローカル鍵）

Container Registry

Artifact Registry

ポリシーの再テスト

クリーンアップ

次のステップ

デプロイ担当者プロジェクトの IAM ロールバインディングを追加する