継続的検証の概要

継続的検証（CV）は、Binary Authorization の機能で、Google Kubernetes Engine（GKE）で実行される Pod をモニタリングして、関連付けられたコンテナ イメージが、指された Binary Authorization チェックベースのプラットフォーム ポリシーに引き続き準拠していることを確認します。

CV は、Pod がプラットフォーム ポリシーに違反していると判断すると、違反を Cloud Logging に記録します。

プラットフォーム ポリシーの CV は、以前の継続的検証よりも優先されます。

CV を利用する理由

Binary Authorization の適用では、コンテナ イメージをデプロイするときに 1 回だけイメージの検証を行いますが、CV は、実行中の Pod に関連付けられたイメージがポリシーを遵守しているかどうかを継続的にモニタリングします。

このため、チェックベースのポリシーで Binary Authorization の適用と CV の両方を有効にすると、オーケストレーションのライフサイクル全体でポリシーの適合性が保証されます。

CV は次のような場合に役立ちます。

  • ポリシーの変更: Binary Authorization プロジェクト シングルトン適用ポリシーを更新すると、Binary Authorization は更新後にデプロイされたイメージのみを検証します。すでに実行中の Pod は影響を受けません。Binary Authorization が、更新されたポリシーを使用して、同じイメージのデプロイをブロックするようにしても、それらは引き続き実行されます。

    このため、Binary Authorization プロジェクト シングルトン ポリシーを更新する場合は、プロジェクト シングルトン ポリシーに一致するように CV プラットフォームのポリシーも作成または更新することをおすすめします。これにより、CV は、更新されたポリシーに違反する Pod の実行を通知します。

  • イメージ メタデータのモニタリング: CV は、イメージ メタデータの変更に対して次のようなチェックを行います。

    • 証明書: Pod イメージの証明書が有効でなくなると、CV が記録します。
    • 鮮度: Pod のイメージが最新でないことが検出されると、CV が記録します。
    • 来歴: CV は、信頼できるソース リポジトリにあるビルド構成を使用して、信頼できるビルダーで Pod のイメージがビルドされたことをチェックします。
    • 信頼できるディレクトリ: Pod イメージが、プラットフォーム ポリシーで指定されていないリポジトリ ディレクトリにある場合に、CV が記録します。
    • 脆弱性: Pod のイメージで脆弱性が確認された場合に、CV が記録します。

  • ドライランのモニタリング: ドライランを有効にすると、Binary Authorization はすべてのイメージのデプロイを許可します。プロジェクト シングルトン ポリシーに一致するプラットフォーム ポリシーで CV を有効にすると、CV はプラットフォーム ポリシーに違反するイメージを定期的に記録します。

  • ブレークグラス モニタリング: ブレークグラスを使用して Pod をデプロイすると、Binary Authorization は、プロジェクトのシングルトン ポリシーの適用を回避し、1 つのイベントを Cloud Audit Logs に記録します。ただし、CV は、一致するプラットフォーム ポリシーを使用して、ポリシー違反の Pod（ブレークグラスを使用してデプロイされた Pod を含む）を定期的に記録します。

CV の仕組み

CV を使用するには、GKE クラスタでそれを有効にする必要があります。

クラスタにイメージをデプロイすると、CV は関連する Pod をモニタリングし、チェックベースのプラットフォーム ポリシーに準拠していることを確認します。

CV は、除外イメージで指定されたイメージのタグをサポートしていません。

実行中の Pod の定期的なレビュー

実行中の Pod をモニタリングするため、CV は各 Pod に関連付けられたイメージを少なくとも 24 時間ごとに確認します。CV は init コンテナもモニタリングします。

CV は、レビューごとに各 Pod に関連付けられているイメージのリストを取得します。その後、イメージ情報がプラットフォーム ポリシーに準拠していることを確認します。

プラットフォーム ポリシー違反の記録

CV は、イメージがプラットフォーム ポリシーに違反していると判断すると、違反とその他の検出結果を Cloud Logging に記録します。

