Google Cloud Platform の利用規約（セクション 1.4（d）、"サービスの終了"）では、 Binary Authorizationに適用される非推奨ポリシーが定義されています。非推奨ポリシーは、こちらに記載されているサービス、機能、プロダクトにのみ適用されます。
サービス、機能、プロダクトが正式に非推奨になっても、利用規約で定義されている期間まではサービスを継続して利用できます。この期間をすぎると、サービスは提供終了となります。
Binary Authorization は、GKE のプロジェクト シングルトン ポリシーによる以前の継続的検証（以前の CV）のサポートを終了します。
- 2024 年 4 月 15 日以降、新しいプロジェクトで Google Kubernetes Engine（GKE）の以前の CV を有効にすることはできません。
- 以前の CV は、2025 年 5 月 1 日まで、すでに有効になっている既存のプロジェクトのプロジェクト シングルトン ポリシーを介して GKE Pod をモニタリングし続けます。2025 年 5 月 1 日以降、以前の CV は Pod をモニタリングしなくなります。また、プロジェクト シングルトンの Binary Authorization ポリシーを遵守していない Pod イメージに対して Cloud Logging エントリが生成されなくなります。
代替: チェックベースのプラットフォーム ポリシーによる継続的検証（CV）
チェックベースのプラットフォーム ポリシーによる継続的検証（CV）を使用して Pod をモニタリングします。
チェックベースのプラットフォーム ポリシーでは、証明書のサポートに加えて、Pod に関連付けられたコンテナ イメージのメタデータをモニタリングして、潜在的なセキュリティ問題を軽減できます。CV チェックベースのポリシーでは、次のチェックが提供されます。
- 脆弱性チェック: 定義した重大度レベルのセキュリティ脆弱性がイメージにないか、チェックされます。
- Sigstore チェック: イメージには、sigstore によって署名された証明書があります。
- SLSA チェック: イメージは、信頼できるビルダーによって、信頼できるディレクトリ内のソースからビルドされています。
- 信頼できるディレクトリのチェック: イメージは、信頼できるイメージ リポジトリ内の信頼できるディレクトリに配置する必要があります。
以前の継続的検証と同様に、チェックベースのポリシーを使用した CV でも、遵守していないイメージを含む Pod が Logging に記録されます。
以前の継続的検証（以前の CV）を使用している場合は、移行をご覧ください。
チェックベースのプラットフォーム ポリシーで CV を使用する方法について詳しくは、継続的検証の概要をご覧ください。
移行
以前の CV プロジェクト シングルトン ポリシーから同等のチェックベースのプラットフォーム ポリシーに移行するには、次の操作を行います。
ALWAYS_ALLOWプロジェクト シングルトン ポリシーの場合は、checkSetブロックのないチェックベースのプラットフォーム ポリシーを作成します。ALWAYS_DENYプロジェクト シングルトン ポリシーの場合は、alwaysDenyチェックを含む単一のcheckSetブロックを使用して、チェックベースのプラットフォーム ポリシーを作成します。- 証明書を必要とするプロジェクト シングルトン ポリシーの場合は、チェックベースのポリシーを 1 つ作成し、プロジェクト シングルトン ポリシーの認証者ごとに、チェックベースのポリシーに SimpleSigningAttestationCheck を 1 つ追加します。同じ鍵ペアを使用すると、チェックは既存の証明書を引き続き使用し、有効な証明書がない Pod イメージのみをログに記録します。
チェックベースのプラットフォーム ポリシーのスコープは、Google Cloud プロジェクトではなく GKE クラスタです。チェックベースのプラットフォーム ポリシーを作成後は、そのポリシーを 1 つ以上のクラスタに適用できます。
クラスタでチェックベースのプラットフォーム ポリシーを使用して CV を有効にするには、クラスタの作成または更新プロセス中にクラスタの Binary Authorization 設定を構成する必要があります。