RegulaとOpen Policy AgentでKubernetes Podを保護する

Fugueはこのたび、Infrastructure as Codeのチェックに使えるオープンソースのポリシーエンジンRegulaで、Kubernetesをサポートしました。Regulaでは、TerraformやCloudFormationのファイルに含まれるセキュリティおよびコンプライアンス違反をチェックできるだけでなく、KubernetesのYAMLマニフェストもチェックできるようになりました。

このブログでは、Kubernetesマニフェストに対してRegulaを実行し、安全でないPodを検出して保護する方法を紹介します。さらに、最終版のマニフェストは、Kubernetes環境を保護するための推奨事項をまとめたCIS Kubernetes Benchmark v1.6.1にも準拠します。

準備はいいですか？それでは始めましょう。

はじめに

まず、Regulaをインストールします。Homebrewをお使いの場合は、次のコマンドを実行してください。

brew tap fugue/regula
brew install regula

または、お使いのプラットフォーム向けのビルド済みバイナリをインストールするか、DockerでRegulaを実行することもできます。

この記事の執筆時には、Regula v1.5.0を使用しました。

次に、GitHub gistを開いて「Download ZIP」ボタンを選択し、ファイルを展開します。ファイルは2つあります。

• pod.yaml：準拠していない、安全でないKubernetesマニフェスト

• pod-compliant.yaml：同じマニフェストを準拠させ、安全にしたもの

各違反の修正方法を説明する際、pod.yamlを手動で編集しながら進めることも、保護済みのpod-compliant.yamlを参照することもできます。

マニフェストを確認する

このマニフェストでは、helloという名前のシンプルなPodを定義しています。Podには、同じくhelloという名前のBusyBoxコンテナが1つ含まれています。

apiVersion: v1
kind: Pod
metadata:
  name: hello
spec:
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']

安全でないようには見えませんよね？念のため、Regulaを実行して確認してみましょう。

Regulaを実行する

ターミナルで、ダウンロードしたファイルがあるディレクトリに移動します。スペースを節約するため--format compactフラグを付けて、pod.yamlに対してRegulaを実行します。

regula run pod.yaml --format compact

次のような出力が表示されます。

大変です！このPodは、十分に安全とは言えません。Regulaによって6つの問題が見つかりました。

ご心配なく。すべて修正できます！各違反の内容を確認し、修正していきましょう。

違反を修正する

サービスアカウントトークン

違反：「サービスアカウントの「automountServiceAccountToken」は「false」に設定する必要があります [中]」

CIS Kubernetes v1.6.1の管理策：5.1.6「必要な場合に限り、サービスアカウントトークンがマウントされるようにする」

重要な理由：サービスアカウントトークンは、クラスター内のプロセスからKubernetes APIサーバーへのリクエストを認証するために使われます。デフォルトでは、すべてのPodにサービスアカウントトークンが自動でマウントされます。しかし、攻撃者が1つのPodを侵害できた場合、そのサービスアカウントトークンを使って権限昇格攻撃を仕掛け、クラスター全体を掌握する可能性があります。

そのため、ワークロードがAPIサーバーとの通信を必要としない場合は、サービスアカウントトークンの自動マウントを避けるのが最善です。これは最小権限の原則にも沿っています。

修正方法：Podの仕様でautomountServiceAccountTokenをfalseに設定します。

spec:
  automountServiceAccountToken: false

pod-compliant.yamlの10行目を参照してください。

rootユーザー

違反：「Podで、コンテナをrootユーザーとして実行しない [中]」

CIS Kubernetes v1.6.1の管理策：5.2.6「rootコンテナの許可を最小限にする」

重要な理由：必要もないのにrootとして実行するのは、ほとんどの場合よくありません。コンテナがrootとして実行されていると、コンテナからの脱出が発生した際に、攻撃者がホストシステムのroot権限を取得するおそれがあります。

修正方法：0はrootを意味するため、Podの仕様でrunAsUserに0以外のユーザーIDを設定します。

spec:
  securityContext:
    runAsUser: 1001

pod-compliant.yamlの8～9行目を参照してください。

ここで指定するユーザーがDockerイメージ内に定義されていることを確認してください。多くの場合、DockerfileでLinuxのuseraddコマンドを実行してroot以外のユーザーを作成し、ユーザーIDをUSERコマンドで指定します。

Linuxのケイパビリティ

次の2つの違反は密接に関連しており、この例では同じ方法で解決できます。

違反：「Podで、NET_RAWケイパビリティを使ってコンテナを実行しない [中]」

CIS Kubernetes v1.6.1の管理策：5.2.7「NET_RAWケイパビリティを持つコンテナの許可を最小限にする」

