このページでは、Binary Authorization に関連する主なコンセプトについて説明します。
ポリシー
Binary Authorization ポリシーは、コンテナ イメージのデプロイと検証を統制する一連のルールです。ポリシーは次の部分から構成されます。
ポリシーを構成するには、次のいずれかを使用します。
- Google Cloud Console
gcloudコマンド
gcloud コマンドを使用する場合は、プロジェクトにインポートする前に、ポリシーの定義を YAML 形式でエクスポートして変更します。YAML 形式は、Binary Authorization ストレージのポリシーの内部構造を反映しています。この形式の詳細については、ポリシー YAML リファレンスをご覧ください。
各 Google Cloud プロジェクトに設定できるポリシーは 1 つだけです。ポリシーは、デプロイ プラットフォームを実行するプロジェクトで構成する必要があります。単一プロジェクト構成では、ポリシーとすべての下位リソース（認証者と証明書）が同じプロジェクトに存在します。職掌分散を確立するために、マルチプロジェクト構成を使用できます。この構成では、デプロイ プラットフォームを 1 つのプロジェクトで実行して、認証者を別のプロジェクトに配置し、証明書をさらに別のプロジェクトに配置できます。
サポートされているプラットフォームで Binary Authorization を設定して使用するには、プラットフォーム別の設定をご覧ください。
GKE のマルチプロジェクト設定の例をご覧ください。
ルール
ポリシーを構成するときに、そのルールを定義します。ルールでは、イメージをデプロイする前に満たす必要がある制約を定義します。ポリシーには、デフォルト ルールが 1 つあり、プラットフォームに応じて特定のルールを設定できます。詳細については、プラットフォーム別のサポートされているルールの種類をご覧ください。
各ルールは、評価モードおよび強制モードを使用して構成できます。たとえば、あるルールについて、イメージのデプロイ前に署名済みの証明書を求めることができます。
デフォルトのルール
各ポリシーには 1 つのデフォルト ルールがあります。このルールは、クラスタ固有のルールに一致しないデプロイ リクエストに適用されます。ポリシー YAML ファイルでは、デフォルト ルールは defaultAdmissionRule ノードに指定されています。
デフォルト ルールの構成の詳細については、ポリシーの設定をご覧ください。
固有のルール
ポリシーには、1 つ以上の固有のルールを追加できます。このタイプのルールは、特定のクラスタ、サービス アカウント、または ID にデプロイするイメージに適用されます。固有のルールのサポートは、プラットフォームによって異なります。詳細については、プラットフォーム別のサポートされているルールの種類をご覧ください。
ポリシー YAML ファイルで、クラスタ固有のルールは clusterAdmissionRule ノードに指定されています。
プラットフォーム別のサポートされているルールの種類
次の表に、各デプロイメント プラットフォームでサポートされるルールの種類を示します。
| プラットフォーム | デフォルトのルール | 固有のルール |
|---|---|---|
| GKE | サポート対象 | クラスタ Kubernetes ID Kubernetes サービス アカウント |
| Cloud Run | サポート対象 | 非対応 |
| Anthos clusters on VMware | サポート対象 | クラスタ |
| Anthos Service Mesh | サポート対象 | Anthos Service Mesh サービス ID |
評価モード
ルールごとに評価モードがあり、Binary Authorization でルールに適用される制約のタイプが指定されます。ルールの評価モードは、ポリシー YAML ファイルの evaluationMode プロパティに指定されます。
次の 3 つの評価モードがあります。
- すべてのイメージを許可。すべてのイメージのデプロイを許可します。
- すべてのイメージを禁止。すべてのイメージのデプロイを禁止します。
- 証明書を要求する。署名者にイメージ ダイジェストにデジタル署名し、デプロイ前に証明書を作成することを要求します。デプロイ時に、Binary Authorization 施行者は認証者を使用して、関連するイメージをデプロイする前に証明書の署名を検証します。
強制適用モード
各ルールには適用モードもあります。これは、イメージがルールを遵守していない場合に GKE が実行するアクションを指定します。ルールには、次の適用モードを設定できます。
ブロックと監査ログ。ルールを遵守していないイメージのデプロイをブロックし、イメージがデプロイされなかった理由を示すメッセージを監査ログに書き込みます。
ドライラン: 監査ログのみ: ドライラン モードは強制適用モードの一つで、非遵守のイメージをデプロイできますが、デプロイに関する詳細を Cloud Audit Logs に書き込みます。ドライラン モードでは、強制実行が実際に適用される前に、本番環境などでポリシーをテストできます。
ほとんどの本番環境ルールでは、「ブロックと監査ログ」の適用モードが使用されます。「ドライラン: 監査ログのみ」は主に、ポリシーを有効にする前に環境でテストを行う場合に使用されます。
ルールの適用モードは、ポリシー YAML ファイルの enforcementMode プロパティに指定します。
Cloud Audit Logs に書き込まれたメッセージの詳細については、監査ログの表示（GKE、Anthos clusters on VMware、Anthos Service Mesh）または監査ログ（Cloud Run）の表示をご覧ください。
継続的検証
継続的検証（CV）は、Binary Authorization の機能です。ポリシーの遵守を継続するために、実行されている Pod に関連付けられたイメージを定期的にチェックします。
除外イメージ
除外イメージは、ポリシールールの対象外となるイメージです。Binary Authorization では、除外イメージのデプロイが常に許可されます。各プロジェクトには、レジストリパスで指定された除外イメージの許可リストがあります。デフォルトでは、パス gcr.io/google_containers/*、k8s.gcr.io/**、追加パスにあるイメージは除外されます。これらのイメージには、デフォルト ポリシーがアクティブな状態で GKE がクラスタを正常に起動するために必要なリソースが含まれています。
除外イメージの許可リストは、ポリシー YAML ファイルの admissionWhitelistPatterns プロパティに指定します。
許可リストパターン
レジストリの場所が指定したパスと一致するイメージをすべて許可リストに登録するには:
gcr.io/example-project/*
レジストリの場所が指定したパスのサブディレクトリ（例: gcr.io/example-project/my-directory/helloworld）であるすべてのイメージを許可リストに登録するには。
gcr.io/example-project/**
特定のイメージを許可リストに登録するには:
gcr.io/example-project/helloworld
タグを使ってイメージの特定のバージョンを許可リストに登録するには:
gcr.io/example-project/helloworld:latest gcr.io/example-project/helloworld:my-tag
1 つのイメージのバージョン / タグをすべて許可リストに登録するには:
gcr.io/example-project/helloworld*
特定のバージョンのイメージをダイジェストで許可リストに登録するには:
gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c
詳細については、コンテナ イメージ ダイジェストの使用をご覧ください。
Google Cloud コンソール、コマンドライン ツール、または REST API を使用した除外イメージを管理する方法を確認してください。
Google が管理するシステム イメージ
Google が管理するシステム イメージをすべて信頼する場合、Binary Authorization では、Google が管理するシステム イメージのリストが以降のポリシー評価から除外されます。この設定を有効にすると、GKE で必要なイメージはポリシーの適用でブロックされません。システム ポリシーは、ユーザー ポリシーよりも先に評価されます。
この設定は、ポリシー YAML ファイルの globalPolicyEvaluationMode プロパティで有効または無効にできます。システム ポリシーの内容を表示するには、次のコマンドを使用します。
gcloud alpha container binauthz policy export-system-policy
証明書
証明書は、イメージを証明するデジタル ドキュメントです。デプロイ時に、Binary Authorization はイメージのデプロイを許可する前に証明書を検証します。
証明書を作成するプロセスを「イメージに署名する」という場合があります。証明書は、イメージのビルド後に作成されます。このようなイメージには、グローバルに一意のダイジェストがあります。署名者は、鍵ペアの秘密鍵を使用してイメージのダイジェストに署名し、その署名を使用して証明書を作成します。デプロイ時に、Binary Authorization 施行者は認証者の公開鍵を使用して証明書の署名を検証します。通常、1 人の認証者が 1 人の署名者に対応します。
証明書は、特定の必要なプロセスが正常に実行され、関連するイメージがビルドされたことを示します。たとえば、署名者が品質保証（QA）の代表者である場合、証明書はステージング環境で必要なエンドツーエンド機能テストに合格していることを示します。
Binary Authorization で証明書を有効にするため、ポリシーの evaluationMode は REQUIRE_ATTESTATION に設定します。
認証者と証明書を作成して使用する方法をご覧ください。
署名者
署名者は、秘密鍵を使用して一意のイメージ記述子に署名することで、証明書を作成する人または自動プロセスです。デプロイ時に、関連するイメージをデプロイする前に認証者に保存された対応公開鍵により、証明書が検証されます。
認証者と証明書を作成して使用する方法をご覧ください。
認証者
認証者は、Binary Authorization が、イメージをデプロイするとき証明書の検証に使用する Google Cloud リソースです。証明書には、イメージのダイジェストに署名して証明書を作成するために署名者が使用した秘密鍵が含まれています。Binary Authorization 施行者は、デプロイ時に認証者を使用して、デプロイを許可するイメージを、デプロイ前に作成された検証可能な証明書を持つイメージに限定します。
認証者の管理は、公開鍵と秘密鍵のペアも管理するセキュリティ オペレーション担当者が担当する場合がよくありますが、通常、署名者は、デプロイ可能なイメージを作成し、秘密鍵で署名を行い、デプロイ前に証明書を作成するソフトウェア エンジニア、DevOps QA 担当者、コンプライアンス担当者になります。
認証者には次のものがあります。
- 対応する Container Analysis メモ
- 署名者が証明書の作成に使用した秘密鍵に対応する 1 つ以上の暗号公開鍵。
「証明書を要求」ルールを含むポリシーを設定する場合は、イメージをデプロイする準備ができていることを確認する人またはプロセスに認証者を追加する必要があります。認証者を追加するには、Google Cloud Console、gcloud インターフェース、または Binary Authorization REST API を使用します。
認証者と証明書を作成して使用する方法をご覧ください。
暗号鍵
Binary Authorization では、ポリシーに「証明書を要求」ルールが含まれている場合、デプロイ時にデジタル署名を使用してイメージを検証します。
鍵ペアが生成されます。秘密鍵は、署名者がイメージ記述子に署名するために使用します。これにより、証明書が作成されます。
次に、認証者が作成され、ポリシーに保存されます。署名に使用される秘密鍵に対応する公開鍵がアップロードされ、認証者に送信されます。
デプロイとイメージが試行されると、Binary Authorization はポリシーで認証者を使用してイメージの証明書を検証します。証明書を検証できる場合は、イメージがデプロイされます。
Binary Authorization は 2 種類の鍵をサポートしています。
PKIX 鍵はローカル、外部、または Cloud Key Management Service に保存できます。
Container Analysis のメモ
Binary Authorization は、Container Analysis を使用して、認証プロセスで使用される信頼できるメタデータを保存します。作成する認証者ごとに、1 つの Container Analysis メモを作成する必要があります。それぞれの証明書が、このメモのオカレンスとして保存されます。
Binary Authorization は、認証者によるイメージの検証を必要とするルールを評価するときに、Container Analysis ストレージをチェックし、必要な証明書が存在するかどうか確認します。