CV がプラットフォーム ポリシーを使用して Pod のイメージを評価したときに、イメージが一部のチェック条件を満たし、他のチェックに違反している場合があります。Pod のイメージがチェックに違反するたびに、CV はログエントリを生成します。

すべてのイメージがすべてのチェック条件を満たした場合、ログエントリは生成されません。

ポリシーに準拠していないイメージを含む Pod が終了するまで、CV はポリシー違反を記録し続けます。ポリシーに違反していて、チェックの間隔中に終了した Pod は次の CV レビューで記録されます。

CV は実行中の Pod を終了しません。

フィード リソースの使用

GKE クラスタで実行されている Pod に関する情報を取得するため、CV は binauthz-cv-cai-feed というフィード リソースを作成します。

CV プラットフォーム ポリシー

CV を使用するには、まずプラットフォーム ポリシーを構成します。

プラットフォーム ポリシーは、以前の Binary Authorization ポリシー（プロジェクト シングルトン ポリシー）と異なります。以前のプロジェクト シングルトン ポリシーはデプロイ プロジェクトに 1 つしか構成できませんが、複数のプラットフォーム ポリシーを構成できます。各プラットフォーム ポリシーは 1 つ以上のプロジェクトに配置できます。

プラットフォーム ポリシーは CV でのみ機能し、Binary Authorization の適用をサポートしていません。このため、Binary Authorization の適用と CV モニタリングの両方を使用する場合は、適用に使用するプロジェクト シングルトン ポリシーとモニタリングに使用するプラットフォーム ポリシーを作成することをおすすめします。

たとえば、イメージのデプロイを許可する前に証明書が存在することを求める Binary Authorization を構成するとします。また、実行中の Pod が同じ要件を満たすようにします。これを行うには、認証者を使用して、プロジェクト シングルトン適用ポリシーを構成します。次に、認証者と同じメモと公開鍵に基づく認証システムが設定されたシンプルな署名証明書チェックを含むプラットフォーム ポリシーを作成します。

プラットフォーム ポリシーはプラットフォーム固有です。サポートされているプラットフォームは GKE のみです。

プラットフォーム ポリシーでチェックを構成できます。チェックは、1 つ以上のチェックセットにグループ化されます。チェックセットごとに 1 つ以上のチェックを指定できます。

プラットフォーム ポリシーでは、CV による評価からイメージを除外できます。

必要な権限

プラットフォーム ポリシーの一覧表示または説明の取得を行うには、binaryauthorization.policyViewer ロールが必要です。プラットフォーム ポリシーを作成、変更、削除するには、binaryauthorization.policyEditor ロールが必要です。詳細については、プラットフォーム ポリシーを管理するをご覧ください。

ポリシーの更新

プラットフォーム ポリシーを更新すると、YAML ファイルに指定したポリシー記述子で既存のポリシーが上書きされます。既存のプラットフォーム ポリシーに新しいチェックを追加するには、既存のポリシーの説明を取得して YAML ファイルに保存し、新しいチェックを追加してから、更新されたファイルでポリシーを更新します。

複数のプラットフォーム ポリシー

プラットフォーム ポリシーは、クラスタと同じプロジェクト（ローカル プラットフォーム ポリシー）または任意のプロジェクトに作成できます。

複数のプラットフォーム ポリシーを構成できるため、それぞれに一意のリソース名で名前を付けます。gcloud CLI コマンドを実行する場合、ID を使用してローカル プラットフォーム ポリシーを参照します。別のプロジェクトのプラットフォーム ポリシーを参照する場合は、projects/POLICY_PROJECT_ID/platforms/gke/policies/POLICY_ID の形式でリソース名を使用します。

ローカル プラットフォーム ポリシーか、異なるプロジェクトのポリシーかにかかわらず、各 GKE クラスタに関連付けるプラットフォーム ポリシーを選択できます。

プラットフォーム ポリシーごとの複数のチェック

プラットフォーム ポリシーに複数のチェックを構成するには、それらをポリシーの checks ブロックに追加します。構成可能なチェックの詳細については、チェックをご覧ください。