違反：「Podで、デフォルトのケイパビリティが割り当てられたコンテナを実行しない [中]」

CIS Kubernetes v1.6.1の管理策：5.2.9「ケイパビリティが割り当てられたコンテナの許可を最小限にする」

重要な理由：Linuxコンテナを実行すると、プロセスに特定のroot権限を付与する、デフォルトのケイパビリティセットが割り当てられます。NET_RAWケイパビリティは特に危険です。攻撃者がこれを使ってネットワークトラフィックを盗み見たり、偽装したアドレスでIPトラフィックを生成したりする可能性があるためです。

多くのサービスでは、デフォルトのケイパビリティすべてを必要としません。まずすべて削除し、必要なものだけを戻すのが得策です。この例では何も戻しませんが、add: ["FOO"]で追加できます。

修正方法：コンテナにsecurityContextを設定し、capabilitiesでdrop: ["ALL"]を指定すると、2つの違反をまとめて修正できます（必要に応じてdrop: ["NET_RAW"]とすれば、5.2.7のみを修正できます）。

spec:
  containers:
    - name: hello
      securityContext:
        capabilities:
          drop: ["ALL"]  

pod-compliant.yamlの15～17行目を参照してください。

seccompプロファイル

違反：「Podのseccompプロファイルを「docker/default」に設定する必要があります [中]」

CIS Kubernetes v1.6.1の管理策：5.7.2「Pod定義でseccompプロファイルがdocker/defaultに設定されていることを確認する」

重要な理由：Linuxのセキュアコンピューティングモード(seccomp)は、許可するシステムコール（syscall）を制限します。Dockerなどのコンテナランタイムでは通常、複数のシステムコールを無効にするデフォルトのseccompプロファイルが用意されており、セキュリティを高められます。

docker/defaultプロファイルはKubernetes 1.11で非推奨になっているため、CIS Kubernetes v1.6.1の記載にかかわらず、代わりにruntime/defaultを使うことをおすすめします。

修正方法：Kubernetesのバージョンによっていくつか方法がありますが、v1.19より前のバージョンでは、Podのメタデータにseccomp.security.alpha.kubernetes.io/podアノテーションを指定します。

metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

pod-compliant.yamlの5～6行目を参照してください。

セキュリティコンテキスト

違反：「Podとコンテナにセキュリティコンテキストを適用する必要があります [中]」

CIS Kubernetes v1.6.1の管理策：5.7.3「Podとコンテナにセキュリティコンテキストを適用する」

重要な理由：Podまたはコンテナのセキュリティコンテキストでは、アクセス制御、Linuxケイパビリティ、権限に関するさまざまなセキュリティ設定を定義します。ご自身のユースケースに関連するパラメーターを設定することが重要です。

修正方法：セキュリティコンテキストはPodレベルまたはコンテナレベルで設定できます。両方のレベルで重複する設定が定義されている場合は、コンテナの設定がPodの設定を上書きします。

先ほど、rootとしての実行を防ぐためにPodレベルでsecurityContextを設定し、すべてのケイパビリティを削除するためにコンテナレベルでも設定しました。そのため、この違反はすでに修正されています。

pod-compliant.yamlの8～9行目と15～17行目を参照してください。

Regulaをもう一度実行する

6つの違反をすべて修正できました。保護されたPodについて、Regulaがどのような結果を出すか確認しましょう。更新したマニフェストは、pod-compliant.yamlとして用意しています。

apiVersion: v1
kind: Pod
metadata:
  name: hello
  annotations:
    seccomp.security.alpha.kubernetes.io/pod: "runtime/default" 
spec:
  securityContext:
    runAsUser: 1001
  automountServiceAccountToken: false
  containers:
    - name: hello
      image: busybox
      command: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 3600']
      securityContext:
        capabilities:
          drop: ["ALL"]

pod.yamlを編集しながら進めていた場合は、先ほどと同じコマンドを実行してください。

regula run pod.yaml --format compact

pod.yamlを編集していない場合（もちろん問題ありません！）は、pod-compliant.yamlマニフェストに対してRegulaを実行してください。

regula run pod-compliant.yaml --format compact

すると、次のように表示されます。

No problems found. Nailed it.

やりました！安全でなかったPodについてRegulaが検出した問題を、すべて修正できました。お疲れさまでした！

次のステップ

Regulaを使ってKubernetesマニフェストを保護する方法を学んだら、Kubernetesセキュリティのベストプラクティスについても確認しましょう。

Regulaの詳細はregula.devをご覧ください。すべてのKubernetesルールを確認できます。また、組織に該当しない場合は、ルールの結果を例外扱いにする方法やルールを完全に無効にする方法もご覧いただけます。