Policy Controller のインストール

このページでは、Policy Controller のインストール方法について説明します。Policy Controller は、セキュリティ、規制、ビジネスルールに関するポリシーへのクラスタの遵守状況を確認し、監査とポリシーの適用を行います。

Google Kubernetes Engine（GKE）Enterprise エディションを使用している場合は、Policy Controller を使用できます。詳細については、Google Kubernetes Engine（GKE）Enterprise エディションの料金をご覧ください。また、インストールする前に、レポートを作成して Policy Controller を試すことができます。この試用は無料です。

注: Policy Controller が実行されていないと、Policy Controller Webhook の開始がエラーとなります。これは、コントローラがダウンしている間（アップグレード中など）にクラスタ オペレーションの妨害を回避するためです。コントローラが利用可能になると、制約を遵守していないリソースが監査ログに記録されます。

注意: Policy Controller がすでに含まれているため、これらの処理は Config Controller によって作成されたクラスタでは使用しないでください。詳細については、Config Controller の概要をご覧ください。

準備

作業を始める前に、次のことを確認してください。

1. この手順で使用する gcloud、gsutil、kubectl、nomos コマンドを含む Google Cloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、gcloud components update を実行して最新のバージョンを取得します。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。
2. オープンソースの Open Policy Agent Gatekeeper がクラスタにインストールされていないことを確認します。インストールされている場合は、Policy Controller をインストールする前に Gatekeeper をアンインストールします。

3. GKE Enterprise API を有効にします。

   GKE Enterprise API を有効にする

4. 1.14.x 以降の Kubernetes バージョンを実行するクラスタを作成するか、このクラスタにアクセスできることを確認します。1.14.x よりも前のバージョンの Kubernetes で Policy Controller が実行されているように見える場合もありますが、プロダクトは正しく動作しません。

5. クラスタを登録するユーザーに必要な IAM ロールを付与します。

6. Google Cloud CLI を使用して Policy Controller を構成する場合は、今すぐフリートにクラスタを登録してください。Google Cloud コンソールを使用する場合は、Policy Controller のインストールの際にクラスタを登録します。

7. GKE アタッチ クラスタを使用している場合は、AKS クラスタに Azure ポリシー アドオンがないことを確認し、control-plane キーによる名前空間へのラベル付けは行わないようにしてください。

8. GKE on VMware または Google Distributed Cloud Virtual for Bare Metal を使用している場合は、ユーザー クラスタに Policy Controller をインストールしていることを確認します。Policy Controller は管理クラスタにインストールできません。

Policy Controller のインストール

Note: Google Cloud コンソールまたは Google Cloud CLI を使用して Config Sync をインストールした場合、後で kubectl コマンドを使用して構成を変更することはできません。

バージョン 1.16.0 以降で Google Cloud CLI を使用している場合は、Policy Controller を直接インストールして管理する（推奨）ことも、ConfigManagement オブジェクトでインストールして管理することもできます。

コンソール

Google Cloud コンソールで Policy Controller をインストールするには、次の手順を行います。

1. Google Cloud コンソールで、[体制管理] セクションの GKE Enterprise [ポリシー] ページに移動します。

   [ポリシー] に移動

2. [ Policy Controller をインストール] を選択します。

3. [Policy Controller のインストール] ペインで、次のインストール オプションのいずれかを選択します。

   • フリート内のすべてのクラスタに Policy Controller をインストールするには:

     1. [フリートにインストールする] を選択したままにします。

        フリートがプロジェクトにない場合は、次のステップでフリートを作成できます。

     2. フリートがまだない場合は、フリートの名前を選択します。

     3. [Policy Controller を有効にする] を選択します。

   • 個々のクラスタに Policy Controller をインストールするには:

     1. [Install on individual clusters] を選択します。

     2. [使用可能なクラスタ] テーブルで、Policy Controller をインストールするクラスタを選択します。

     3. [Policy Controller を有効にする] を選択します。

Policy Controller の [設定] タブにリダイレクトされます。Policy Controller がクラスタにインストールされて構成されると、ステータス列に [インストール済み ] と表示されます。これには数分かかることがあります。

gcloud Policy Controller

次のコマンドを実行して Policy Controller を有効にします。

gcloud container fleet policycontroller enable \
    --memberships=MEMBERSHIP_NAME

さらにいくつかのフィールドを設定すると、Policy Controller を構成できます。たとえば、一部の名前空間を適用から除外するように Policy Controller に指示できます。構成できるフィールドの一覧については、Policy Controller の Google Cloud CLI のドキュメントをご覧になるか、gcloud container fleet policycontroller enable --help を実行してください。

