こんにちは。SB C&Sの村上です。
この記事では、Tanzu Mission Control (TMC) のPolicy機能 によるKubernetesクラスタのPolicy管理を紹介します。

KubernetesではさまざまなPolicyが提供されており、これらを活用することで一貫性のある制御を行えます。たとえば、Podやコンテナ内で起動されるプロセスのセキュリティ設定、コンテナイメージの取得ルール、Podの通信制限などがPolicyを用いて制御できます。

ただしクラスタ数が増加すると、Policyの適用対象も増加するため、クラスタごとのPolicy調整などにより管理負荷が増加する可能性があります。

こうした課題に対処するために、TMCのPolicy機能を活用することで、ひとつのコンソール上から効率的にPolicyを管理することができます。
以下はSecurity Policyの作成画面になりますが、TMCのコンソールを用いてGUIでのPolicy作成やパラメータ設定を行い、クラスタへ適用できます。

また、複数クラスタに対して、一括での同じPolicyの適用や、Policy違反状況の可視化なども行うことができます。

　

Policy機能詳細

ここからは、利用可能なPolicyの種類や適用範囲、可視化などについて説明します。

Policyの種類

TMCでは現在7種類のPolicyに対応しており、それらを使い分けて利用する形となります。

Access Policy

Access Policyでは、TMC管理下の各リソースに対して誰がどこまでアクセスできるかを制御します。
例えば、各クラスタの操作権限やそもそもの閲覧権限等を制御できます。

Security Policy

Security Policyでは、クラスタ上に展開されたPodが実行できる機能を制御できます。
例えば、特権コンテナの利用可否やSELinux機能、さらに利用可能なVolumeType (ConfigMapやPVC等)を細かく制御できます。 

Image Registry Policy

Image Registry Policyでは、Pullするコンテナイメージを制御できます。
例えば、latestタグのついているイメージの拒否や、特定の名前やタグがついているコンテナイメージのみを許可するような制御ができます。

Network Policy

Network Policyでは、TMCの管理対象とした名前空間にて、Pod間通信やクラスタ外との通信を制御できます。
例えば、指定したラベルがついたPodへの通信はすべて拒否、特定IPからの通信のみ許可する、といった制御ができます。
注意点として、こちらを利用する場合はクラスタで使用しているCNI (Container Network Interface) がNetwork Policyの機能に対応している必要があります。

Quota Policy

Quota Policyでは、クラスタ内の名前空間ごとで利用可能なリソースの量を制限できます。
例えば、特定の名前空間のリソース消費量が大きくなりすぎないように、CPUとメモリとストレージのそれぞれに最大値を設定できます。

Mutation Policy

Mutation Policyは、Podがクラスタにデプロイされる際にそのプロパティを変更できます。
例えばPodに対して、デプロイ前にPod Securityの設定やLabel、Annotationを追加できます。

Custom Policy

Custom Policyは、より特殊な条件のPolicyが必要な場合に利用できるものです。
これまでに紹介したPolicyで満たせない要件に対して、OPA (Open Policy Agent)というPolicyエンジンを利用して、自身で用意したテンプレートからPolicyを作成できます。なお、テンプレートの作成には、RegoというPolicy言語が必要となります。

なお、以下のようにTMCには標準でいくつかテンプレートが用意されています。

　

Policyの適用範囲

TMCのPolicyを適用する範囲については、単一のクラスタ、複数のクラスタ、組織全体といったように柔軟に指定できます。

実際は使用するPolicyの種類に応じて、TMC内の管理単位である「クラスタグループ」と「ワークスペース」のどちらを軸に適用できるかが変わります。ここからは、それぞれのパターンとPolicyの関係について紹介します。

パターン①（クラスタグループ軸）

クラスタグループは、TMCに登録してあるKubernetesクラスタをグループ分けするものです。

こちらのパターンのPolicyは、クラスタグループか、単一クラスタの単位で指定できます。クラスタグループに適用した場合はその配下のクラスタすべてに適用されます。

このパターンに該当するPolicyは以下となります。

• Security Policy
• Quota Policy
• Mutation Policy
• Custom Policy

例えば、以下図のような構成でクラスタグループ1にPolicyを適用した場合は、クラスタ1とクラスタ2にも同じPolicyが適用される形となります。

パターン②（ワークスペース軸）

ワークスペースとは、TMCに登録してある名前空間をグループ分けするものです。

こちらはパターンのPolicyは、ワークスペース単位で指定します。クラスタ単位での指定等はできず、あらかじめワークスペース作成と、そこへの名前空間の割り当てが必要です。

該当Policyは以下となります。

• Image Registry Policy
• Network Policy

例えば、以下図のような構成でワークスペース1に適用した場合は、名前空間1と名前空間2がPolicyの対象となります。

パターン③（クラスタグループ軸 / ワークスペース軸 の両方）

Access Policyのみ、クラスタグループ軸とワークスペース軸の両方で割り当てられます。

Policy Insights機能

こちらの機能では、Policyの順守状況を可視化できます。どのクラスタに、どのPolicyが適用されていて、なぜ違反となっているか、といったことが確認できます。

例えば以下画像では、Image registryで1件、Securityで3件の違反が検知されていることが確認できます。
さらにImage registryの違反の詳細を確認すると、nginxコンテナイメージにlatestタグがついているのが原因と一目でわかります。

　

Policy機能のデモンストレーション

最後に、Policyの作成から違反を検知してInsights機能で確認するまでの一連の流れを紹介します。

以下のような形で、「特権コンテナが作成された場合に警告を出す」というSecurity Policyを適用したtkgs-01クラスタ上で、特権コンテナを起動するPodをデプロイしてみます。

※tkgs-01はTMCに登録済みの状態としてあります

TMCにて[Policies]-[Assignments]-[Security]を開き、[Cluster groups]から[tkgs-01]を選択して、[CREATE SECURITY POLICY]をクリックします。

以下パラメータを選択して、[CREATE POLICY]をクリックします。

• Security template: Custom
• Policy name: privileged-container-warn
• トグルボタン: [Allow privileged containers]をオフ(拒否)、他はオン(許可)のまま
• Enforcement action: Warn

続いて、特権コンテナを利用するPodをデプロイします。
今回は以下のYAMLファイルを利用して、「nginx」という名前のコンテナを含むPodを起動します。

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    securityContext:
      privileged: true # 特権コンテナを有効
  restartPolicy: Always

PowerShellにて、前述のYAMLファイルをapplyします。

$ kubectl apply -f nginx_pod.yaml 

TMCにて[Insights]を確認すると、Securityのカテゴリで1件の違反が確認できます。
詳細を確認すると、先ほど作成したPolicyにて違反が検知できています。

　

まとめ

今回はTMCのPolicy機能の紹介をしました。
Kubernetes運用でのPolicy管理は、特に大規模になればなるほどしっかりと管理者側にて制御したいものですが、その分管理負荷がとても増加します。
その際にTMCのPolicy機能を用いれば、ひとつのコンソール上からPolicyの適用から検知した違反状況の可視化までを実現できます。またPolicy適用の対象として、組織やクラスタグループなど柔軟な単位を選択できることも大きなメリットであると感じます。