CV プラットフォーム ポリシーで複数のチェックを指定した場合、1 つのチェックで評価されたイメージは、他のチェックでも引き続き評価されます。

イメージが除外イメージの許可リストパターンと一致する場合を除き、Binary Authorization は、各イメージのプラットフォーム ポリシーで構成されているすべてのチェックを評価します。詳細については、除外イメージをご覧ください。

単一プロジェクト設定

CV は単一のプロジェクトに設定できます。

単一プロジェクト設定では、Binary Authorization は Binary Authorization サービス エージェントに必要なロールを自動的に設定します。

GKE クラスタ、クラスタにバインドされたプラットフォーム ポリシー、チェックで必要なメタデータがすべて同じプロジェクトにある場合、追加の Identity and Access Management（IAM）ロールは必要ありません。

セキュリティを追加するためのマルチプロジェクト設定の構成については、懸念事項の分離をご覧ください。

マルチプロジェクト設定

プラットフォーム ポリシーでマルチプロジェクトの CV を構成する場合、プラットフォーム ポリシー、イメージ、GKE クラスタ、その他の種類の CV 依存リソースがそれぞれ異なるプロジェクトに存在する可能性があります。

マルチプロジェクト設定では、各プロジェクトの目的と CV がアクセスする必要のあるリソースを把握し、それに応じて必要な IAM のロールと権限を設定することが重要です。

CV の使用方法

CV を使用するには、通常、次のようにします。

  1. 使用するチェックを決めます。
  2. ポリシー YAML ファイルを使用して、1 つ以上のプラットフォーム ポリシーを作成します。このファイルに、使用するチェックを指定します。
  3. プラットフォーム ポリシーを作成します。ポリシーは、任意のプロジェクトに格納できます。
  4. プラットフォーム ポリシーを使用するには、新しいクラスタまたは既存のクラスタで Binary Authorization と CV を有効にします。
  5. Logging の CV ログでイベントを確認します。
  6. ログを確認し、チェック要件を満たすイメージを生成するように、ビルドなどのプロセスを更新します。

チェック

このセクションでは、CV が提供する特定のチェックについて説明します。

チェックベースのポリシーの形式は次のとおりです。

gkePolicy:
  checkSets:
  - checks:
    - CHECK_TYPE1:
        CHECK_TYPE1_PARAMETERS
      displayName: CHECK_TYPE1_DISPLAY_NAME
    - CHECK_TYPE2:
        CHECK_TYPE2_PARAMETERS
      displayName: CHECK_TYPE2_DISPLAY_NAME
    displayName: CHECK_SET_DISPLAY_NAME

checks と checkSets の displayName フィールドは省略可能です。これは、CV がポリシー違反を記録する場合にのみ使用されます。このガイドの後半で説明する一部の例では省略しています。

「常に拒否」チェック

「常に拒否」チェックでは、このチェックの対象となるすべてのイメージの評価が失敗します。CV が実行中の Pod に対してこのチェックを行うたびに、各 Pod のログエントリが生成されます。

「常に拒否」チェックを許可リストまたは複数のチェックセットと組み合わせて使用すると、特定の場合に Binary Authorization が Pod のログを常に生成するように設定できます。

「常に拒否」チェックを使用するには、次のように checks ブロックに alwaysDeny: true を追加します。

gkePolicy:
  checkSets:
    - displayName: "My check set"
      checks:
        - alwaysDeny: true

alwaysDeny の値は false に設定できません。代わりに、チェックを削除してください。

「常に拒否」チェックの使用例については、複数のチェックセットを使用するをご覧ください。

イメージの鮮度チェック

イメージの鮮度チェックでは、イメージの実行期間を計算し、その期間がしきい値 maxUploadAgeDays を超えた場合にログに記録します。

次のプラットフォーム ポリシーの YAML の例では、リポジトリにアップロードされ、30 日以上前にデプロイされたイメージを実行している Pod が記録されます。

gkePolicy:
  checkSets:
    checks:
    - imageFreshnessCheck:
        maxUploadAgeDays: 30
      displayName: "My image freshness check"
    displayName: "My check set"