gcloud ConfigManagement

注: gcloud CLI の apply コマンドのファイル形式はバージョン 1.8.0 で変更されました。gcloud CLI を最新バージョンに更新してください。

1. 新しい apply-spec.yaml マニフェストを作成するか、既存のマニフェストを使用して、構成を準備します。既存のマニフェストを使用すると、別のクラスタで使用されているものと同じ設定でクラスタを構成できます。

   新しいマニフェストの作成

   クラスタ用の新しい設定で Policy Controller を構成するには、apply-spec.yaml という名前のファイルを作成して次の YAML ファイルをコピーします。

   # apply-spec.yaml
   
   applySpecVersion: 1
   spec:
     policyController:
       # Set to true to install and enable Policy Controller
       enabled: true
       # Uncomment to prevent the template library from being installed
       # templateLibraryInstalled: false
       # Uncomment to enable support for referential constraints
       # referentialRulesEnabled: true
       # Uncomment to disable audit, adjust value to set audit interval
       # auditIntervalSeconds: 0
       # Uncomment to log all denies and dryrun failures
       # logDeniesEnabled: true
       # Uncomment to enable mutation
       # mutationEnabled: true
       # Uncomment to exempt namespaces
       # exemptableNamespaces: ["namespace-name"]
       # Uncomment to change the monitoring backends
       # monitoring:
       #     backends:
       #     - cloudmonitoring
       #     - prometheus
     # ...other fields...
   

   注: 名前空間を除外する場合は、その名前空間に "admission.gatekeeper.sh/ignore=true" でラベル付けする必要があります。ラベルの適用方法については、名前空間を除外するをご覧ください。

   spec.policyController フィールドを追加し、enabled の値を true に設定する必要があります。他の Policy Controller 機能を有効にすることもできます。しかし、参照制約のサポートは、デフォルトで無効になっています。有効にする前に、結果整合性に関する注意事項を必ず理解してください。

   注: Autopilot クラスタでは、ミューテーションを有効にできません。

   既存のマニフェストを使用

   別のクラスタで使用されている同じ設定でクラスタを構成するには、登録済みクラスタから設定を取得します。

   gcloud alpha container fleet config-management fetch-for-apply \
        --membership=MEMBERSHIP_NAME \
        --project=PROJECT_ID \
        > CONFIG_YAML_PATH
   

   次のように置き換えます。

   • MEMBERSHIP_NAME: 使用する Policy Controller 設定になっている登録済みクラスタのメンバーシップ名
   • PROJECT_ID: プロジェクト ID
   • CONFIG_YAML_PATH: apply-spec.yaml ファイルのパス

2. apply-spec.yaml ファイルを適用します。

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=CONFIG_YAML \
       --project=PROJECT_ID
   

   次のように置き換えます。

   • MEMBERSHIP_NAME: 使用する Policy Controller 設定になっている登録済みクラスタのメンバーシップ名。
   • CONFIG_YAML: apply-spec.yaml ファイルのパスを追加します。
   • PROJECT_ID: プロジェクト ID を追加します。

Pod が作成され、Policy Controller が制約の確認と適用を開始します。

Policy Controller のインストールの確認

Policy Controller のインストール後に、正常に完了したことを確認できます。

コンソール

次の手順を完了します。

1. Google Cloud コンソールで、[体制管理] セクションの GKE Enterprise [ポリシー] ページに移動します。

   [ポリシー] に移動

2. [設定] タブのクラスタ テーブルで、[Policy Controller のステータス] 列を確認します。インストールに成功すると、ステータスは [インストール済み ]になります。

gcloud Policy Controller

次のコマンドを実行します。

gcloud container fleet policycontroller describe --memberships=MEMBERSHIP_NAME

インストールが正常に完了すると、membershipStates: MEMBERSHIP_NAME: policycontroller: state: ACTIVE と表示されます。

gcloud ConfigManagement

次のコマンドを実行します。

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

PROJECT_ID はプロジェクトの ID に置き換えます。

出力は次の例のようになります。

Name          Status  Last_Synced_Token  Sync_Branch  Last_Synced_Time      Policy_Controller
CLUSTER_NAME  SYNCED  a687c2c            1.0.0        2021-02-17T00:15:55Z  INSTALLED

正常にインストールされると、[Policy Controller] 列に INSTALLED のステータスが表示されます。

制約テンプレート ライブラリのインストールの検証

Policy Controller をインストールすると、制約テンプレート ライブラリがデフォルトでインストールされます。インストールが完了するまでに数分かかることがあります。テンプレート ライブラリが正常に完了したことを確認できます。

