マルチプロジェクト設定

このチュートリアルでは、マルチプロジェクト構成で Binary Authorization を使用する方法について説明します。 より単純な単一プロジェクトの構成については、コマンドライン ツールを使用したスタートガイドをご覧ください。

職掌分散を確立するには、マルチプロジェクト構成で Binary Authorization を設定します。各プロジェクトの目的については、このチュートリアルの後半で説明します。この構成では、コンテナ イメージをデプロイするために、個人がすべてのプロジェクトにアクセスする必要があります。

目標

このチュートリアルの内容は次のとおりです。

  1. 前述のロールごとに異なるプロジェクトを設定します。

  2. 証明書を要求するように、Binary Authorization ポリシーのデフォルトのルールを構成します。

  3. 証明書に署名して後で検証するための鍵ペアを作成します。

  4. Binary Authorization 施行者が証明書の検証に使用する認証者を作成します。

  5. サンプル イメージに署名し、証明書を作成します。

  6. サンプル イメージをデプロイしてポリシーをテストします。

各プロジェクトには、Identity and Access Management(IAM)による適切なアクセス制御が構成されます。

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

料金

このチュートリアルでは、Google Cloud の課金対象となるコンポーネントを使用します。詳細については、以下のリンク先にある各コンポーネントの料金ページをご覧ください。

また、料金計算ツールを使うと、予想使用量に基づいて費用の見積もりを出すことができます。

新しい Cloud Platform ユーザーは無料トライアルをご利用いただけます。

始める前に

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

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

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

  4. Cloud SDK をインストールして初期化します。
  5. GKE を操作するために kubectl をインストールします。

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

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

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

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

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

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

    DEPLOYER_PROJECT_ID=PROJECT_ID
    

    PROJECT_ID は、Google Cloud のプロジェクトの名前に置き換えます。

    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"
    

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

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

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

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

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

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

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

    ATTESTOR_PROJECT_ID=PROJECT_ID
    

    PROJECT_ID は Google Cloud プロジェクトの名前です。

    ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
        --format="value(projectNumber)")
    
  4. Container 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"
    

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

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

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

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

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

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

    ATTESTATION_PROJECT_ID=PROJECT_ID
    

    PROJECT_ID は Google Cloud プロジェクトの名前です。

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

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

クラスタを作成する

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

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

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

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

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

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

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

認証者を作成する

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

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

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

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

Container Analysis メモを作成する

  1. 認証者の名前と Container 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 リクエストを Container 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

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

また、デプロイ担当者プロジェクトと認証者プロジェクトの両方にアクセスできるように、作成した Container 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}'
            ]
          }
        ]
      }
    }
    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(ローカルキー)

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

      PRIVATE_KEY_FILE は、証明書ペイロードの署名に使用される秘密鍵を含むファイルの名前です。

      PRIVATE_KEY_FILE="/tmp/ec_private.pem"
      openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
      
    2. 秘密鍵から公開鍵を抽出し、ファイルに保存します。

      PUBLIC_KEY_FILE は、認証者に保存される公開鍵を含むファイルの名前です。

      PUBLIC_KEY_FILE="/tmp/ec_public.pem"
      openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
      
      1. 認証者にローカル公開鍵を追加する

      次に、エクスポートした公開鍵を認証者に追加して、Binary Authorization で本人確認に使用できるようにします。

      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
      

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

ポリシーを構成する

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

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

  1. Google 管理のシステム イメージを許可する新しいポリシー ファイルを作成します。evaluationModeREQUIRE_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!」イメージなどの証明書を作成します。最初に、必要な証明書が存在しないため、施行者はイメージのデプロイをブロックします。

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

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 "hello-server-579859fb5b-hjvnr" is forbidden: image policy webhook backend denied one or more images: Denied by default admission rule. Denied by Attestation Authority. Image gcr.io/google-samples/hello-app:1.0 denied by projects/example-project/attestors/test-attestor: No attestations found

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

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"
    
  2. 証明書ペイロードを生成します。

    gcloud --project=${ATTESTATION_PROJECT_ID} \
        container binauthz create-signature-payload \
        --artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /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"
      }
    }
    
  3. ペイロードに署名します。

    PKIX(ローカルキー)

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

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

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

    PKIX(Cloud Key Management Service)

    Cloud Key Management Service サービスを使用してペイロードに署名します。

      gcloud kms asymmetric-sign \
            --location=${KMS_KEY_LOCATION} \
            --keyring=${KMS_KEYRING_NAME} \
            --key=${KMS_KEY_NAME} \
            --version=${KMS_KEY_VERSION} \
            --digest-algorithm=sha256 \
            --input-file=/tmp/generated_payload.json \
            --signature-file=/tmp/ec_signature \
            --project ${KMS_KEY_PROJECT_ID}
    
  4. 認証者から公開鍵 ID を取得する

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

    公開鍵 ID を環境変数に格納するには、次のコマンドを入力します。

    PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
    --format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
    
  5. 証明するイメージの URL を作成します。

    IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}
    
  6. 証明書を作成して検証します。

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

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

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

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

ポリシーの再テスト

クラスタにサンプル コンテナ イメージをデプロイして、ポリシーをテストします。今回は、Binary Authorization はイメージパスとダイジェストの両方を使用して証明書を検索するため、1.0latest などのタグではなく、ダイジェストを使用してイメージをデプロイする必要があります。この場合、イメージには証明書が関連付けられているため、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 アカウントに課金されないようにするには、リソースを含むプロジェクトを削除するか、プロジェクトを維持して個々のリソースを削除します。

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

    gcloud container clusters delete \
        --zone=us-central1-a \
        test-cluster
    
  2. このチュートリアル用に作成した Google Cloud プロジェクトを削除することもできます。

次のステップ