Cloud Run と Google Kubernetes Engine へのイメージのデプロイを保護する

このページでは、Cloud Build を使用して Cloud Run と Google Kubernetes Engine に対するイメージのデプロイを保護する方法について説明します。

Binary Authorization を構成して、ビルド証明書を確認し、Cloud Build によって生成されていないイメージのデプロイをブロックする方法を学習します。このプロセスにより、不正なソフトウェアをデプロイするリスクを軽減できます。

準備

  1. Enable the Cloud Build, Binary Authorization, and Artifact Registry APIs.

    Enable the APIs

  2. このガイドのコマンドラインの例を使用するには、Google Cloud SDK をインストールして構成します。

  3. プラットフォームに Binary Authorization を設定する。

Binary Authorization でデプロイを制御する

Binary Authorization ポリシーは、イメージのデプロイを制御する一連のルールです。ルールは、デジタル署名された証明書を要求するように構成できます。

Cloud Build は、ビルド時に証明書を生成して署名します。Binary Authorization では、built-by-cloud-build 認証者を使用して証明書を検証し、Cloud Build がビルドしたイメージのみをデプロイできます。

プロジェクトに built-by-cloud-build 認証者を作成するには、そのプロジェクトでビルドを実行します。

Cloud Build によってビルドされたイメージのみをデプロイできるようにするには、次の手順を行います。

Console

  1. Google Cloud コンソールで [Binary Authorization] ページに移動します。

    [Binary Authorization] に移動

  2. [Policy]（ポリシー）タブで [Edit Policy]（ポリシーを編集）をクリックします。

  3. [ポリシーの編集] ダイアログで、[次のアテスターによって検証されたイメージのみを許可します] を選択します。

  4. [認証者の追加] をクリックします。

  5. [認証者の追加] ダイアログ ボックスで、次の操作を行います。

    1. [プロジェクトと認証者の名前により追加] を選択し、次の手順を行います。
      1. [プロジェクト名] フィールドに、Cloud Build を実行するプロジェクトを入力します。
      2. [認証者の名前] をクリックして、built-by-cloud-build 認証者が表示されていることを確認します。
      3. [built-by-cloud-build] をクリックします。

    2. または、[認証者リソース ID により追加] を選択します。[認証者リソース ID] に、次のように入力します。

      projects/PROJECT_ID/attestors/built-by-cloud-build

      PROJECT_ID は、Cloud Build を実行するプロジェクトに置き換えます。

  6. [Add 1 attestor] をクリックします。

  7. [ポリシーを保存] をクリックします。

gcloud

  1. 次のコマンドを使用して、既存のポリシーをファイルにエクスポートします。

    gcloud container binauthz policy export > /tmp/policy.yaml

  2. ポリシー ファイルを編集します。

  3. 次のいずれかのルールを編集します。

    • defaultAdmissionRule
    • clusterAdmissionRules
    • istioServiceIdentityAdmissionRules
    • kubernetesServiceAccountAdmissionRules

  4. まだルールに requireAttestationsBy ブロックがない場合は、追加します。

  5. requireAttestationsBy ブロックに以下の行を追加します。

    projects/PROJECT_ID/attestors/built-by-cloud-build

    PROJECT_ID は、Cloud Build を実行するプロジェクトに置き換えます。

  6. ポリシー ファイルを保存します。

  7. ポリシー ファイルをインポートします。

    gcloud container binauthz policy import /tmp/policy.yaml

    built-by-cloud-build-attestor への参照を含むポリシー ファイルの例を次に示します。

    defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
    - projects/PROJECT_ID/attestors/built-by-cloud-build
name: projects/PROJECT_ID/policy

    PROJECT_ID は、Cloud Build を実行するプロジェクト ID に置き換えます。

ポリシーエラーは、GKE または Cloud Run の Binary Authorization ログメッセージで確認できます。

ドライラン モードを使用する

ドライラン モードでは、デプロイを実際にブロックすることなく、Binary Authorization でポリシーのコンプライアンスを確認します。なお、ポリシー遵守のステータス メッセージは、Cloud Logging に記録されます。これらのログを使用して、ブロッキング ポリシーが正常に動作しているかどうかを確認し、誤検出を特定できます。

ドライランを有効にするには、次の操作を行います。