コンソール

次の手順を完了します。

1. Google Cloud コンソールで、[体制管理] セクションの GKE Enterprise [ポリシー] ページに移動します。

   [ポリシー] に移動

2. [設定] タブのクラスタ テーブルで、[インストール済みのバンドル] 列に表示されている番号を選択します。[ポリシー コンテンツのステータス] ペインで、テンプレート ライブラリが正常にインストールされると、ステータスは [インストール済み ] になります。

gcloud

次のコマンドを実行します。

kubectl get constrainttemplates

出力は次の例のようになります。

NAME                                      AGE
k8sallowedrepos                           84s
k8scontainerlimits                        84s
k8spspallowprivilegeescalationcontainer   84s
...[OUTPUT TRUNCATED]...

個々の制約テンプレートが正しくインストールされている場合、その status.created フィールドは true です。

フリートレベルのデフォルトを構成する

Google Kubernetes Engine（GKE）Enterprise エディションを有効にしている場合は、Policy Controller を有効にしてクラスタのフリートレベルのデフォルトとして構成できます。つまり、クラスタ作成時に登録された Google Cloud クラスタ上の新しい GKE ではすべて、指定した設定のクラスタで Policy Controller が有効になります。フリートのデフォルト構成の詳細については、フリートレベルの機能を管理するをご覧ください。

Policy Controller のフリートレベルのデフォルトを構成するには、次の手順を行います。

コンソール

1. Google Cloud コンソールで、[機能マネージャー] ページに移動します。

   機能マネージャーに移動

2. [ポリシー] ペインで [構成] をクリックします。

3. フリートレベルの設定を確認します。フリートに登録した新しいクラスタすべてに、これらの設定が継承されます。

4. 省略可: デフォルト設定を変更するには、[フリートの設定をカスタマイズ] をクリックします。表示されるダイアログで、次の操作を行います。

   1. [ポリシー バンドルを追加 / 編集] セクションで、関連する切り替えをクリックしてポリシー バンドルを含めるか除外します。
   2. [Policy Controller の構成を編集] セクションで、次の操作を行います。
      1. Mutation Webhook を有効にするには、[Mutation Webhook を有効にする] チェックボックスをオンにします。この機能には、Autopilot クラスタとの互換性がありません。
      2. [監査間隔] ボックスに、2 つの連続する監査の間隔を秒単位で入力します。
      3. [Exemptible namespaces] ボックスに、名前空間のリストを入力します。Policy Controller は、これらの名前空間内のオブジェクトを無視します。
      4. 参照制約を有効にするには、[現在評価されているオブジェクト以外のオブジェクトを参照する制約テンプレートを有効にする] チェックボックスをオンにします。
      5. [バージョン] リストで、使用する Policy Controller のバージョンを選択します。
   3. [保存] をクリックします。

5. [構成] をクリックします。

6. 確認のダイアログで [確認] をクリックします。以前に Policy Controller を有効にしていない場合は、[確認] をクリックすると anthospolicycontroller.googleapis.com API が有効になります。

7. 省略可: 既存のクラスタをデフォルト設定と同期します。

   1. [フリート内のクラスタ] リストで、同期するクラスタを選択します。
   2. [フリートの設定に同期] をクリックし、表示された確認ダイアログで [確認] をクリックします。このオペレーションには数分かかることがあります。

gcloud

1. Policy Controller のデフォルト構成を含む fleet-default.yaml という名前のファイルを作成します。フリートレベルのデフォルトを有効にするには、installSpec フィールドが必要です。この例では、構成可能なオプションを示しています。

   # cat fleet-default.yaml
   
    policyControllerHubConfig:
     installSpec: INSTALL_SPEC_ENABLED 
     # Uncomment to set default deployment-level configurations.
     # deploymentConfigs:
     #   admission:
     #     containerResources:
     #       limits:
     #        cpu: 1000m
     #         memory: 8Gi
     #       requests:
     #         cpu: 500m
     #         memory: 4Gi
     # Uncomment to set policy bundles that you want to install by default.
     # policyContent:
     #   bundles:
     #     cis-k8s-v1.5.1:
     #       exemptedNamespaces:
     #       - "namespace-name"
     # Uncomment to exempt namespaces from admission.
     # exemptableNamespaces:
     # - "namespace-name"
     # Uncomment to enable support for referential constraints
     # referentialRulesEnabled: true
     # Uncomment to disable audit, adjust value to set audit interval
     # auditIntervalSeconds: 0
     # Uncomment to log all denies and dryrun failures
     # logDeniesEnabled: true
     # Uncomment to enable mutation
     # mutationEnabled: true
     # Uncomment to adjust the value to set the constraint violation limit
     # constraintViolationLimit: 20
     # ... other fields ...
   