シンプルな署名証明書チェック

CV のシンプルな署名証明書チェックでは、各 Pod のイメージに有効な署名付き証明書があることを確認します。

このチェックは、Binary Authorization 適用ポリシーの証明書の評価と同じです。このチェックには、認証者に使用したメモと鍵を構成できます。以前の継続的検証ではなく、このチェックを使用することをおすすめします。

シンプルな署名証明書チェックを含むプラットフォーム ポリシーの例を次に示します。

gkePolicy:
  checkSets:
    checks:
      simpleSigningAttestationCheck:
        containerAnalysisAttestationProjects:
        - "projects/my-attestation-project1"
        - "projects/my-attestation-project2"
        attestationAuthenticators:
          pkixPublicKeySet:
            pkixPublicKeys:
              publicKeyPem: |
                -----BEGIN PUBLIC KEY-----
                MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQxXxgAEvgQuW1FHYZPB2PTQfOJKUkS9sjMO/1os10xOWrhl1kQo4EnzMOovROWVLo+m9mcwp7nRQ2qQDThZdSFi0nFJ1A==
                -----END PUBLIC KEY-----
              signatureAlgorithm: ECDSA_P256_SHA256

CV 証明書チェックには、Binary Authorization 認証者ではなく、認証システムが設定されています。認証者は、ポリシーの attestationAuthenticators ブロックに直接指定します。

プラットフォーム ポリシーの simpleSigningAttestationCheck には、pkixPublicKeySet ごとに複数の attestationAuthenticators と複数の鍵を設定できます。それぞれの Pod のイメージで、任意の認証システムの pkixPublicKeySet に任意の鍵で署名された有効な証明書がある場合、このチェックの条件を満たしています。

CV プラットフォーム ポリシーは、次の点でプロジェクト シングルトン適用ポリシーと異なります。

  • PGP 鍵はサポートされていません。
  • 認証者は必要ありません。代わりに、鍵を手動で作成し、プラットフォーム ポリシーの説明を取得して、証明書の作成に今後使用する鍵 ID を取得します。
  • Artifact Analysis API を使用して、手動でペイロードを作成して署名し、証明書 JSON ファイルを作成して証明書を作成します。
  • Artifact Analysis メモはまだ作成されますが、ポリシーで指定しません。代わりに、CV は containerAnalysisAttestationProjects フィールドに一覧表示されているすべてのプロジェクトで証明書を検索します。
  • 証明書はまだ Artifact Analysis のオカレンスに保存されますが、複数のプロジェクトに保存されている可能性があります。
  • リソース名 projects/ATTESTATION_PROJECT_ID を使用して、証明書を含む 1 つ以上のプロジェクトを明示的に指定する必要があります。

CV は、除外イメージで指定されたものを除き、イメージのタグをサポートしていません。

イメージがダイジェストではなくイメージタグでデプロイされると、許可リストにはタグが含まれている可能性があるため、CV は最初に除外イメージの評価を行います。イメージが除外されていない場合、CV はイメージ ダイジェストを探します。存在しないため、イメージがチェックに違反しています。

SLSA チェック

SLSA チェックは、Pod のイメージの SLSA に指定された来歴をチェックします。

CV プラットフォーム ポリシーの YAML 構成の例を次に示します。

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
        allowPattern: "gcr.io/my-images/not-built-by-GCB/**"
    - slsaCheck:
        rules:
          trustedBuilder: GOOGLE_CLOUD_BUILD
          attestationSource:
          - containerAnalysisAttestationProjects: "projects/attestation-project1"
          - containerAnalysisAttestationProjects: "projects/attestation-project2"
          # Require that images were built using a checked-in top-level config file.
          configBasedBuildRequired: true
          # Which repos the config file can be from.
          trustedSourceRepoPatterns:
          - "source.cloud.google.com/my-project/my-source-repo"
          - "github.com/my-github-user/*"
      displayName: "My SLSA check"
    displayName: "My check set"

