Cloud Build と GKE を使用した Binary Authorization の実装

このチュートリアルでは、Google Kubernetes Engine（GKE）の Binary Authorization を設定、構成し、使用する方法について説明します。Binary Authorization は、コンテナイメージの証明書を作成するプロセスで、GKE にイメージがデプロイされる前に特定の基準が満たされていることを確認します。

たとえば、Binary Authorization では、アプリが単体テストに合格したかどうか、またはアプリが特定のシステムセットを使用して構築されたかどうかを確認できます。詳細とユースケースについては、Google Kubernetes Engine でのソフトウェアサプライチェーンの保護をご覧ください。

このチュートリアルは、コンテナの脆弱性スキャンと Binary Authorization、さらに CI / CD パイプラインでの実装と適用について理解を深めたい技術者を対象としています。

このチュートリアルは、次のトピックとテクノロジーを理解していることを前提としています。

継続的インテグレーションと継続的デプロイ
共通脆弱性識別子（CVE）の脆弱性スキャン
GKE
Artifact Registry
Cloud Build
Cloud Key Management Service（Cloud KMS）

目標

ステージングと本番環境用に GKE クラスタをデプロイする。
複数の認証者と証明書を作成する。
Cloud Build を使用して CI / CD パイプラインをデプロイする。
デプロイパイプラインをテストする。
ブレークグラスプロセスを開発する。

料金

このチュートリアルでは、課金対象である次の Google Cloud コンポーネントを使用します。

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

このチュートリアルを終了した後、作成したリソースを削除すると、それ以上の請求は発生しません。詳細については、クリーンアップをご覧ください。

始める前に

Google Cloud アカウントにログインします。Google Cloud を初めて使用する場合は、アカウントを作成して、実際のシナリオでの Google プロダクトのパフォーマンスを評価してください。新規のお客様には、ワークロードの実行、テスト、デプロイができる無料クレジット $300 分を差し上げます。

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

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

Cloud プロジェクトに対して課金が有効になっていることを確認します。詳しくは、プロジェクトで課金が有効になっているかどうかを確認する方法をご覧ください。

Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Container Analysis, Resource Manager, and Cloud Source Repositories API を有効にします。

API を有効にする

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

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

Binary Authorization, Cloud Build, Cloud KMS, GKE, Artifact Registry, Container Analysis, Resource Manager, and Cloud Source Repositories API を有効にします。

API を有効にする

Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。

CI / CD パイプラインのアーキテクチャ

ソフトウェア開発ライフサイクル（SDLC）の重要な側面は、アプリのデプロイが組織の承認済みのプロセスに従って実施されることです。これらのチェックとバランスを確立する 1 つの方法は、GKE で Binary Authorization を使用することです。まず、Binary Authorization がコンテナイメージにメモを添付します。次に、アプリをデプロイできるようになる前に GKE が必要なメモの存在を確認します。

これらのメモ、つまり証明書は、イメージについての説明です。証明書は完全に構成可能ですが、一般的な例は次のとおりです。

アプリが単体テストに合格した。
アプリが品質保証（QA）チームによって検証された。
アプリがスキャンされ、脆弱性が検出されなかった。

次の図は、既知の脆弱性がないことを確認して終了した脆弱性スキャンの後に、1 つの証明書が適用される SDLC を示しています。

1 つの証明書が適用された SDLC のアーキテクチャ。

このチュートリアルでは、Cloud Source Repositories、Cloud Build、Artifact Registry、GKE を使用して CI / CD パイプラインを作成します。次の図は、CI / CD パイプラインを示しています。

3 つの Google Cloud プロダクトを含む CI / CD パイプラインのアーキテクチャ

この CI / CD パイプラインは、次の手順で構成されます。

コンテナイメージをアプリのソースコードでビルドします。
コンテナイメージを Artifact Registry に push します。
Container Analysis は、既知のセキュリティの脆弱性または CVE についてコンテナイメージをスキャンします。