2. デフォルト構成をフリートに適用します。

   gcloud container fleet policycontroller enable \
     --fleet-default-member-config=fleet-default.yaml
   

3. 構成が適用されたことを確認するには、次のコマンドを実行します。

   gcloud container fleet policycontroller describe
   

4. フリートレベルのデフォルト構成を削除するには、次のコマンドを実行します。

   gcloud container fleet policycontroller enable \
     --no-fleet-default-member-config
   

Config Sync での Policy Controller の操作

Config Sync で Policy Controller を使用する場合、Config Sync によって同期される信頼できる情報源に保存されているリソースに関する次の操作に注意する必要があります。

• 制約テンプレート ライブラリを無効にしない限り、テンプレート ライブラリの一部でもある制約テンプレートを同期することはできません。

  注意: テンプレート ライブラリを無効にすると、制約の依存関係の一部が削除される可能性があります。詳細については、制約を作成するをご覧ください。

• gatekeeper-system 名前空間に保存されている Config リソースを同期する場合は、信頼できる情報源の Config リソースのみを定義する必要があります。gatekeeper-system Namespace を一緒に定義することはできません。

制約テンプレート ライブラリを管理する

制約テンプレート、制約テンプレートに関連付けられた制約、もしくは制約テンプレート ライブラリのアンインストールまたはインストールについては、制約を作成するをご覧ください。

Namespace を適用の対象外にする

Namespace 内のオブジェクトを無視するように Policy Controller を構成できます。詳細については、Policy Controller から Namespace を除外するをご覧ください。

リソースの変更

Policy Controller はミューテーション Webhook としても機能します。詳しくは、リソースを変更するをご覧ください。

Policy Controller のバージョンの表示

Gatekeeper Policy Controller が使用しているバージョンを確認するには、次のコマンドを実行してイメージタグを表示します。

kubectl get deployments -n gatekeeper-system gatekeeper-controller-manager \
  -o="jsonpath={.spec.template.spec.containers[0].image}"

Gatekeeper のビルドに使用される Git タグ（またはハッシュ）と ConfigManagement Operator のバージョン番号がイメージタグに次のように含まれます。

.../gatekeeper:VERSION_NUMBER-GIT_TAG.gBUILD_NUMBER

たとえば、次のイメージの場合:

gcr.io/config-management-release/gatekeeper:anthos1.3.2-480baac.g0

• anthos1.3.2 はバージョン番号です。
• 480baacは Git タグです。
• 0 はビルド番号です。

また、リリース バージョン マトリックスで、対応するマニフェスト、インストール、nomos バイナリ バージョンとともに、すべての Policy Controller バージョンのリストを確認できます。

Policy Controller のアップグレード

Policy Controller をアップグレードする前に、リリースノートでバージョン間で変更点の詳細を確認してください。

注: Config Controller を使用して Policy Controller のインストールと管理を行う場合は、手動でアップグレードする必要はありません。Config Controller はマネージド サービスであるため、Google が自動的にアップグレードします。Config Controller の変更点の詳細については、Config Controller のリリースノートをご覧ください。

Policy Controller をアップグレードする手順は、以下のとおりです。

コンソール

1. Google Cloud コンソールで、[体制管理] セクションの GKE Enterprise [ポリシー] ページに移動します。

   [ポリシー] に移動

2. [設定] タブで、バージョンをアップグレードするクラスタの横にある [ 構成を編集] を選択します。
3. [Policy Controller の構成を編集] メニューを開きます。
4. [バージョン] プルダウン リストから、アップグレードするバージョンを選択します。
5. [保存] をクリックします。

gcloud

次のコマンドを実行します。

gcloud container fleet policycontroller update \
  --version=VERSION \
  --membership=MEMBERSHIP_NAME

次のように置き換えます。

• VERSION: アップグレードするバージョン
• MEMBERSHIP_NAME: クラスタの登録時に選択したメンバーシップ名。メンバーシップ名を確認するには、gcloud container fleet memberships list を実行します。

Policy Controller のアンインストール

クラスタから Policy Controller をアンインストールする手順は次のとおりです。

コンソール

クラスタで Policy Controller を無効にするには、次の操作を行います。

1. Google Cloud コンソールで、[体制管理] セクションの GKE Enterprise [ポリシー] ページに移動します。

   [ポリシー] に移動

