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
  • Container Registry
  • Cloud Build
  • Cloud Key Management Service(Cloud KMS)

目標

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

費用

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

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

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

始める前に

  1. Google アカウントにログインします。

    Google アカウントをまだお持ちでない場合は、新しいアカウントを登録します。

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

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

  3. Google Cloud プロジェクトに対して課金が有効になっていることを確認します。プロジェクトに対して課金が有効になっていることを確認する方法を学習する

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

    API を有効にする

  5. Cloud Console で、Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

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

  6. このチュートリアルのすべてのコマンドは Cloud Shell で実行されます。

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

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

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

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

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

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

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

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

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

  1. コンテナ イメージをアプリのソースコードでビルドします。

  2. コンテナ イメージを Container Registry に push します。

  3. Container Analysis は、既知のセキュリティの脆弱性または CVE についてコンテナ イメージをスキャンします。

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

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

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

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

環境設定

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

  1. Cloud Shell で、このチュートリアルで使用するすべてのリソースをデプロイおよび管理する Cloud プロジェクトを設定します。

    export PROJECT_ID="${DEVSHELL_PROJECT_ID}"
    
  2. これらのリソースをデプロイするリージョンを設定します。

    export REGION="us-central1"
    

    GKE クラスタと Cloud KMS 鍵はこのリージョンにあります。このチュートリアルでは、リージョンは us-central1 です。リージョンの詳細については、地域とリージョンをご覧ください。

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

    export PROJECT_NUMBER="$(gcloud projects describe "${PROJECT_ID}" \
      --format='value(projectNumber)')"
    
  4. Cloud Build サービス アカウントのメールアドレスを設定します。

    export CLOUD_BUILD_SA_EMAIL="${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com"
    

GKE クラスタの作成

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

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

    gcloud container clusters create "staging-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --enable-binauthz
    
  2. 本番環境の GKE クラスタを作成します。

    gcloud container clusters create "prod-cluster" \
      --project "${PROJECT_ID}" \
      --machine-type "n1-standard-1" \
      --region "${REGION}" \
      --num-nodes "1" \
      --enable-binauthz
    
  3. Cloud Build サービス アカウントに GKE にデプロイする権限を付与します。

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

署名鍵の作成

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

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

    gcloud kms keyrings create "binauthz" \
      --project "${PROJECT_ID}" \
      --location "${REGION}"
    
  2. 脆弱性スキャン証明書の署名と検証に使用する 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"
    
  3. 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 サービス アカウントに、メモの表示、メモの添付、および前の手順で作成した鍵を使用した認証者の作成を行う権限を付与します。

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

  1. 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
    
  2. Cloud Build サービス アカウントに、vulnz-note メモを表示したり、コンテナ イメージに添付したりする権限を付与します。

    curl "https://containeranalysis.googleapis.com/v1beta1/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
    
  3. 脆弱性スキャン認証者を作成します。

    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"
    
  4. 認証者の署名鍵の公開鍵を追加します。

    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}"
    
  5. 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.attestorsVerifier"
    
  6. 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 証明書を作成する

  1. 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
    
  2. Cloud Build サービス アカウントに、qa-note メモを表示したり、コンテナ イメージに添付したりする権限を付与します。

    curl "https://containeranalysis.googleapis.com/v1beta1/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
    
  3. 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"
    
  4. 認証者の署名鍵の公開鍵を追加します。

    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}"
    
  5. 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.attestorsVerifier"
    
  6. QA チームに証明書に署名する権限を付与します。

    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 ポリシーの設定

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

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

  • デフォルトの evaluationModeALWAYS_DENY に変更します。除外されたイメージ、または必要な証明書があるイメージのみがクラスタで実行できます。

  • globalPolicyEvaluationMode を有効にします。これにより、デフォルトのホワイトリストが Google 提供のシステム イメージのみを含むように変更されます。

  • 次のクラスタ アドミッション ルールを定義します。

    • staging-cluster には vulnz-attestor からの証明書が必要です。

    • prod-cluster には vulnz-attestorqa-attestor からの証明書が必要です。

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

  1. 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
    
  2. 新しいポリシーを Cloud プロジェクトにアップロードします。

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

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

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

  1. Cloud Shell で、Binary Authorization ツールとサンプル アプリケーション ソースのクローンを作成します。

    git clone https://github.com/GoogleCloudPlatform/gke-binary-auth-tools ~/binauthz-tools
    
  2. 脆弱性スキャン認証者の cloudbuild-attestor というコンテナをビルドして、Container Registry に push します。

    gcloud builds submit \
      --project "${PROJECT_ID}" \
      --tag "gcr.io/${PROJECT_ID}/cloudbuild-attestor" \
      ~/binauthz-tools
    
  3. 脆弱性スキャナ API を有効にします。

    gcloud services enable containerscanning.googleapis.com
    

Cloud Build パイプラインの設定

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