CV は、このプラットフォーム ポリシーを使用してイメージを確認する際、次の点をチェックします。

  • イメージは、信頼できるビルダーによってビルドされている必要があります。Cloud Build は、SLSA チェックでサポートされる唯一の信頼できるビルダーです。

  • Cloud Build が attestation-project1 または attestation-project2 のいずれかで証明書を生成している必要があります。

  • イメージは、次の信頼できるリポジトリのいずれかの最上位構成ファイルを使用して、ビルドする必要があります。

    • リポジトリ source.cloud.google.com/my-project/my-source-repo/
    • github.com/my-github-user/ の任意のリポジトリ

  • gcr.io/my-images/not-built-by-GCB/ またはそのサブディレクトリの（Cloud Build でビルドされていない）イメージは、違反する可能性があるため、チェックから除外されます。

「信頼できるディレクトリ」チェック

信頼できるディレクトリのチェックでは、Pod のイメージが、プラットフォーム ポリシーで指定された 1 つ以上の信頼できるディレクトリにあるかどうかチェックします。

このチェックを使用する場合は、ポリシーで信頼できるディレクトリとしてリストしているリポジトリを不正アクセスから保護するようにしてください。

次のプラットフォーム ポリシーの例では、信頼できるディレクトリのチェックを構成する方法について説明します。

gkePolicy:
  checkSets:
    checks:
      trustedDirectoryCheck:
        trustedDirPatterns:
        - "gcr.io/my-project/gcr-directory"
        - "us-central1-docker.pkg.dev/my-project/ar-directory"
        displayName: "My trusted directory check"
    displayName: "My check set"

プラットフォーム ポリシーの例では、trustedDirPatterns によって信頼できるディレクトリが一覧表示されます。すべての Pod のイメージが一覧表示されたディレクトリに存在する場合は、ポリシーに準拠します。一覧表示されたディレクトリに存在しない Pod のイメージがポリシーに違反し、CV がその違反を記録しています。

脆弱性チェック

脆弱性チェックでは、Artifact Analysis の脆弱性スキャンを使用して、Pod のイメージに脆弱性が含まれているかどうかをチェックします。これには、Pod のデプロイ後に脆弱性スキャンで識別された新しい脆弱性が含まれます。脆弱性チェックでは、脆弱性の重大度レベルのしきい値と特定の脆弱性（CVE）を構成できます。脆弱性チェックに違反するイメージは Logging に記録されます。

このチェックを使用するには、まず Artifact Analysis で脆弱性スキャンを有効にする必要があります。

次のプラットフォーム ポリシー構成の例には、脆弱性チェックが含まれています。

gkePolicy:
  checkSets:
    - displayName: "Default check set"
      checks:
        - vulnerabilityCheck:
           maximumFixableSeverity: MEDIUM
           maximumUnfixableSeverity: HIGH
           allowedCves:
             - "CVE-2022-11111"
             - "CVE-2022-22222"
           blockedCves:
             - "CVE-2022-33333"
             - "CVE-2022-44444"
           containerAnalysisVulnerabilityProjects: "projects/my-project"

例では、maximumUnfixableSeverity と maximumFixableSeverity は Artifact Analysis で識別できる脆弱性に関連付けられている共通脆弱性スコアシステム（CVSS）の重大度レベルを定義します。また、blockedCves には、特定の共通脆弱性識別子（CVE）が記載されています。識別された脆弱性が、指定された重大度レベルのいずれか超えるか、blockedCves にリストされている CVE の 1 つと一致するか、allowedCves にリストされている CVE の 1 つと一致しない場合、CV は Logging にエントリを記録します。

更新されたポリシーを検証する

CV プラットフォーム ポリシーを更新した後は、Binary Authorization と CV が想定どおりに動作し続けることを確認してください。

構成を検証する

構成をチェックするには、Binary Authorization プロジェクトのシングルトン ポリシーと CV プラットフォームのポリシーの両方を調査します。

オペレーションを検証する

Binary Authorization と CV が期待どおりに動作していることを検証するには、テスト Pod をデプロイしてから、Logging で Binary Authorization エントリをチェックします。

許可リストでイメージを除外する

