Policy Controller のインストール

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

このページは、監査または適用のために自動化を行い、維持することで、クラウド プラットフォーム内で実行されているすべてのリソースが組織のコンプライアンス要件を確実に満たすようにする IT 管理者と運用担当者を対象としています。Google Cloud のコンテンツで参照する一般的なロールとタスク例の詳細については、一般的な GKE Enterprise ユーザーロールとタスクをご覧ください。

Policy Controller は、Google Kubernetes Engine(GKE)Enterprise エディションを使用している場合に利用できます。詳細については、Google Kubernetes Engine(GKE)Enterprise エディションの料金をご覧ください。

準備

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

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

  3. 必要な API を有効にします。

    Console

    1. GKE Enterprise API を有効にします

      GKE Enterprise API を有効にする

    2. Policy Controller API を有効にします。

      Policy Controller API を有効にする

    gcloud

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

    gcloud services enable anthos.googleapis.com anthospolicycontroller.googleapis.com
    
  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. VMware またはベアメタルで Google Distributed Cloud を使用している場合は、ユーザー クラスタに Policy Controller をインストールしてください。管理クラスタに Policy Controller をインストールすることはできません。

Policy Controller のインストール

バージョン 1.16.0 以降で Google Cloud CLI を使用している場合は、Policy Controller を直接インストールして管理できます(こちらをおすすめします)。ConfigManagement オブジェクトを使用して Policy Controller を構成することはおすすめしません。

Console

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

  1. Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。

    [ポリシー] に移動

  2. [Policy Controller を構成] をクリックします。

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

    1. [ポリシー バンドルを追加/編集] セクションで、関連する切り替えをクリックしてポリシー バンドルを含めるか除外します。
    2. [Policy Controller の構成を編集] セクションで、次の操作を行います。

      1. Mutation Webhook を有効にするには、[Mutation Webhook を有効にする] チェックボックスをオンにします。この機能には、Autopilot クラスタとの互換性がありません。
      2. [監査間隔] ボックスに、2 つの連続する監査の間隔(秒単位)を入力します。
      3. [Exemptible namespaces] ボックスに、名前空間のリストを入力します。Policy Controller は、これらの Namespace 内のオブジェクトを無視します。

        ベスト プラクティス:

        システム Namespace を除外して、環境でエラーが発生しないようにします。名前空間を除外する手順と、Google Cloud サービスによって作成された一般的な名前空間のリストについては、名前空間を除外するページをご覧ください。

      4. 参照制約を有効にするには、[現在評価されているオブジェクト以外のオブジェクトを参照する制約テンプレートを有効にする] チェックボックスをオンにします。

      5. [バージョン] リストで、使用する Policy Controller のバージョンを選択します。

    3. [保存] をクリックします。

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

  5. 確認のダイアログで [確認] をクリックします。以前に Policy Controller を有効にしていない場合は、[確認] をクリックして anthospolicycontroller.googleapis.com API を有効にし、クラスタに Policy Controller をインストールします。

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

    1. [設定] タブで、[フリートの設定に同期] をクリックします。
    2. [フリート内のクラスタ] リストで、同期するクラスタを選択し、[フリートの設定に同期] をクリックします。このオペレーションが完了するまでには数分かかる場合があります。

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

gcloud policyController

次のコマンドを実行して 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 を実行してください。

Policy Controller のフリートレベルの設定を設定するには、次の操作を行います。

  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 ...
    
    ベスト プラクティス:

    システム Namespace を除外して、環境でエラーが発生しないようにします。名前空間を除外する手順と、Google Cloud サービスによって作成された一般的な名前空間のリストについては、名前空間を除外するページをご覧ください。

  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
    

gcloud ConfigManagement

  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...
    
    ベスト プラクティス:

    システム Namespace を除外して、環境でエラーが発生しないようにします。名前空間を除外する手順と、Google Cloud サービスによって作成された一般的な名前空間のリストについては、名前空間を除外するページをご覧ください。

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

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

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

    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 のインストール後に、正常に完了したことを確認できます。

Console

次の手順を完了します。

  1. Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。

    [ポリシー] に移動

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

gcloud policyController

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

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 です。

Config Sync での Policy Controller の操作

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

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

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

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

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

Namespace を適用の対象外にする

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

リソースの変更

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 はビルド番号です。

Policy Controller をアップグレードする

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

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

コンソール

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

    [ポリシー] に移動

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

gcloud

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

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

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

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

Policy Controller のアンインストール

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

Console

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

  1. Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。

    [ポリシー] に移動

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

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

gcloud policyController

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.enabledfalse に設定します。

  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 を追加します。

ConfigManagement Operator を削除する

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

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

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

    kubectl delete configmanagement --all
    

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

    • ConfigManagement Operator によってクラスタに作成された ClusterRole と ClusterRoleBinding がすべてクラスタから削除されます。
    • ConfigManagement Operator によってインストールされたアドミッション コントローラの構成がすべて削除されます。
    • git-creds Secret を除き、config-management-system Namespace の内容が削除されます。1.9.0 以降の Policy Controller のバージョンの場合は、config-management-operator Deployment と config-management-operator Pod も削除されます。ConfigManagement Operator は、config-management-system Namespace なしでは機能しません。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 のリソース リクエスト

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

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

次のステップ