イメージに重大度スコアが 5 を超える CVE が含まれていない場合、そのイメージは重大な CVE がないことが証明され、自動的にステージングにデプロイされます。スコアが 5 を超えると、中程度から重大な脆弱性があることを示され、証明もデプロイもされません。

QA チームがステージングクラスタ内のアプリを検査します。要件を満たしていれば、コンテナイメージが本番環境にデプロイ可能な品質であることを示す手動の証明書を適用します。本番環境のマニフェストが更新され、アプリが本番環境用の GKE クラスタにデプロイされます。

GKE クラスタは、コンテナイメージを調べて証明書を確認し、必要な証明書がないデプロイを拒否するように構成されています。ステージング GKE クラスタには脆弱性スキャン証明書のみが必要ですが、本番環境の GKE クラスタには脆弱性スキャンと QA 証明書の両方が必要です。

このチュートリアルでは、CI / CD パイプラインに障害を発生させ、この違反措置をテストして検証します。最後に、緊急の場合、GKE にこれらのデプロイのチェックを回避するブレークグラスの手順を実装します。

環境設定

このチュートリアルでは、次の環境変数を使用します。これらの値は要件に合わせて変更できますが、このチュートリアルのすべての手順では、これらの環境変数が存在し、有効な値が含まれているものとします。

Cloud Shell で、このチュートリアルで使用するすべてのリソースをデプロイおよび管理する Cloud プロジェクトを設定します。
```
export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
gcloud config set project ${PROJECT_ID}
```
これらのリソースをデプロイするリージョンを設定します。
```
export REGION="us-central1"
```
GKE クラスタと Cloud KMS 鍵はこのリージョンにあります。このチュートリアルでは、リージョンは us-central1 です。リージョンの詳細については、地域とリージョンをご覧ください。

Cloud Build プロジェクト番号を設定します。

export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
  --format='value(projectNumber)')"

Cloud Build サービスアカウントのメールアドレスを設定します。
```
export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
```

GKE クラスタの作成

2 つの GKE クラスタを作成し、Cloud Build が GKE にアプリをデプロイするための Identity and Access Management（IAM）権限を付与します。GKE クラスタの作成には数分かかることがあります。

Cloud Shell で、ステージング用の GKE クラスタを作成します。

gcloud container clusters create "staging-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

本番環境の GKE クラスタを作成します。

gcloud container clusters create "prod-cluster" \
  --project "${PROJECT_ID}" \
  --machine-type "n1-standard-1" \
  --region "${REGION}" \
  --num-nodes "1" \
  --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

Cloud Build サービスアカウントに GKE にデプロイする権限を付与します。

gcloud projects add-iam-policy-binding "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/container.developer"

署名鍵の作成

証明書に署名するための Cloud KMS 非対称鍵を 2 つ作成します。

Cloud Shell で、binauthz という名前の Cloud KMS キーリングを作成します。

gcloud kms keyrings create "binauthz" \
  --project "${PROJECT_ID}" \
  --location "${REGION}"

脆弱性スキャン証明書の署名と検証に使用する vulnz-signer という名前の非対称 Cloud KMS 鍵を作成します。

gcloud kms keys create "vulnz-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

qa-signer という名前の非対称 Cloud KMS 鍵を作成し、QA 証明書に署名して検証します。

gcloud kms keys create "qa-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --purpose "asymmetric-signing" \
  --default-algorithm "rsa-sign-pkcs1-4096-sha512"

証明書の構成

コンテナイメージに添付するメモを作成し、Cloud Build サービスアカウントに、メモの表示、メモの添付、および前の手順で作成した鍵を使用した認証者の作成を行う権限を付与します。

脆弱性スキャナの証明書を作成する

Cloud Shell で、vulnz-note という名前の Container Analysis メモを作成します。

curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=vulnz-note" \
  --request "POST" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "name": "projects/${PROJECT_ID}/notes/vulnz-note",
      "attestation": {
        "hint": {
          "human_readable_name": "Vulnerability scan note"
        }
      }
    }
EOF

Cloud Build サービスアカウントに、vulnz-note メモを表示したり、コンテナイメージに添付したりする権限を付与します。

curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/vulnz-note:setIamPolicy" \
  --request POST \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "resource": "projects/${PROJECT_ID}/notes/vulnz-note",
      "policy": {
        "bindings": [
          {
            "role": "roles/containeranalysis.notes.occurrences.viewer",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          },
          {
            "role": "roles/containeranalysis.notes.attacher",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          }
        ]
      }
    }
EOF

脆弱性スキャン認証者を作成します。

gcloud container binauthz attestors create "vulnz-attestor" \
  --project "${PROJECT_ID}" \
  --attestation-authority-note-project "${PROJECT_ID}" \
  --attestation-authority-note "vulnz-note" \
  --description "Vulnerability scan attestor"

認証者の署名鍵の公開鍵を追加します。

gcloud beta container binauthz attestors public-keys add \
  --project "${PROJECT_ID}" \
  --attestor "vulnz-attestor" \
  --keyversion "1" \
  --keyversion-key "vulnz-signer" \
  --keyversion-keyring "binauthz" \
  --keyversion-location "${REGION}" \
  --keyversion-project "${PROJECT_ID}"

Cloud Build サービスアカウントに、vulnz-attestor によって作成された証明書を閲覧する権限を付与します。

gcloud container binauthz attestors add-iam-policy-binding "vulnz-attestor" \
  --project "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/binaryauthorization.attestorsViewer"

Cloud Build サービスアカウントに、vulnz-signer 鍵を使用してオブジェクトへ署名する権限を付与します。

gcloud kms keys add-iam-policy-binding "vulnz-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role 'roles/cloudkms.signerVerifier'

QA 証明書を作成する

Cloud Shell で、qa-note という名前の Container Analysis メモを作成します。

curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=qa-note" \
  --request "POST" \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "name": "projects/${PROJECT_ID}/notes/qa-note",
      "attestation": {
        "hint": {
          "human_readable_name": "QA note"
        }
      }
    }
EOF

Cloud Build サービスアカウントに、qa-note メモを表示したり、コンテナイメージに添付したりする権限を付与します。

curl "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/qa-note:setIamPolicy" \
  --request POST \
  --header "Content-Type: application/json" \
  --header "Authorization: Bearer $(gcloud auth print-access-token)" \
  --header "X-Goog-User-Project: ${PROJECT_ID}" \
  --data-binary @- <<EOF
    {
      "resource": "projects/${PROJECT_ID}/notes/qa-note",
      "policy": {
        "bindings": [
          {
            "role": "roles/containeranalysis.notes.occurrences.viewer",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          },
          {
            "role": "roles/containeranalysis.notes.attacher",
            "members": [
              "serviceAccount:${CLOUD_BUILD_SA_EMAIL}"
            ]
          }
        ]
      }
    }
EOF

QA 認証者を作成します。

gcloud container binauthz attestors create "qa-attestor" \
  --project "${PROJECT_ID}" \
  --attestation-authority-note-project "${PROJECT_ID}" \
  --attestation-authority-note "qa-note" \
  --description "QA attestor"

認証者の署名鍵の公開鍵を追加します。

gcloud beta container binauthz attestors public-keys add \
  --project "${PROJECT_ID}" \
  --attestor "qa-attestor" \
  --keyversion "1" \
  --keyversion-key "qa-signer" \
  --keyversion-keyring "binauthz" \
  --keyversion-location "${REGION}" \
  --keyversion-project "${PROJECT_ID}"

Cloud Build サービスアカウントに、qa-attestor によって作成された証明書を閲覧する権限を付与します。

gcloud container binauthz attestors add-iam-policy-binding "qa-attestor" \
  --project "${PROJECT_ID}" \
  --member "serviceAccount:${CLOUD_BUILD_SA_EMAIL}" \
  --role "roles/binaryauthorization.attestorsViewer"

QA チームに証明書に署名する権限を付与します。

