Tanzu Mission Controlで学ぶOpen Policy Agent Part-2

2020-09-30 · 5 分で読めます

この記事はTanzu Mission Controlで学ぶ Open Policy Agentシリーズです。

シリーズ

第一回 : 概要
第二回 : TMCのOpen Policy Agentを遊んでみる < いまここ
第三回 : TMCのOpen Policy Agentを解剖する
第四回 : TMCからOPAポリシーを自作する

はじめに

前回の記事にあるよう、TMCを使うとOPAが気軽に試せます。今回はまずこの機能を試してみます。

TMCでは、OPAをSecurity Policyとして実装しています。この中身をみていきます。

準備編

TMCの環境が必要になります。アカウントをもっていない場合、HOL（Hands on Lab)が一番早く用意できます。環境はこの記事をベースに確認してください。

Tanzu Mission Controlを気軽に試す(via HOL)

テストには、前回でも紹介したよう、悪意のあるPodの権限昇格の手段として使えた以下のYamlを使います。


apiVersion: v1
kind: Pod
metadata:
  name: verybad
spec:
  hostPID: true
  containers:
    - name: verybad
      image: alpine
      command: [ "sleep", "3600" ]
      securityContext:
          privileged: true

まず、特にセキュリティ設定していないk8sで走らせると、想定通りですが、動いてしまいます。

% kubectl create -f verybadsecurity.yaml
pod/verybad created

検証

とりあえず試す

まずTMC側でPolicyを有効にします。

左ペインの[ Policies ] > [Assignment] > [ Security ]タブを選択します。

対象のClusterGroupを選択して[ CREATE SECURITY POLICY ]を選択します。

その他のオプションは、のちに説明します。とりあえず、これで[ Create Policy ] で作ってしまいます。

すると、さきほど起動が成功してしまった、昇格権限をもったPodがいっぱい怒られて、上がらなくなります。

これのすごい点がClusterAdminで上の操作をしていますが、それでもTMCで設定したPodの設定が有効になります。さらに、新しくNamespaceを作ってもそれが有効になります。以下の例ではfooというネームスペースを作った場合にも有効になっていることを確認しています。

Namespaceに例外を追加する

例えば、特定のNamespaceで例外を作りたいとします。もう一度TMCの画面にもどって、作成したポリシーの一番下のExclude specific namespaces (optional)を選択します。

ここに、除外するネームスペースのルールをいれます。

先ほどのつくったfooのネームスペースにこのLabelを追加します。

kubectl label namespace foo security=false

この状態でもう一度違反Podをfooネームスペースで作ると以下のように今度はエラーにならず実行できます。Labelに該当しないネームスペースは引き続き失敗します。

Introducing Policy Insights!

さらにすごいのが、最近のリリースで追加されたPolicy Insightsの機能。もし、ポリシー違反の状態でうごいているものがあった場合に画面一覧で表示する機能があります。

あれ？で、OPAは？

さて、ここまでOPAが一切登場していないですが、実はこの裏で動いていた技術こそがOPAでした。 TMCのSecurity Policyを有効にした環境では、以下のconstrainttemplatesCRDが作られます。

kubectl get constrainttemplates
NAME                                              AGE
vmware-system-tmc-allowed-host-paths-v1           23m
vmware-system-tmc-allowed-users-v1                23m
vmware-system-tmc-allowed-volumes-v1              23m
vmware-system-tmc-block-host-namespace-v1         23m
vmware-system-tmc-block-privilege-escalation-v1   23m
vmware-system-tmc-block-privileged-container-v1   23m
vmware-system-tmc-enforce-host-networking-v1      23m
vmware-system-tmc-linux-capabilities-v1           23m

さらに、上のリソース名で、kubectl getをすると同じく何かみえてきます。

kubectl get vmware-system-tmc-block-host-namespace-v1
NAME             AGE
tmc.cgp.strict   24m

この設定がOPAに関連します。

さて、より細かい話は次回にとっておきたいと思います。いまはTMCを使うとOPAが裏で動いてなんかすごいことをしている程度に思ってください。

まとめ

TMCのSecurity Policyを使うと不正な権限昇格を阻止できる
Policy Insightsを使うと、ポリシー違反を一目でわかる
TMCは裏でOPAをつかっている

次回は「TMCのOpen Policy Agentを解剖する」です。