ポリシー YAML リファレンス

このページには、YAML 形式の Binary Authorization ポリシーのリファレンス情報が記載されています。コマンドライン インターフェースを使用してポリシーを構成する場合は、この仕様に準拠した YAML 形式のファイルを編集します。YAML 形式のポリシーの例については、サンプル ポリシーをご覧ください。

ポリシー YAML ファイルの形式は次のとおりです。

name: projects/<PROJECT_ID>/policy
admissionWhitelistPatterns:
- namePattern: <MATCHING_PATTERN>
- ...
globalPolicyEvaluationMode: <GLOBAL_EVAL_MODE>
defaultAdmissionRule:
  <ADMISSION_RULE>
clusterAdmissionRules:
  <CLUSTER_SPECIFIER>:
    <ADMISSION_RULE>
  ...

ノード

YAML 形式の最上位ノードは次のとおりです。

ノード 説明 必須
name ポリシーの名前。 ○
admissionWhitelistPatterns 常にデプロイを許可するコンテナ イメージを指定します。 ×
globalPolicyEvaluationMode Google 所有のシステム イメージを除外するグローバル ポリシーを適用するかどうかを指定します。 ×
defaultAdmissionRule クラスタ固有のルールがないすべてのクラスタに適用されるルールを指定します。 ○
clusterAdmissionRules 特定のクラスタに適用するルールを指定します。 ×

name

name ノードには、次の形式でポリシーの名前が含まれます。

name: projects/PROJECT_ID/policy

ここで、PROJECT_ID はポリシーが定義されている Google Cloud Platform（GCP）プロジェクトの名前です。

例:

name: projects/example-project/policy

admissionWhitelistPatterns

admissionWhitelistPatterns は、ポリシーの適用対象外のコンテナ イメージの許可リストを指定します。Container Registry または namePattern サブノード内の別のレジストリにあるイメージへのパスを指定します。

admissionWhitelistPatterns:
  - namePattern: MATCHING_PATTERN
  - ...

MATCHING_PATTERN は、完全に一致する単一イメージへのパスを表します。ワイルドカード記号（*）を使用した場合は、パターンに一致する任意のイメージへのパスになります。ワイルドカードは末尾にのみ使用できます。パターン内の他の場所には使用できません。gcr.io/n*x は使用できませんが、gcr.io/nginx* は使用できます。また、ワイルドカードは / に一致しません。例:gcr.io/nginx* は gcr.io/nginx@latest と一致しますが、gcr.io/nginx/image とは一致しません。

次の例では、よく使用される Google Kubernetes Engine（GKE）イメージと gcr.io/example-project/helloworld にあるイメージを含むレジストリをポリシーの除外イメージのリストに追加します。

