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

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

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

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

1. Google Cloud コンソールでプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。

2. Identity and Access Management に関する注: デプロイ担当者プロジェクトには GKE クラスタが含まれます。このプロジェクトの Identity and Access Management の構成にも、このことが反映されている必要があります。

3. 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)")
   

4. 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
   

5. デプロイ担当者プロジェクトのサービス アカウント名を取得します。

   DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
   

   サービス アカウント名は、後の手順で認証者に関連付けられた Artifact Analysis メモの権限を構成する際に使用します。

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

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

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

1. Google Cloud コンソールでプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。

2. Identity and Access Management に関する注: このプロジェクトには認証者が含まれているため、セキュリティ担当者にのみ書き込み権限を付与します。

3. プロジェクト IDと番号を格納する環境変数を設定します。

   ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID
   

   ATTESTOR_PROJECT_ID は、認証者プロジェクト ID に置き換えます。

   ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
       --format="value(projectNumber)")
   

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

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

5. 認証者プロジェクトのサービス アカウント名を取得します。

   ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
   

   サービス アカウント名は、後の手順で認証者に関連付けられた Artifact Analysis メモの権限を構成する際に使用します。

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

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

1. Google Cloud Console でプロジェクトを作成し、課金を有効にします（まだ有効にしていない場合）。

2. Identity and Access Management に関する注: Binary Authorization に関するすべてのロールに、このプロジェクトの Artifact Analysis のメモとオカレンスに対する読み取り権限が付与されますが、書き込み権限が必要になるのは証明書マネージャーだけです。

3. プロジェクト名を格納する環境変数を設定します。

   ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
   

   ATTESTATION_PROJECT_ID は、証明書プロジェクト ID に置き換えます。

4. 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 メモを作成する

1. 認証者の名前と Artifact Analysis メモを格納する変数を設定します。

   ATTESTOR_NAME=test-attestor
   NOTE_ID=test-attestor-note
   

   以下のように置き換えます。

   • test-attestor: 選択した認証者の名前。
   • test-attestor-note: 選択した認証者のメモ名。

2. 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
   

3. 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}"
   

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

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

認証者を作成する

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

1. 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}
   

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

   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 ポリシーを更新し、プロジェクト サービス アカウントに閲覧者のアクセス権を割り当てます。

1. メモに 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
   

2. 作成したメモのサービス アカウントとリクエストされたアクセス ロールを 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 はこの公開鍵を使用して秘密鍵で署名された証明書を検証します。

1. 秘密鍵を生成します。

   新しいローカル非対称 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 鍵を設定します。

      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（ローカルキー）

   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 ファイルをローカル システムにエクスポートし、上記で定義した認証者による証明書を要求するようにデフォルト ルールを変更します。

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

1. 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
   

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

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

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

ポリシーのテスト

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

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

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

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 を含むデジタル署名付きのレコードです。

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

証明書を作成するには:

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

   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}
   

2. 証明書を作成する

   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（ローカルキー）

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

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

      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"
      }
      }
      

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

      ローカル PKIX ファイルを使用する場合は、ローカル PKIX 秘密鍵でペイロードに署名して署名ファイルを出力します。

      openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature
      

      出力ファイルは、前の手順で作成したペイロード JSON ファイルの署名付きバージョンです。

   3. 認証者から公開鍵 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})
      

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

      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 フラグは、ポリシーで構成した認証者が証明書を検証できることを確認します。

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

   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