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