プラットフォーム ポリシーを作成するときに、イメージの URL を許可リストに登録することで、イメージをチェック対象から除外できます。ポリシーレベルの許可リストにより、イメージがポリシー全体から除外されます。これは、チェックセット レベルの許可リストはチェックセットから除外され、そのチェックセットが評価された場合にのみ適用されます。チェック内の許可リストは、そのチェックからイメージのみを除外します。

許可リストパターンは、1 つ以上のイメージ URL に一致するパターンです。許可リストパターンには、次のいずれかを使用できます。

  • ワイルドカード * または ** で終わるイメージ名の接頭辞。
  • タグやダイジェストのないイメージ名のみ。
  • タグのあるイメージ名（またはワイルドカード * のあるタグ接頭辞）。
  • ダイジェストのあるイメージ名。
  • タグとダイジェストの両方のあるイメージ名。

許可リストのパターンの例を次に示します。

  • us-central1.pkg.dev/my-project/my-image:latest@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c は、イメージ名、タグ、ダイジェストと完全に一致します。
  • us-central1.pkg.dev/my-project/my-image:latest は、任意のダイジェスト（またはダイジェストなし）を使用して、名前とタグを一緒に照合します。
  • us-central1.pkg.dev/my-image:foo* は、名前とタグ接頭辞（myimage:foo や myimage:foobar など）を、任意のダイジェスト（またはダイジェストなし）と照合します。
  • us-central1.pkg.dev/my-project/my-image@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c は、名前とダイジェストを、任意のタグ（またはタグなし）と照合します。
  • us-central1.pkg.dev/my-project/my-image は、任意の名前を任意のタグやダイジェストと一致も扱います。

ワイルドカード文字 * と ** は、任意の名前を特定の接頭辞と一致させる場合にのみ使用できます。* は、/ を含まない接尾辞に一致します。** は、/ を含む接尾辞と一致しますが、** は / の後にのみ使用できます。* と ** は、タグまたはダイジェストと一緒に使用できません。