Console

  1. Google Cloud コンソールで [Binary Authorization] ページに移動します。

    Binary Authorization に移動

  2. [ポリシーの編集] をクリックします。

  3. [デフォルトのルール] または [固有のルール] で、[ドライラン モード] を選択します。

  4. [ポリシーを保存] をクリックします。

gcloud

  1. Binary Authorization ポリシーを YAML ファイルにエクスポートします。

    gcloud container binauthz policy export  > /tmp/policy.yaml

  2. テキスト エディタで、enforcementMode を DRYRUN_AUDIT_LOG_ONLY に設定し、ファイルを保存します。

  3. ポリシーを更新するには、次のコマンドを実行してファイルをインポートします。

    gcloud container binauthz policy import /tmp/policy.yaml

ポリシーエラーは、GKE または Cloud Run の Binary Authorization ログメッセージで確認できます。

制限事項

  • Cloud Build と Binary Authorization は同じプロジェクト内に存在する必要があります。 デプロイ プラットフォームを別のプロジェクトで実行する場合は、マルチプロジェクト設定用の IAM ロールを構成し、Binary Authorization で built-by-cloud-build 認証者を追加する際に Cloud Build プロジェクトを参照します。

  • 明示的な docker push ビルドステップを使用して Artifact Registry にイメージを push する場合、Cloud Build は証明書を生成しません。docker build ビルドステップで images フィールドを使用して Artifact Registry に push してください。images の詳細については、Artifact Registry にイメージを保存するさまざまな方法をご覧ください。

  • ビルド パイプラインとデプロイ パイプラインには、別々のビルド構成ファイルを使用する必要があります。これは、Cloud Build がビルド パイプラインが正常に完了した後にのみ証明書を生成するためです。 次に Binary Authorization が、イメージをデプロイする前に証明書を確認します。

プライベート プール内の証明書を有効にする

デフォルトでは、Cloud Build はプライベート プール内のビルドの Binary Authorization 証明書を生成しません。証明書を生成するには、requestedVerifyOption: VERIFIED オプションをビルド構成ファイルに追加します。

steps:
- name: 'gcr.io/cloud-builders/docker'
  args: [ 'build', '-t', 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1', '.' ]
images:
- 'us-central1-docker.pkg.dev/$PROJECT_ID/quickstart-docker-repo/quickstart-image:tag1'
options:
  requestedVerifyOption: VERIFIED

requestedVerifyOption を追加すると、Cloud Build によってイメージの証明書の生成と来歴メタデータが有効になります。

認証者メタデータを確認する

認証者は、プロジェクトで初めてビルドを実行するときに作成されます。 認証者 ID の形式は projects/PROJECT_ID/attestors/built-by-cloud-build です。ここで、PROJECT_ID はプロジェクト ID です。

ビルド認証者メタデータは、次のコマンドを使用して確認できます。

curl -X GET -H "Content-Type: application/json" \
    -H "Authorization: Bearer $(gcloud auth print-access-token)" \
    https://binaryauthorization.googleapis.com/v1beta1/projects/PROJECT_ID/attestors/built-by-cloud-build

PROJECT_ID は、Cloud Build を実行するプロジェクトに置き換えます。

出力には、認証者と対応する公開鍵に関する情報が含まれます。例:

name": "projects/PROJECT_ID/attestors/built-by-cloud-build",
  "userOwnedDrydockNote": {
    "noteReference": "projects/PROJECT_ID/notes/built-by-cloud-build",
    "publicKeys": [
      {
        "id": "//cloudkms.googleapis.com/v1/projects/verified-builder/locations/asia/keyRings/attestor/cryptoKeys/builtByGCB/cryptoKeyVersions/1",
        "pkixPublicKey": {
          "publicKeyPem": "-----BEGIN PUBLIC KEY-----\nMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEMMvFxZLgIiWOLIXsaTkjTmOKcaK7\neIZrgpWHpHziTFGg8qyEI4S8O2/2wh1Eru7+sj0Sh1QxytN/KE5j3mTvYA==\n-----END PUBLIC KEY-----\n",
          "signatureAlgorithm": "ECDSA_P256_SHA256"
        }
      },
...
      }
    ],
    "delegationServiceAccountEmail": "service-942118413832@gcp-binaryauthorization.iam.gserviceaccount.com"
  },
  "updateTime": "2021-09-24T15:26:44.808914Z",
  "description": "Attestor autogenerated by build ID fab07092-30f4-4f70-caf7-4545cbc404d6"

次のステップ