このページでは、Google Cloud Console を使用して Binary Authorization ポリシーを構成する手順について説明します。これらのタスクは gcloud コマンドライン ツールまたは REST API でも実行できます。この手順は Binary Authorization の設定の一部です。
ポリシーとは、コンテナ イメージのデプロイを規定する一連のルールです。
始める前に
- Binary Authorization を有効にします。
- クラスタを作成します。
- 証明書を使用する場合は、ポリシーを構成する前に認証者を作成することをおすすめします。認証者を作成するには、Cloud Console またはコマンドライン ツールを使用します。
- Binary Authorization を有効にしたプロジェクトのプロジェクト ID を選択します。
デフォルト ルールを設定する
このセクションは、GKE、Anthos clusters on VMware、Cloud Run、Anthos Service Mesh に該当する内容です。
ルールは、イメージをデプロイする前に満たす必要がある制約を定義するポリシーの一部です。デフォルト ルールは、独自のクラスタ固有のルールがなく、すべての対象コンテナ イメージに適用される制約を定義します。すべてのポリシーにはデフォルト ルールがあります。
デフォルト ルールを設定するには、次のようにします。
Cloud Console で、[Binary Authorization] ページに移動します。
[ポリシー] タブをクリックします。
[ポリシーの編集] をクリックします。
デフォルト ルールの評価モードを選択します。
評価モードにより、デプロイ時に Binary Authorization が適用する制約のタイプが指定されます。評価モードを設定するには、次のいずれかのオプションを選択します。
- すべてのイメージを許可: すべてのイメージのデプロイを許可します。
- Deny all images: すべてのイメージのデプロイを禁止します。
- Allow only images that have been approved by the following attestors: このルールに追加した認証者の 1 人によって検証された関連の証明書がイメージに含まれている場合に、イメージのデプロイを許可します。認証者の作成方法については、認証者の作成をご覧ください。
[Allow only images that have been approved by the following attestors] を選択した場合:
認証者の名前またはリソース ID を取得します。
Google Cloud Console の [認証者] ページでは、既存の認証者を確認するか、新しい認証者を作成できます。
[認証者の追加] をクリックします。
次のオプションのいずれかを選択します。
プロジェクトと認証者の名前により追加
プロジェクトは、認証者を保存するプロジェクトのプロジェクト ID を参照します。認証者の名前の例は
build-qaです。認証者リソース ID により追加
リソース ID の形式は次のとおりです。
projects/PROJECT_ID/attestors/ATTESTOR_NAME
[認証者] で、選択したオプションに適切な値を入力します。
さらに認証者を追加する場合は、[別の認証者を追加] をクリックします。
[認証者の追加] をクリックしてルールを保存します。
ドライラン モードを有効にする場合は、次の操作を行います。
[ドライラン モード] を選択します。
[ポリシーを保存] をクリックします。
クラスタ固有のルールを設定する（省略可）
このセクションは、GKE、Anthos clusters on VMware、Anthos Service Mesh に該当する内容です。
ポリシーには、1 つ以上のクラスタ固有のルールも設定できます。このタイプのルールは、特定の Google Kubernetes Engine（GKE）クラスタにのみデプロイされるコンテナ イメージに適用されます。クラスタ固有のルールはポリシーのオプション部分です。
クラスタ固有のルールを追加する（GKE）
このセクションは、GKE と Anthos clusters on VMware に該当する内容です。
GKE クラスタにクラスタ固有のルールを追加するには、次の手順を行います。
Cloud Console で、[Binary Authorization] ページに移動します。
[ポリシー] タブをクリックします。
[ポリシーの編集] をクリックします。
[クラスタ固有のルール] で、[ルール] セクションを開きます。
[ルールを追加] をクリックします。
[クラスタ リソース ID] に、クラスタのリソース ID を入力します。
クラスタのリソース ID の形式は、
LOCATION.NAMEです（例:us-central1-a.test-cluster）。デフォルト ルールの評価モードを選択します。
評価モードにより、デプロイ時に Binary Authorization が適用する制約のタイプが指定されます。評価モードを設定するには、次のいずれかのオプションを選択します。
- すべてのイメージを許可: すべてのイメージのデプロイを許可します。
- Deny all images: すべてのイメージのデプロイを禁止します。
- Allow only images that have been approved by the following attestors: このルールに追加した認証者の 1 人によって検証された関連の証明書がイメージに含まれている場合に、イメージのデプロイを許可します。認証者の作成方法については、認証者の作成をご覧ください。
[Allow only images that have been approved by the following attestors] を選択した場合:
認証者の名前またはリソース ID を取得します。
Google Cloud Console の [認証者] ページでは、既存の認証者を確認するか、新しい認証者を作成できます。
[認証者の追加] をクリックします。
次のオプションのいずれかを選択します。
プロジェクトと認証者の名前により追加
プロジェクトは、認証者を保存するプロジェクトのプロジェクト ID を参照します。認証者の名前の例は
build-qaです。認証者リソース ID により追加
リソース ID の形式は次のとおりです。
projects/PROJECT_ID/attestors/ATTESTOR_NAME
[認証者] で、選択したオプションに適切な値を入力します。
さらに認証者を追加する場合は、[別の認証者を追加] をクリックします。
[認証者の追加] をクリックしてルールを保存します。
[追加] をクリックして、クラスタ固有のルールを追加します。
次のようなメッセージが表示されることがあります「このクラスタは存在しないようです。このクラスタが GKE で使用可能になると、このルールは有効になります。」その場合は、[追加] をもう一度クリックしてルールを保存します。
ドライラン モードを有効にする場合は、[ドライラン モード] を選択します。
[ポリシーを保存] をクリックします。
クラスタ固有のルールを追加する（Anthos clusters on VMware）
このセクションは、Anthos clusters on VMware に該当する内容です。
Anthos clusters on VMware クラスタにクラスタ固有のルールを追加する方法は次のとおりです。
Cloud Console で、[Binary Authorization] ページに移動します。
[ポリシー] タブをクリックします。
[ポリシーの編集] をクリックします。
[クラスタ固有のルール] で、[ルール] セクションを開きます。
[ルールを追加] をクリックします。
[クラスタ リソース ID] に、クラスタのリソース ID を入力します。
リソース ID の形式は
global.CLUSTER_IDです。Anthos clusters on VMware クラスタのクラスタ リソース ID を取得する方法を確認してください。デフォルト ルールの評価モードを選択します。
評価モードにより、デプロイ時に Binary Authorization が適用する制約のタイプが指定されます。評価モードを設定するには、次のいずれかのオプションを選択します。
- すべてのイメージを許可: すべてのイメージのデプロイを許可します。
- Deny all images: すべてのイメージのデプロイを禁止します。
- Allow only images that have been approved by the following attestors: このルールに追加した認証者の 1 人によって検証された関連の証明書がイメージに含まれている場合に、イメージのデプロイを許可します。認証者の作成方法については、認証者の作成をご覧ください。
[Allow only images that have been approved by the following attestors] を選択した場合:
認証者の名前またはリソース ID を取得します。
Google Cloud Console の [認証者] ページでは、既存の認証者を確認するか、新しい認証者を作成できます。
[認証者の追加] をクリックします。
次のオプションのいずれかを選択します。
プロジェクトと認証者の名前により追加
プロジェクトは、認証者を保存するプロジェクトのプロジェクト ID を参照します。認証者の名前の例は
build-qaです。認証者リソース ID により追加
リソース ID の形式は次のとおりです。
projects/PROJECT_ID/attestors/ATTESTOR_NAME
[認証者] で、選択したオプションに適切な値を入力します。
さらに認証者を追加する場合は、[別の認証者を追加] をクリックします。
[認証者の追加] をクリックしてルールを保存します。
[追加] をクリックしてルールを保存します。
次のようなメッセージが表示されることがあります「このクラスタは存在しないようです。指定したクラスタが GKE で使用可能になると、このルールは有効になります。」その場合は、もう一度 [追加] をクリックしてルールを保存します。
ドライラン モードを有効にする場合は、[ドライラン モード] を選択します。
[ポリシーを保存] をクリックします。
固有のルールを追加する
メッシュ サービス ID、Kubernetes サービス アカウント、または Kubernetes Namespace のいずれかをスコープとするルールを作成できます。特定のルールを追加または変更するには、次のようにします。
Cloud Console で、[Binary Authorization] ページに移動します。
[ポリシー] タブをクリックします。
[ポリシーの編集] をクリックします。
特定のルールの種類が設定されていない場合は、[特定のルールを作成] をクリックします。
[固有のルールの種類] をクリックして、ルールの種類を選択します。
[変更] をクリックして、ルールの種類を更新します。
特定のルールの種類が存在する場合は、[タイプの編集] をクリックしてルールの種類を変更できます。
特定のルールを追加するには、[固有のルールを追加] をクリックします。選択したルールの種類に応じて、次のように ID を入力します。
- ASM Service Identity: ASM サービス ID を入力します。これは、PROJECT_ID.svc.id/goog/ns/NAMESPACE/sa/SERVICE_ACCOUNT のような形式になります。
- Kubernetes サービス アカウント: Kubernetes サービス アカウントを入力します。これは、NAMESPACE:SERVICE_ACCOUNT のような形式になります。
- Kubernetes Namespace: Kubernetes の Namespace を入力します。これは、NAMESPACE のような形式になります。
ルールの種類によって、必要に応じて次のように置き換えます。
- PROJECT_ID: Kubernetes リソースを定義するプロジェクト ID。
- NAMESPACE: Kubernetes の Namespace。
- SERVICE_ACCOUNT: サービス アカウント。
デフォルト ルールの評価モードを選択します。
評価モードにより、デプロイ時に Binary Authorization が適用する制約のタイプが指定されます。評価モードを設定するには、次のいずれかのオプションを選択します。
- すべてのイメージを許可: すべてのイメージのデプロイを許可します。
- Deny all images: すべてのイメージのデプロイを禁止します。
- Allow only images that have been approved by the following attestors: このルールに追加した認証者の 1 人によって検証された関連の証明書がイメージに含まれている場合に、イメージのデプロイを許可します。認証者の作成方法については、認証者の作成をご覧ください。
[Allow only images that have been approved by the following attestors] を選択した場合:
認証者の名前またはリソース ID を取得します。
Google Cloud Console の [認証者] ページでは、既存の認証者を確認するか、新しい認証者を作成できます。
[認証者の追加] をクリックします。
次のオプションのいずれかを選択します。
プロジェクトと認証者の名前により追加
プロジェクトは、認証者を保存するプロジェクトのプロジェクト ID を参照します。認証者の名前の例は
build-qaです。認証者リソース ID により追加
リソース ID の形式は次のとおりです。
projects/PROJECT_ID/attestors/ATTESTOR_NAME
[認証者] で、選択したオプションに適切な値を入力します。
さらに認証者を追加する場合は、[別の認証者を追加] をクリックします。
[認証者の追加] をクリックしてルールを保存します。
[ドライラン モード] をクリックして、ドライラン モードを有効にします。
[追加] をクリックして、そのルールを保存します。
[ポリシーを保存] をクリックします。
除外イメージを管理する
このセクションは、GKE、Anthos clusters on VMware、Cloud Run、Anthos Service Mesh に該当する内容です。
除外イメージは、パスで指定され、ポリシールールの対象外となるイメージです。Binary Authorization では、除外イメージのデプロイが常に許可されます。
このパスは、Container Registry 内の場所か、別のコンテナ イメージ レジストリを指定できます。
Cloud Run
このセクションは Cloud Run に該当する内容です。
イメージ名は、IMAGE_PATH@* の形式にする必要があります（例: us-docker.pkg.dev/cloudrun/container/hello@*）。
イメージ名にタグを含めることはできません。タグを含むイメージ名を除外するイメージ名をフォーマットするには、* をワイルドカードとして使用します。
パス名にはダイジェストを指定できます。
システム ポリシーを有効にする
このセクションは、GKE と Anthos clusters on VMware に該当する内容です。
[Trust all Google-maintained system images] は、Binary Authorization システム ポリシーを有効にするポリシー設定です。この設定をデプロイ時に有効にすると、Binary Authorization は、GKE で必要とされる Google 管理のシステム イメージのリストをポリシー評価から除外します。システム ポリシーは、他のポリシー設定よりも先に評価されます。
システム ポリシーを有効にする方法は次のとおりです。
Cloud Console の [Binary Authorization] ページに移動します。
[ポリシーの編集] をクリックします。
[デプロイルールからイメージを除外] セクションで、[Google 提供のシステム イメージをすべて信頼する] を選択します。
システム ポリシーによって除外されたイメージを表示するには、[詳細を表示] をクリックします。
除外するイメージを手動で指定するには、[Images Paths] セクションを展開します。
次に、[イメージパスを追加] をクリックして、除外するイメージのレジストリパスを入力します。
[ポリシーを保存] をクリックします。
次のステップ
built-by-cloud-build認証者を使用して、Cloud Build によってビルドされたイメージのみをデプロイする（プレビュー）。- 証明書を使用する。
- GKE イメージをデプロイする。
- Cloud Audit Logs のイベントを表示する。
- 継続的検証を使用して、ポリシーを遵守しているか確認する。