admissionWhitelistPatterns:
  - namePattern: gcr.io/google_containers/*
  - namePattern: gcr.io/google-containers/*
  - namePattern: k8s.gcr.io/*
  - namePattern: gke.gcr.io/*
  - namePattern: gcr.io/stackdriver-agents/*
  - namePattern: gcr.io/example-project/helloworld

許可リストのパターン

レジストリの場所が指定したパスと一致するコンテナ イメージをすべて許可リストに登録するには:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/*

特定のイメージを許可リストに登録するには:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld

現在タグ付けされているバージョンを許可リストに登録するには:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld:latest
  - namePattern: gcr.io/example-project/helloworld:my-tag
  - namePattern: gcr.io/example-project/helloworld:v1.*

特定のバージョンのイメージをダイジェストで許可リストに登録するには:

admissionWhitelistPatterns:
  ...
  - namePattern: gcr.io/example-project/helloworld@sha256:77b0b75136b9bd0fd36fb50f4c92ae0dbdbbe164ab67885e736fa4374e0cbb8c

globalPolicyEvaluationMode

グローバル ポリシー評価モードは、ユーザーとして構成したポリシーを評価する前に、Binary Authorization がシステム ポリシーを評価するポリシー設定です。システム ポリシーは Google から提供されるものです。Google 管理のシステム イメージのリストは以降のポリシー評価から除外されます。この設定を有効にすると、GKE で必要なイメージはポリシーの適用でブロックされません。admissionWhitelistPatterns を含め、グローバル ポリシーはユーザー ポリシーより先に評価されます。

Google 管理のすべてのシステム イメージを許可するには、globalPolicyEvaluationMode プロパティを ENABLE に設定します。

globalPolicyEvaluationMode: ENABLE

グローバル ポリシー評価モードを無効にするには:

globalPolicyEvaluationMode: DISABLE

defaultAdmissionRule

defaultAdmissionRule には、ポリシーのデフォルト ルールを指定します。デフォルト ルールは、対象のすべてのコンテナ イメージに適用される制約を定義するルールです。ただし、クラスタ固有の独自のルールがあるものは除きます。デフォルト ルールは、ADMISSION_RULE コレクションで指定します。

defaultAdmissionRule:
  ADMISSION_RULE

次の例は、指定した認証者によって承認されたコンテナ イメージのみをデプロイするデフォルト ルールを示しています。必要なすべての認証者がイメージを承認していない場合、Binary Authorization はデプロイをブロックし、監査ログに書き込みます。

defaultAdmissionRule:
  evaluationMode: REQUIRE_ATTESTATION
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  requireAttestationsBy:
  - projects/example-project/attestors/secure-build

clusterAdmissionRules

clusterAdmissionRules は、ポリシーでクラスタ固有のルールを宣言します。これらのルールの制約は、指定したクラスタにのみ適用されます。Binary Authorization がクラスタ固有のルールをデプロイに適用した場合、デフォルト ルールは考慮されません。デフォルト ルールと同様に、ADMISSION_RULE コレクションを使用してクラスタ固有のルールを指定します。

clusterAdmissionRules:
  CLUSTER_SPECIFIER:
    ADMISSION_RULE

CLUSTER_SPECIFIER は、ルールが適用されるクラスタのリソース ID です。形式は location.name です（例: us-east1-a.prod-cluster）。

次の例は、指定した認証者によって承認されたコンテナ イメージのみをデプロイするクラスタ固有のルールを示しています。

clusterAdmissionRules:
  us-east1-a.prod-cluster:
    evaluationMode: REQUIRE_ATTESTATION
    enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
    requireAttestationsBy:
    - projects/example-project/attestors/secure-build
    - projects/example-project/attestors/prod-qualified

ノード コレクション

ADMISSION_RULE

ADMISSION_RULE は、ルールの制約を指定するノードのコレクションです。形式は次のとおりです。

evaluationMode: EVAL_MODE
enforcementMode: ENFORCEMENT_MODE
requireAttestationsBy:
- ATTESTOR
- ...

defaultAdmissionRule と clusterAdmissionRule の両方がこのコレクションを参照します。

evaluationMode

evaluationMode は、コンテナ イメージをデプロイするかどうかを評価するために Binary Authorization が実行するオペレーションを指定します。使用できる値は次のとおりです。

  • ALWAYS_ALLOW: このルールで評価されるイメージのデプロイを常に許可します。
  • ALWAYS_DENY: このルールで評価されるイメージのデプロイを常に拒否します。
  • REQUIRE_ATTESTATION: デプロイする前に、1 人以上の認証者がリリースを承認する必要があります。

evaluationMode が REQUIRE_ATTESTATION の場合、requireAttestationsBy で必要な認証者への参照を提供する必要があります。

enforcementMode

enforcementMode は、コンテナ イメージがルールで定義された制約を遵守していない場合に、Binary Authorization が実行するアクションを指定します。使用できる値は次のとおりです。

  • ENFORCED_BLOCK_AND_AUDIT_LOG: デプロイをブロックして監査ログに書き込みます。
  • DRYRUN_AUDIT_LOG_ONLY: 遵守していないイメージのデプロイを許可し、違反の詳細を監査ログに書き込みます。

ほとんどの本番環境のルールでは、ENFORCED_BLOCK_AND_AUDIT_LOG 適用モードが使用されます。DRYRUN_AUDIT_LOG_ONLY は主に、ポリシーを有効にする前に環境内でテストする場合に使用します。

requireAttestationsBy

requireAttestationsBy には、コンテナ イメージをデプロイする前にリリースを承認する必要がある認証者を指定します。これは REQUIRE_ATTESTATION ルールでのみ必要です。このノードの形式は次のとおりです。

requireAttestationsBy:
  - projects/PROJECT_ID/attestors/ATTESTOR_NAME
  - ...

PROJECT_ID は認証者が定義されているプロジェクトの名前で、ATTESTOR_NAME はリリースに署名する必要がある認証者の名前です。

次の例は、認証者の指定方法を示しています。

requireAttestationsBy:
- projects/example-project/attestors/secure-build
- projects/example-project/attestors/prod-qualified