注: この例では、グループまたはチームのエイリアスを使用して権限を付与しています。個々のユーザーを追加することもできます。テストするチームのエイリアスがない場合は、メンバーをメールアドレスに置き換えます。たとえば、user:you@example.com です。
```
gcloud kms keys add-iam-policy-binding "qa-signer" \
  --project "${PROJECT_ID}" \
  --location "${REGION}" \
  --keyring "binauthz" \
  --member "group:qa-team@example.com" \
  --role 'roles/cloudkms.signerVerifier'
```

Binary Authorization ポリシーの設定

--binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE で GKE クラスタを作成しても、バイナリがクラスタで実行するために必要な証明書を GKE に指示するポリシーを作成する必要があります。Binary Authorization ポリシーはプロジェクトレベルで存在しますが、クラスタレベルの構成が含まれています。

次のポリシーは、デフォルトのポリシーを次のように変更します。

デフォルトの evaluationMode を ALWAYS_DENY に変更します。除外されたイメージ、または必要な証明書があるイメージのみがクラスタで実行できます。
globalPolicyEvaluationMode を有効にします。これにより、デフォルトの許可リストが Google 提供のシステムイメージのみを含むように変更されます。
次のクラスタアドミッションルールを定義します。
- staging-cluster には vulnz-attestor からの証明書が必要です。
- prod-cluster には vulnz-attestor と qa-attestor からの証明書が必要です。

Binary Authorization ポリシーの詳細については、ポリシー YAML リファレンスをご覧ください。

Cloud Shell で、Cloud プロジェクトの Binary Authorization ポリシーを記述する YAML ファイルを作成します。