2. [設定] タブのクラスタ テーブルで、[構成を編集] 列にある [編集] を選択します。
3. クラスタペインを下にスクロールし、[Policy Controller について] メニューを開きます。
4. [Policy Controller のアンインストール] を選択します。
5. 確認ダイアログの手順に沿って、[確認] を選択してアンインストールを確定します。

Policy Controller がアンインストールされると、ステータスの列に [インストールされていません ] と表示されます。

gcloud Policy Controller

Policy Controller をアンインストールするには、次のコマンドを実行します。

gcloud container fleet policycontroller disable \
  --memberships=MEMBERSHIP_NAME

MEMBERSHIP_NAME は、Policy Controller を無効にする登録済みクラスタのメンバーシップ名に置き換えます。複数のメンバーシップをカンマで区切って指定できます。

gcloud ConfigManagement

Policy Controller をアンインストールするには:

1. apply-spec.yaml ファイル内の ConfigManagement Operator の構成を編集し、policyController.enabled を false に設定します。

2. apply-spec.yaml ファイルに変更を適用します。

    gcloud beta container fleet config-management apply \
        --membership=CLUSTER_NAME \
        --config=CONFIG_YAML \
        --project=PROJECT_ID
   

   次のように置き換えます。

   • CLUSTER_NAME: この構成を適用する登録済みクラスタを追加します。
   • CONFIG_YAML: apply-spec.yaml ファイルのパスを追加します。
   • PROJECT_ID: プロジェクト ID を追加します。

注: Policy Controller をアンインストールすると、クラスタに保存されているすべての制約とテンプレートが削除されます。

ConfigManagement Operator を削除する

ConfigManagement オブジェクトで Policy Controller をインストールした場合は、クラスタから ConfigManagement Operator も削除する必要があります。

ConfigManagement Operator を削除するには、次のコマンドを実行します。

1. クラスタから ConfigManagement オブジェクトを削除します。

   kubectl delete configmanagement --all
   

   このコマンドを実行すると、次のようになります。

   • ConfigManagement Operator によってクラスタに作成された ClusterRole と ClusterRoleBinding がクラスタからすべて削除されます。
   • ConfigManagement Operator によってインストールされたアドミッション コントローラの構成がすべて削除されます。
   • config-management-system 名前空間の内容が削除されます。ただし、git-creds Secret を除外し、1.9.0 以降の Policy Controller、Config Sync、Config Controller のバージョンの場合は、config-management-operator Deployment と config-management-operator Pod を除外します。ConfigManagement Operator は、config-management-system 名前空間なしでは機能しません。ConfigManagement Operator コントローラによって作成または変更された CustomResourceDefinition（CRD）は、それらが作成または変更されたクラスタからすべて削除されます。ConfigManagement Operator の実行に必要な CRD は、Kubernetes の観点からは ConfigManagement Operator をインストールしたユーザーが追加したものとみなされるため、削除されずに残ります。これらのコンポーネントを削除する方法については、次のステップで説明します。

2. git-creds Secret を維持する必要がある場合は、ここで行います。

   kubectl -n config-management-system get secret git-creds -o yaml
   

3. config-management-system 名前空間を削除します。

   kubectl delete ns config-management-system
   

4. config-management-monitoring 名前空間を削除します。

   kubectl delete ns config-management-monitoring
   

5. ConfigManagement CustomResourceDefinition を削除します。

   kubectl delete crd configmanagements.configmanagement.gke.io
   

Policy Controller の RBAC と権限

Policy Controller には、高い特権を持つワークロードが含まれています。これらのワークロードの権限は、Open Policy Agent の Gatekeeper オペレーションのドキュメントで説明されています。

Policy Controller のリソース リクエスト

次の表に、サポートされている各バージョンの Kubernetes リソースの要件を示します。ConfigManagement Operator のリソース リクエストは、ConfigManagement オブジェクトを介して Policy Controller をインストールした場合にのみ適用されます。

1.16

コンポーネント	CPU	メモリ
ConfigManagement Operator	100 m	100 Mi
Policy Controller	100 m	256 Mi

1.15

コンポーネント	CPU	メモリ
ConfigManagement Operator	100 m	100 Mi
Policy Controller	100 m	256 Mi

1.14

コンポーネント	CPU	メモリ
ConfigManagement Operator	100 m	100 Mi
Policy Controller	100 m	256 Mi

次のステップ

• Policy Controller の詳細を確認する。
• Policy Controller のバンドルの詳細を確認する。
• 制約を作成する方法を学ぶ。
• Policy Controller のトラブルシューティング。