hello-app の Cloud Source Repositories を作成する

  1. Cloud Shell で、サンプルアプリの Cloud Source Repositories のリポジトリを作成します。

    gcloud source repos create hello-app \
      --project "${PROJECT_ID}"
    
  2. リポジトリのクローンをローカルに作成します。

    gcloud source repos clone hello-app ~/hello-app \
      --project "${PROJECT_ID}"
    
  3. サンプルコードをリポジトリにコピーします。

    cp -R ~/binauthz-tools/examples/hello-app/* ~/hello-app
    

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

  1. Cloud Console で、[トリガー] ページに移動します。

    [トリガー] に移動

  2. [トリガーを作成] をクリックします。

  3. [トリガー設定] ウィンドウに、次の詳細を入力します。

    • [リポジトリ] フィールドで、メニューから hello-app を選択します。
    • [名前] フィールドに「build-vulnz-deploy」と入力します。
    • [トリガーのタイプ] で [ブランチ] を選択します。
    • [ブランチ(正規表現)] フィールドに master と入力します。
    • [ビルド構成] で [Cloud Build 構成ファイル] を選択します。
    • [Cloud Build 構成ファイルの場所] に、デフォルト値 /cloudbuild.yaml を入力します。
  4. 次の代入変数のペアを追加します。

    • _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
  5. [トリガーを作成] をクリックします。

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

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

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

    cd ~/hello-app
    
    git add .
    git commit -m "Initial commit"
    git push origin master
    
  2. Cloud Console で [履歴] ページに移動します。

    [履歴] ページに移動

  3. ビルドの進捗状況を確認するには、Cloud Build の最新の実行をクリックします。

    ビルド情報

  4. staging-cluster へのデプロイが終了したら、[サービス] ページに移動します。

    [サービス] ページに移動

  5. アプリが機能していることを確認するには、アプリの [エンドポイント] リンクをクリックします。

  6. [イメージ] ページに移動します。

    [イメージ] ページに移動

  7. hello-app をクリックします。

  8. ステージング デプロイで検証したイメージをクリックします。

    検証されたイメージの名前。

  9. [ダイジェストの詳細] ページで、イメージの詳細から [ダイジェスト] の値をコピーします。この情報は次のステップで必要となります。

    イメージのダイジェストの値。

  10. 手動の 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 "gcr.io/${PROJECT_ID}/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}"
    
  11. アプリがデプロイされたことを確認するには、[サービス] ページに移動します。

    [サービス] ページに移動

  12. アプリを表示するには、エンドポイント リンクをクリックします。

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

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

  1. 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/FROM debian/g" Dockerfile
    
  2. 変更を commit して push します。

    git add .
    git commit -m "Change message and base image"
    git push origin master
    
  3. CI / CD パイプラインのステータスをモニタリングするには、Cloud Console の [履歴] ページに移動します。

    [履歴] ページに移動

    イメージに CVE が検出されたため、ビルドは失敗します。

  4. 検出された CVE を調べるには、[イメージ] ページに移動します。

    [イメージ] ページに移動

  5. hello-app をクリックします。

  6. 検出された CVE を確認するには、最新のイメージの脆弱性の概要をクリックします。

    最新のイメージの脆弱性の概要リンク。

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

    export SHA_DIGEST="[SHA_DIGEST_VALUE]"
    
    cd ~/hello-app
    sed "s/GOOGLE_CLOUD_PROJECT/${DEVSHELL_PROJECT_ID}/g" \
        kubernetes/deployment.yaml.tpl | sed -e  \
        "s/DIGEST/${SHA_DIGEST}/g" > kubernetes/deployment.yaml
    
    gcloud container clusters get-credentials \
        --project=${DEVSHELL_PROJECT_ID} \
        --zone=${COMPUTE_ZONE} prod-cluster
    
    kubectl apply -f kubernetes
    
  8. Cloud Console で、[ワークロード] ページに移動します。

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

    イメージの失敗ステータス。

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

ブレークグラスの手順

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

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

  1. Cloud Shell で、Kubernetes マニフェストのブレークグラス アノテーションのコメントを解除します。

    sed -i "31s/^#//" kubernetes/deployment.yaml
    
  2. kubectl を使用して変更を適用します。

    kubectl apply -f kubernetes
    
  3. 変更が prod-cluster にデプロイされたことを確認するには Cloud Console の [ワークロード] ページに移動します。

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

    デプロイのエラー メッセージが消えました。

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

    [サービス] ページに移動

  5. アプリを表示するには、エンドポイント リンクをクリックします。

クリーンアップ

このチュートリアルで使用したリソースについて、Google Cloud Platform アカウントに課金されないようにする手順は次のとおりです。

プロジェクトの削除

  1. Cloud Console で [リソースの管理] ページに移動します。

    [リソースの管理] ページに移動

  2. プロジェクト リストで、削除するプロジェクトを選択し、[削除] をクリックします。
  3. ダイアログでプロジェクト ID を入力し、[シャットダウン] をクリックしてプロジェクトを削除します。

次のステップ