このページでは、Policy Controller のインストール方法について説明します。Policy Controller は、セキュリティ、規制、ビジネスルールに関するポリシーへのクラスタの遵守状況を確認し、監査とポリシーの適用を行います。
Policy Controller は、Google Kubernetes Engine(GKE)Enterprise エディションを使用している場合に利用できます。詳細については、Google Kubernetes Engine(GKE)Enterprise エディションの料金をご覧ください。インストールする前に、レポートを作成して Policy Controller を試すことができます。この試用は無料です。
始める前に
作業を始める前に、次のことを確認してください。
- この手順で使用する
gcloud
、gsutil
、kubectl
、nomos
コマンドを含む Google Cloud CLI をインストールして初期化します。すでに gcloud CLI をインストールしている場合は、gcloud components update
を実行して最新のバージョンを取得する。Cloud Shell を使用する場合、Google Cloud CLI がプリインストールされています。 - オープンソースの Open Policy Agent Gatekeeper がクラスタにインストールされていないことを確認します。インストールされている場合は、Policy Controller をインストールする前に Gatekeeper をアンインストールします。
Policy Controller API を有効にします。
1.14.x 以降の Kubernetes バージョンを実行するクラスタを作成するか、このクラスタにアクセスできることを確認します。1.14.x よりも前のバージョンの Kubernetes で Policy Controller が実行されているように見える場合もありますが、プロダクトは正しく動作しません。
Google Cloud CLI を使用して Policy Controller を構成する場合は、今すぐフリートにクラスタを登録してください。Google Cloud コンソールを使用する場合は、Policy Controller のインストールの際にクラスタを登録します。
GKE 接続クラスタを使用している場合は、AKS クラスタに Azure ポリシー アドオンがないことを確認し、
control-plane
キーを使用した名前空間へのラベル付けは行わないようにしてください。VMware またはベアメタルで Google Distributed Cloud を使用している場合は、ユーザー クラスタに Policy Controller をインストールしてください。管理クラスタに Policy Controller をインストールすることはできません。
Policy Controller をインストールする
バージョン 1.16.0 以降で Google Cloud CLI を使用している場合は、Policy Controller を直接インストールして管理できます(こちらをおすすめします)。また、ConfigManagement オブジェクトでインストールして管理することもできます。
コンソール
Google Cloud コンソールで Policy Controller をインストールするには、次の手順を行います。
- Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。
[add Policy Controller をインストールする] を選択します。
[Policy Controller のインストール] ペインで、次のいずれかのインストール オプションを選択します。
フリート内のすべてのクラスタに Policy Controller をインストールするには:
[フリートにインストールする] を選択したままにします。
プロジェクトにフリートがない場合は、次の手順でフリートを作成できます。
フリートがない場合は、フリートの名前を選択します。
[Policy Controller を有効にする] を選択します。
個々のクラスタに Policy Controller をインストールするには:
[個々のクラスタにインストールする] を選択します。
[使用可能なクラスタ] テーブルで、Policy Controller をインストールするクラスタを選択します。
[Policy Controller を有効にする] を選択します。
Policy Controller の [設定] タブにリダイレクトされます。Policy Controller がクラスタにインストールされて構成されると、ステータス列に「インストール済み check_circle」と表示されます。これには数分かかることがあります。
gcloud Policy Controller
次のコマンドを実行して Policy Controller を有効にします。
gcloud container fleet policycontroller enable \
--memberships=MEMBERSHIP_NAME
さらにいくつかのフィールドを設定して Policy Controller を構成できます。たとえば、一部の Namespace を適用から除外するように Policy Controller に指示できます。構成可能なフィールドの一覧については、Policy Controller の Google Cloud CLI のドキュメントをご覧になるか、gcloud container fleet policycontroller enable --help
を実行してください。
gcloud ConfigManagement
新しい
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...
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
: プロジェクト IDCONFIG_YAML_PATH
:apply-spec.yaml
ファイルのパス
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 のインストール後に、正常に完了したことを確認できます。
コンソール
次の手順を完了します。
- Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。
- [設定] タブのクラスタ テーブルで、[Policy Controller のステータス] 列を確認します。インストールに成功すると、ステータスは「インストール済みcheck_circle」になります。
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 をインストールすると、制約テンプレート ライブラリがデフォルトでインストールされます。このインストールが完了するまでに数分かかることがあります。テンプレート ライブラリが正常に完了したことを確認できます。
コンソール
次の手順を完了します。
- Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。
- [設定] タブのクラスタ テーブルで、[インストール済みのバンドル] 列に表示されている番号を選択します。[ポリシー コンテンツのステータス] ペインで、テンプレート ライブラリが正常にインストールされると、ステータスは「インストール済み check_circle」になります。
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 のフリートレベルのデフォルトを構成する手順は次のとおりです。
コンソール
Google Cloud コンソールで、[機能マネージャー] ページに移動します。
[ポリシー] ペインで [構成] をクリックします。
フリートレベルの設定を確認します。フリートに登録した新しいクラスタすべてに、これらの設定が継承されます。
省略可: デフォルトの設定を変更するには、[フリートの設定をカスタマイズ] をクリックします。表示されるダイアログで、次の操作を行います。
- [ポリシー バンドルを追加 / 編集] セクションで、関連する切り替えをクリックしてポリシー バンドルを含めるか除外します。
- [Policy Controller の構成を編集] セクションで、次の操作を行います。
- Mutation Webhook を有効にするには、[Mutation Webhook を有効にする] チェックボックスをオンにします。この機能には、Autopilot クラスタとの互換性がありません。
- [監査間隔] ボックスに、2 つの連続する監査の間隔(秒単位)を入力します。
- [Exemptible namespaces] ボックスに、Namespace のリストを入力します。Policy Controller は、これらの Namespace 内のオブジェクトを無視します。
- 参照制約を有効にするには、[現在評価されているオブジェクト以外のオブジェクトを参照する制約テンプレートを有効にする] チェックボックスをオンにします。
- [バージョン] リストで、使用する Policy Controller のバージョンを選択します。
- [保存] をクリックします。
[構成] をクリックします。
確認のダイアログで [確認] をクリックします。以前に Policy Controller を有効にしていない場合は、[確認] をクリックして
anthospolicycontroller.googleapis.com
API を有効にします。省略可: 既存のクラスタをデフォルト設定に同期します。
- [フリート内のクラスタ] リストで、同期するクラスタを選択します。
- [フリートの設定に同期] をクリックし、表示された確認ダイアログで [確認] をクリックします。このオペレーションには数分かかることがあります。
gcloud
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 ...
フリートにデフォルト構成を適用します。
gcloud container fleet policycontroller enable \ --fleet-default-member-config=fleet-default.yaml
構成が適用されたことを確認するには、次のコマンドを実行します。
gcloud container fleet policycontroller describe
フリートレベルのデフォルト構成を削除するには、次のコマンドを実行します。
gcloud container fleet policycontroller enable \ --no-fleet-default-member-config
Config Sync での Policy Controller の操作
Config Sync で Policy Controller を使用する場合、Config Sync によって同期される信頼できる情報源(Git リポジトリなど)に保存されているリソースに関する次の操作に注意する必要があります。
制約テンプレート ライブラリを無効にしない限り、テンプレート ライブラリの一部でもある制約テンプレートを同期することはできません。
gatekeeper-system
Namespace に保存されている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
はビルド番号です。
Policy Controller をアップグレードする
Policy Controller をアップグレードする前に、リリースノートでバージョン間での変更点の詳細を確認してください。
Policy Controller のアップグレード手順は以下のとおりです。
コンソール
- Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。
- [設定] タブで、バージョンをアップグレードするクラスタの横にある [edit 構成を編集] を選択します。
- [Policy Controller の構成を編集] メニューを開きます。
- [バージョン] プルダウン リストから、アップグレードするバージョンを選択します。
- [保存] をクリックします。
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 を無効にするには、次の操作を行います。
- Google Cloud コンソールで [GKE Enterprise] に移動し、[体制の管理] の下にある [ポリシー] を選択します。
- [設定] タブのクラスタ テーブルで、[構成の編集] 列にある [編集 edit] を選択します。
- クラスタペインを下にスクロールし、[Policy Controller について] メニューを開きます。
- [Policy Controller のアンインストール] を選択します。
- 確認ダイアログの手順に沿って、[確認] を選択してアンインストールを確定します。
Policy Controller がアンインストールされると、ステータスの列に「インストールされていません do_not_disturb_on」と表示されます。
gcloud Policy Controller
Policy Controller をアンインストールするには、次のコマンドを実行します。
gcloud container fleet policycontroller disable \
--memberships=MEMBERSHIP_NAME
MEMBERSHIP_NAME
は、Policy Controller を無効にする登録済みクラスタのメンバーシップ名に置き換えます。複数のメンバーシップを指定する場合は、カンマ区切りで指定します。
gcloud ConfigManagement
Policy Controller をアンインストールするには:
apply-spec.yaml
ファイル内の ConfigManagement Operator の構成を編集し、policyController.enabled
をfalse
に設定します。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 を削除するには、次のコマンドを実行します。
クラスタから 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 をインストールしたユーザーによって追加されたものとされるため、削除されずに残ります。これらのコンポーネントを削除する方法については、次のステップで説明します。
git-creds
Secret を維持する必要がある場合は、ここで行います。kubectl -n config-management-system get secret git-creds -o yaml
config-management-system
名前空間を削除します。kubectl delete ns config-management-system
config-management-monitoring
名前空間を削除します。kubectl delete ns config-management-monitoring
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 | 100 m | 256 Mi |
次のステップ
- Policy Controller の詳細を確認する。
- Policy Controller のバンドルの詳細を確認する。
- 制約を作成する方法を学ぶ。
- Policy Controller のトラブルシューティング。