cat > ./binauthz-policy.yaml <<EOF
admissionWhitelistPatterns:
- namePattern: docker.io/istio/*
defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_DENY
globalPolicyEvaluationMode: ENABLE
clusterAdmissionRules:
  # Staging cluster
  ${REGION}.staging-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor

  # Production cluster
  ${REGION}.prod-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/${PROJECT_ID}/attestors/vulnz-attestor
    - projects/${PROJECT_ID}/attestors/qa-attestor
EOF

新しいポリシーを Cloud プロジェクトにアップロードします。

gcloud container binauthz policy import ./binauthz-policy.yaml \
  --project "${PROJECT_ID}"

脆弱性スキャンチェッカーの作成と API の有効化

Cloud Build でビルドステップとして使用されるコンテナイメージを作成します。このコンテナは、検出された脆弱性の重大度スコアを構成済みのしきい値と比較します。スコアがしきい値内の場合、Cloud Build はコンテナに証明書を作成します。スコアがしきい値を外れた場合、ビルドは失敗し、証明書は作成されません。

Cloud Shell で、認証者イメージを保存する新しい Artifact Registry リポジトリを作成します。
```
gcloud artifacts repositories create cloudbuild-helpers \
  --repository-format=DOCKER --location=${REGION}
```
Binary Authorization ツールとサンプルアプリケーションソースのクローンを作成します。
```
git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
```

脆弱性スキャン認証者の attestor というコンテナをビルドして、cloudbuild-helpers Artifact Registry に push します。

gcloud builds submit \
  --project "${PROJECT_ID}" \
  --tag "us-central1-docker.pkg.dev/${PROJECT_ID}/cloudbuild-helpers/attestor" \
  ~/binauthz-tools

Cloud Build パイプラインの設定

サンプルアプリと Kubernetes マニフェストの Cloud Source Repositories リポジトリと Cloud Build トリガーを作成します。

hello-app Cloud Source Repositories と Artifact Registry リポジトリを作成する

Cloud Shell で、サンプルアプリの Cloud Source Repositories のリポジトリを作成します。
```
gcloud source repos create hello-app \
  --project "${PROJECT_ID}"
```

リポジトリのクローンをローカルに作成します。

gcloud source repos clone hello-app ~/hello-app \
  --project "${PROJECT_ID}"

サンプルコードをリポジトリにコピーします。
```
cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
```
アプリケーションイメージを格納する新しい Artifact Registry リポジトリを作成します。
```
gcloud artifacts repositories create applications \
  --repository-format=DOCKER --location=${REGION}
```

hello-app の Cloud Build トリガーを作成する

Google Cloud コンソールの [トリガー] ページに移動します。

[トリガー] に移動
[リポジトリを管理] をクリックします。
hello-app リポジトリで、[...] をクリックし、[Add Trigger] を選択します。
[トリガー設定] ウィンドウに、次の詳細を入力します。
- [名前] フィールドに「build-vulnz-deploy」と入力します。
- [イベント] で [ブランチに push する] を選択します。
- [リポジトリ] フィールドで、メニューから hello-app を選択します。
- [ブランチ] フィールドに「master」と入力します。
- [構成] で [Cloud Build 構成ファイル（YAML または JSON）] を選択します。
- [ロケーション] で、[リポジトリ] を選択してデフォルト値 /cloudbuild.yaml を入力します。
次の代入変数のペアを追加します。
- _COMPUTE_REGION と値 us-central1（または最初に選択したリージョン）。
- _KMS_KEYRING と値 binauthz。
- _KMS_LOCATION と値 us-central1（または最初に選択したリージョン）。
- _PROD_CLUSTER と値 prod-cluster。
- _QA_ATTESTOR と値 qa-attestor。
- _QA_KMS_KEY と値 qa-signer。
- _QA_KMS_KEY_VERSION と値 1。
- _STAGING_CLUSTER と値 staging-cluster。
- _VULNZ_ATTESTOR と値 vulnz-attestor。
- _VULNZ_KMS_KEY と値 vulnz-signer。
- _VULNZ_KMS_KEY_VERSION と値 1。
[作成] をクリックします。

Cloud Build パイプラインをテストする

サンプルアプリを Cloud Source Repositories のリポジトリに commit して push し、CI / CD パイプラインをテストします。Cloud Build は変更を検出し、アプリをビルドして staging-cluster にデプロイします。パイプラインは QA 検証のために最大 10 分間待機します。QA チームによってデプロイが検証された後、プロセスは続行され、本番環境用 Kubernetes マニフェストが更新され、Cloud Build によってアプリが prod-cluster にデプロイされます。

Cloud Shell で、hello-app ファイルを Cloud Source Repositories リポジトリに commit して push し、ビルドをトリガーします。
```
cd ~/hello-app

git add .
git commit -m "Initial commit"
git push origin master
```
Google Cloud コンソールの [履歴] ページに移動します。

[履歴] ページに移動
ビルドの進捗状況を確認するには、Cloud Build の最新の実行をクリックします。
staging-cluster へのデプロイが終了したら、[サービス] ページに移動します。

[サービス] ページに移動
アプリが機能していることを確認するには、アプリの [エンドポイント] リンクをクリックします。
[リポジトリ] ページに移動します。

[イメージ] ページに移動
applications をクリックします。
hello-app をクリックします。
ステージングデプロイで検証したイメージをクリックします。
イメージの詳細から [ダイジェスト] の値をコピーします。この情報は次のステップで必要となります。

手動の QA 証明書を適用するために、... を、イメージの詳細からコピーした値に置き換えます。DIGEST 変数は sha256:hash-value の形式にします。

Await QA attestation ビルド手順では、以下に示すコピーペースト可能なコマンドも出力されます。

DIGEST="sha256:..." # Replace with your value

gcloud beta container binauthz attestations sign-and-create \
  --project "${PROJECT_ID}" \
  --artifact-url "${REGION}-docker.pkg.dev/${PROJECT_ID}/applications/hello-app@${DIGEST}" \
  --attestor "qa-attestor" \
  --attestor-project "${PROJECT_ID}" \
  --keyversion "1" \
  --keyversion-key "qa-signer" \
  --keyversion-location "${REGION}" \
  --keyversion-keyring "binauthz" \
  --keyversion-project "${PROJECT_ID}"

アプリがデプロイされたことを確認するには、[サービス] ページに移動します。

[サービス] ページに移動
アプリを表示するには、エンドポイントリンクをクリックします。

未検証のイメージのデプロイ

これまでのところ、サンプルアプリに脆弱性はありません。アプリを更新して別のメッセージを出力し、ベースイメージを変更します。

Cloud Shell で、出力を Hello World から Binary Authorization に変更し、ベースイメージを distroless から debian に変更します。

cd ~/hello-app
sed -i "s/Hello World/Binary Authorization/g" main.go
sed -i "s/FROM gcr\.io\/distroless\/static-debian11/FROM debian/g" Dockerfile

変更を commit して push します。

git add .
git commit -m "Change message and base image"
git push origin master

CI / CD パイプラインのステータスをモニタリングするには、Google Cloud コンソールの [履歴] ページに移動します。

[履歴] ページに移動

イメージに CVE が検出されたため、ビルドは失敗します。
検出された CVE を調べるには、[イメージ] ページに移動します。

[イメージ] ページに移動
hello-app をクリックします。
検出された CVE を確認するには、最新のイメージの脆弱性の概要をクリックします。

Cloud Shell で、脆弱性スキャンによる証明書がない新しいイメージを本番環境にデプロイしてみます。

export SHA_DIGEST="[SHA_DIGEST_VALUE]"

cd ~/hello-app
sed "s/REGION/${REGION}/g" kubernetes/deployment.yaml.tpl | \
    sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" | \
    sed -e "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml

gcloud container clusters get-credentials \
    --project=${PROJECT_ID} \
    --region="${REGION}" prod-cluster

kubectl apply -f kubernetes

Google Cloud コンソールの [ワークロード] ページに移動します。

[ワークロード] ページに移動

イメージに vulnz-attestor と qa-attestor の署名がないため、デプロイに失敗しました。

ブレークグラスの手順

場合によっては、通常のワークフローの範囲外の変更を許可する必要があります。必要な証明書がないイメージのデプロイを許可するために、ポッド定義には、ブレークグラスポリシーフラグによるアノテーションが付けられています。このフラグを有効にすると、GKE は引き続き必要な証明書を確認しますが、コンテナイメージのデプロイが許可され、違反が記録されます。

証明書チェックの回避の詳細については、ポリシーをオーバーライドするをご覧ください。

Cloud Shell で、Kubernetes マニフェストのブレークグラスアノテーションのコメントを解除します。
```
sed -i "31s/^#//" kubernetes/deployment.yaml
```
kubectl を使用して変更を適用します。
```
kubectl apply -f kubernetes
```
変更が prod-cluster にデプロイされたことを確認するには、Google Cloud コンソールの [ワークロード] ページに移動します。

[ワークロード] ページに移動

デプロイのエラーメッセージが消えました。
アプリがデプロイされたことを確認するには、[サービス] ページに移動します。

[サービス] ページに移動
アプリを表示するには、エンドポイントリンクをクリックします。

クリーンアップ

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

プロジェクトの削除

Google Cloud コンソールで、[リソースの管理] ページに移動します。
[リソースの管理] に移動
プロジェクトリストで、削除するプロジェクトを選択し、[削除] をクリックします。
ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ

コンテナ構築のおすすめの方法
コンテナ化されたウェブアプリケーションのデプロイ
Cloud Build を使用した GitOps スタイルの継続的デリバリー
マネージドベースイメージ
Google Cloud に関するリファレンスアーキテクチャ、図、ベストプラクティスを確認する。Cloud Architecture Center をご覧ください。

Cloud Build と GKE を使用した Binary Authorization の実装

目標

料金

始める前に

CI / CD パイプラインのアーキテクチャ

環境設定

GKE クラスタの作成

署名鍵の作成

証明書の構成

脆弱性スキャナの証明書を作成する

QA 証明書を作成する

Binary Authorization ポリシーの設定

脆弱性スキャン チェッカーの作成と API の有効化

Cloud Build パイプラインの設定

hello-app Cloud Source Repositories と Artifact Registry リポジトリを作成する

hello-app の Cloud Build トリガーを作成する

Cloud Build パイプラインをテストする

未検証のイメージのデプロイ

ブレークグラスの手順

クリーンアップ

プロジェクトの削除

次のステップ

脆弱性スキャンチェッカーの作成と API の有効化