このページでは、Binary Authorization に関連する主なコンセプトについて説明します。
ポリシー
Binary Authorization のポリシーは、Google Kubernetes Engine（GKE）へのコンテナ イメージのデプロイを制御する一連のルールです。ポリシーは次の部分から構成されます。
ポリシーを構成するには、次のいずれかを使用します。
- Google Cloud Console
gcloudコマンド
gcloud コマンドを使用する場合は、プロジェクトにインポートする前に、ポリシーの定義を YAML 形式でエクスポートして変更します。YAML 形式は、Binary Authorization ストレージのポリシーの内部構造を反映しています。この形式の詳細については、ポリシー YAML リファレンスをご覧ください。
各 Google Cloud プロジェクトに設定できるポリシーは 1 つだけです。単一プロジェクト構成では、このポリシーは GKE へのデプロイを制御します。この場合、デプロイ パイプライン内のすべてのリソースが同じプロジェクトに存在します。マルチプロジェクト構成では、1 つのプロジェクトの Container Registry から別のプロジェクトで実行される GKE クラスタへのイメージのデプロイを 1 つのポリシーで制御できます。
詳細については、コマンドライン インターフェース（GKE）を使用してポリシーを構成すると Cloud Console（GKE）を使用してポリシーを構成するをご覧ください。
ルール
ルールは、ポリシーの一部として、イメージをデプロイする際の制約を定義します。通常、ルールでは、デジタル署名を 1 つ以上持つ証明書が必要になります。必要な証明書の署名が検証されることで、必要な内部プロセスがすべて揃っていることが確認されると、イメージのデプロイが許可されます。また、特定の Container Registry パスや特定の GKE クラスタへのデプロイをすべて許可または拒否することもできます。
ルールはポリシーの構成時に定義します。1 つのポリシーには、1 つのデフォルト ルールと任意の数のクラスタ固有のルールがあります。
デフォルトのルール
各ポリシーには 1 つのデフォルト ルールがあります。このルールは、クラスタ固有のルールに一致しないデプロイ リクエストに適用されます。ポリシーにクラスタ固有のルールがない場合、デフォルト ルールが常に適用されます。ポリシー YAML ファイルでは、デフォルト ルールは defaultAdmissionRule ノードに指定されています。
クラスタ固有のルール
ポリシーには、1 つ以上のクラスタ固有のルールも設定できます。このタイプのルールは、特定の GKE クラスタにのみデプロイされるイメージに適用されます。ポリシー YAML ファイルで、クラスタ固有のルールは clusterAdmissionRule ノードに指定されています。
評価モード
ルールごとに評価モードがあり、Binary Authorization でルールに適用される制約のタイプが指定されます。ルールの評価モードは、ポリシー YAML ファイルの evaluationMode プロパティに指定されます。
次の 3 つの評価モードがあります。
- すべてのイメージを許可: すべてのイメージのデプロイを許可します。
- すべてのイメージを禁止: すべてのイメージのデプロイを禁止します。
- 証明書を要求する: 署名者にイメージ ダイジェストにデジタル署名し、デプロイ前に証明書を作成することを要求します。デプロイ時に、Binary Authorization 施行者は認証者を使用して、関連するイメージをデプロイする前に証明書の署名を検証します。
強制適用モード
各ルールには適用モードもあります。これは、イメージがルールを遵守していない場合に GKE が実行するアクションを指定します。ルールには、次の適用モードを設定できます。
ブロックと監査ログ。ルールを遵守していないイメージのデプロイをブロックし、イメージがデプロイされなかった理由を示すメッセージを監査ログに書き込みます。
ドライラン: 監査ログのみ: ドライラン モードは強制適用モードの 1 つで、非遵守のイメージをデプロイできますが、デプロイに関する詳細を Cloud Audit Logs に書き込みます。ドライラン モードでは、強制実行が実際に適用される前に、本番環境などでポリシーをテストできます。
ほとんどの本番環境ルールでは、「ブロックと監査ログ」の適用モードが使用されます。「ドライラン: 監査ログのみ」は主に、ポリシーを有効にする前に環境でテストを行う場合に使用されます。
ルールの適用モードは、ポリシー YAML ファイルの enforcementMode プロパティに指定します。
Cloud Logging に書き込まれるメッセージの詳細については、監査ログの表示をご覧ください。
継続的検証
継続的検証（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
詳細については、コンテナ イメージ ダイジェストの使用をご覧ください。
Cloud Console、コマンドライン ツール、または REST API を使用した除外イメージを管理する方法を確認してください。
Google が管理するシステム イメージ
Google が管理するシステム イメージをすべて信頼する場合、Binary Authorization では、Google が管理するシステム イメージのリストが以降のポリシー評価から除外されます。この設定を有効にすると、GKE で必要なイメージはポリシーの適用でブロックされません。システム ポリシーは、ユーザー ポリシーよりも先に評価されます。
この設定は、ポリシー YAML ファイルの globalPolicyEvaluationModeプロパティで有効または無効にできます。次のコマンドを使用すると、システム ポリシーの内容を表示できます。
gcloud container binauthz policy export-system-policy
証明書
証明書は、イメージを証明するデジタル ドキュメントです。デプロイ時に Binary Authorization は、イメージのデプロイを許可する前に証明書を検証します。
証明書を作成するプロセスを「イメージに署名する」という場合があります。証明書はイメージのビルド後に作成されます。このようなイメージには、グローバルに一意のダイジェストが付与されています。署名者は、鍵ペアの秘密鍵を使用してイメージのダイジェストに署名し、その署名を使用して証明書を作成します。デプロイ時に、Binary Authorization 施行者は認証者の公開鍵を使用して証明書の署名を検証します。通常、1 人の認証者が 1 人の署名者に対応します。
証明書は、特定の必要なプロセスが正常に実行され、関連するイメージがビルドされたことを示します。たとえば、署名者が品質保証（QA）の代表者である場合、証明書はステージング環境で必要なエンドツーエンドの機能テストに合格していることを示します。
Binary Authorization で証明書を有効にするため、ポリシーの evaluationMode は REQUIRE_ATTESTATION に設定します。
一般的なユースケースについては、Binary Authorization の概要をご覧ください。
認証者と証明書を作成して使用する方法をご覧ください。
署名者
署名者は、秘密鍵を使用して一意のイメージ記述子に署名して証明書を作成する、人または自動プロセスです。証明書は、関連するイメージをデプロイする前に認証者に保存された対応する公開鍵により、デプロイ時に検証されます。
認証者と証明書を作成して使用する方法をご覧ください。
認証者
認証者は、Binary Authorization が、イメージをデプロイするとき証明書の検証に使用する Google Cloud リソースです。認証者には、イメージのダイジェストに署名して証明書を作成するために署名者が使用した秘密鍵に対応する公開鍵が含まれています。Binary Authorization 施行者は、デプロイ時に認証者を使用して、デプロイを許可するイメージを、デプロイ前に作成された検証可能な証明書を持つイメージに限定します。
認証者の管理は、公開鍵と秘密鍵のペアも管理するセキュリティ オペレーション担当者が担当する場合がよくありますが、通常、署名者は、デプロイ可能なイメージを作成し、秘密鍵で署名を行い、デプロイ前に証明書を作成するソフトウェア エンジニア、DevOps QA 担当者、コンプライアンス担当者になります。
認証者には次のものがあります。
- 対応する Container Analysis メモ
- 署名者が証明書の作成に使用した秘密鍵に対応する 1 つ以上の暗号公開鍵。
「証明書を要求」ルールを含むポリシーを設定する場合は、イメージをデプロイする準備ができていることを確認する人またはプロセスに、認証者を追加する必要があります。認証者を追加するには、Google Cloud Console、gcloud インターフェース、または Binary Authorization REST API を使用します。
認証者と証明書を作成して使用する方法をご覧ください。
暗号鍵
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 ストレージをチェックし、必要な証明書が存在するかどうか確認します。