次に例を示します。

  • us-central1.pkg.dev/my-project/my-image* は、us-central1.pkg.dev/myproject/my-image、us-central1.pkg.dev/myproject/my-image1、us-central1.pkg.dev/myproject/my-image2 を任意のタグやダイジェストと照合します。
  • us-central1.pkg.dev/my-project/** では、us-central1.pkg.dev/myproject/my-image と us-central1.pkg.dev/my-project/some-directory/other-image は、任意のタグやダイジェストと照合します。

名前の接頭辞とタグの接頭辞は空にしてはいけません。したがって、* または ** のみは有効なパターンではなく、us-central1.pkg.dev/my-image:* でもありません。

gkePolicy レベルの除外

次の例は、プラットフォーム ポリシー レベルでイメージを除外する方法について示しています。exempt-images1 と exempt-images2 のディレクトリとそれらのサブディレクトリのすべてのイメージは CV モニタリングから除外されます。

gkePolicy:
  imageAllowlist:
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
  - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
  checkSets:
      checks:
        ...

このポリシーでは、imageAllowlist にリストされているイメージは、gkePolicy にリストされているすべてのチェックセット（checkSets）から除外されます。

チェックセットのレベルの除外

次の例は、チェックセット レベルでイメージを除外する方法を示しています。

gkePolicy:
  checkSets:
    imageAllowlist:
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
    - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
    checks:
      ...

このポリシーにより、imageAllowlist にリストされているイメージは checkSets にリストされているすべてのチェックから除外されます。

チェックレベルの除外

次の例は、チェックレベルでイメージを除外する方法を示しています。

gkePolicy:
  checkSets:
    checks:
      imageAllowlist:
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images1/**"
      - allow_pattern: "us-central1-docker.pkg.dev/PROJECT_ID/exempt-images2/**"
      ...

複数のチェックセットを使用する

CV チェックベースのポリシーには、複数のチェックセットを含めることができます。CV は、ポリシーを評価するたびに 1 つのチェックセットを評価します。チェックセットは、異なる状況で評価されるサブポリシーと考えることができます。たとえば、本番環境で適用するのとは異なるチェックを開発環境に適用する場合は、各環境のチェックを別々のチェックセット（開発環境でのみ評価されるものと本番環境で評価されるもの）に配置できます。

各チェックセットのスコープは、Kubernetes Namespace または Kubernetes サービス アカウントのいずれかです。スコープにより、チェックセットを適用する Pod を決めます。

チェックセットにスコープが構成されている場合、このスコープで実行中の Pod にのみ適用されます。

スコープのないチェックセットはデフォルトのチェックセットと呼ばれます。つまり、Kubernetes Namespace のスコープかサービス アカウント スコープに関係なく、すべての Pod にチェックが適用されます。

CV ガイドにあるサンプル ポリシーのほとんどは、デフォルトのチェックセットのみを使用しています。

次のポリシー構成の例では、3 つのチェックセットを構成しています。

gkePolicy:
  checkSets:
    - displayName: "Prod check set"
      scope:
        kubernetesNamespace: "prod-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/prod-images"
        - imageFreshnessCheck:
            maxUploadAgeDays: 30
    - displayName: "Dev check set"
      scope:
        kubernetesNamespace: "dev-namespace"
      checks:
        - trustedDirectoryCheck:
            trustedDirPatterns: "gcr.io/my-project/dev-images"
    - displayName: "Default check set"
      checks:
        - alwaysDeny: true

構成例で、最初のチェックセットは prod-namespace にスコープ設定されているため、そのチェックは、そのスコープで実行されている Pod にのみ影響します。2 つ目のチェックセットには、dev-namespace に設定されているため、そのチェックはスコープで実行されている Pod にのみ影響します。3 つ目のチェックセットは、デフォルトのチェックセットです。このチェックは、prod-namespace と dev-namespace のスコープ外で実行されているクラスタで、すべての Pod に適用されます。

CV は Prod check set というチェックセットを評価する際に、prod-namespace Kubernetes Namespace で実行されている Pod イメージについて次のことをチェックします。

  • イメージが信頼できる prod-images ディレクトリに保存されている。
  • イメージが、過去 30 日間の間にアップロードされました。

CV は Dev check set というチェックセットを評価する際に、dev-namespace Kubernetes Namespace で実行されている Pod を評価して、Pod 内のイメージが dev-images ディレクトリから取得されたかどうかをチェックします。

デフォルトのチェックセットはキャッチオールとして機能します。「常に拒否」チェックでは、CV が他の Namespace で実行されているすべての Pod がログに記録されるようにします。

Kubernetes サービス アカウントをチェックセットのスコープとして使用するには、例のキー kubernetesNamespace を kubernetesServiceAccount に置き換えます。値は形式 my-namespace:my-service-account です。

チェックセットのスコープには次のルールがあります。

  • プラットフォーム ポリシーのスコープごとに設定できるチェックセットは 1 つのみです。

  • ポリシーに Namespace スコープとサービス アカウント スコープの両方のチェックセットが含まれている場合、サービス アカウント スコープのチェックセットを最初に一覧表示してから、次に Namespace スコープのチェックセットを一覧表示する必要があります。

  • デフォルトのチェックセットは 1 つのみ設定できます。これは、最後に一覧表示されるはずです。

プラットフォーム ポリシーになんらかのチェックセットが含まれている場合は、少なくともデフォルトのチェックセットを含める必要があります。チェックセットのないプラットフォーム ポリシーも使用できますが、違反するチェックがないため、CV はログエントリを生成しません。

以前の CV

このセクションでは、以前の CV ポリシーについて説明します。CV に慣れていない場合は、代わりに CV プラットフォーム ポリシーを使用することをおすすめします。

以前の CV ユーザーをサポートするため、GKE を実行するプロジェクトで CV を有効にできます。その後、CV は Binary Authorization 適用ポリシーを使用して、Binary Authorization の適用が有効になっていないクラスタなど、プロジェクト内のすべてのクラスタで実行されている Pod をチェックします。

以前の CV を使用して、Cloud Logging での以前の CV イベントを表示する方法を学習します。

次のステップ