Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

継続的検証の概要

チェックベースのプラットフォームポリシーによる継続的検証（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 のイメージがビルドされたことをチェックします。
- Sigstore 署名: Pod イメージに有効な Sigstore 署名がない場合に CV が記録します。
- 信頼できるディレクトリ: 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 に記録します。各 Pod について、違反したプラットフォームポリシーごとに別々のログエントリが書き込まれます。

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

CV は、ポリシーに準拠していないイメージを含む Pod が終了するまでポリシー違反を記録し続けます。ポリシーに準拠していない Pod が検証期間の合間に終了すると、次の CV 評価期間中に最終的な CV 生成ログエントリが表示されることがあります。

ポリシーに準拠していない Pod は、短命な Pod であっても少なくとも 1 回はログに記録されます。

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 を使用するには、通常、次のようにします。

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

チェック

このセクションでは、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:
        -