ブログ

kube-psp-advisorでKubernetes Pod Securityを有効にする

Google Cloudとコンテナの継続的なセキュリティ

本文の内容は、2019年2月6日にSysdigのKaizhe Huangが投稿したブログ(https://sysdig.com/blog/enable-kubernetes-pod-security-policy/)を元に日本語に翻訳・再構成した内容となっております。

Kubernetes Podセキュリティポリシーは、Kubernetesで最高のセキュリティ対策を実施するためのメカニズムです。 このチュートリアルでは、kube-psp-advisorを使用してクラスター全体でKubernetes Podセキュリティポリシーを有効にし、運用中のKubernetesに適応型のきめ細かいセキュリティポリシーを構築するという実際的な課題に対処する方法を説明します。

例)Kubernetes Pod Security ポリシーとは?

Kubernetesポッドセキュリティポリシーは、Kubernetesポッドのアクセス権限を制限する、ポッド仕様のセキュリティ上重要な側面を制御するクラスタレベルのリソースです。 たとえば、Kubernetes PSPを使用して制限することができます:

  • 特権コンテナの実行
  • コンテナが実行されているユーザー
  • ホストプロセスまたはネットワーク名前空間にアクセスする
  • ホストファイルシステムにアクセスする
  • Linux機能、SeccompまたはSELinuxプロファイル

Pod Security ポリシーの定義は次のようになります:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
    name: example
spec:
  allowedCapabilities:
  - NET_ADMIN
  - IPC_LOCK
  allowedHostPaths:
  - pathPrefix: /dev
  - pathPrefix: /run
  - pathPrefix: /
  fsGroup:
    rule: RunAsAny
  hostNetwork: true
  privileged: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - hostPath
  - secret

このPSPは非常に緩い状態です:NET_ADMINおよびIPC_LOCK機能、mount /、/ devand /をホストおよびKubernetesシークレットボリュームから実行できるようにします。 ファイルシステムのグループIDや補足グループを強制しません。 任意のユーザーとしてコンテナを実行し、ホストネットワークのネームスペースにアクセスし、特権コンテナとして実行することを許可します。 SELinuxポリシーは適用されません。

Kubernetes Pod Security ポリシーの有効化方法

Kubernetes Podセキュリティポリシーを実装することは、クラスタ内に他のKubernetesリソースを作成するのと同じです:

$ kubectl apply -f example-psp.yaml

次に、Podセキュリティポリシーが正しく作成されたことを確認します。

$ kubectl get psp

出力は下記のようになります:

NAME      PRIV     CAPS                           SELINUX    RUNASUSER   FSGROUP    SUPGROUP   READONLYROOTFS   VOLUMES
example   true     NET_ADMIN, IPC_LOCK            RunAsAny   RunAsAny    RunAsAny   RunAsAny   false            hostPath,secret

しかし、ポッドセキュリティポリシーがどのようなものであるべきかをどのように把握すると良いのでしょうか? 必要としないものすべてを制限しますか? 制限が厳しすぎる、または緩すぎるポリシーになる可能性もあります。

Kubernetes Pod Security ポリシーのベストプラクティスと本番環境での実装の課題

Kubernetesセキュリティに関しては、ベストプラクティスがあります。

  1. 特権コンテナを実行させない
  2. コンテナーをrootとして実行しない
  3. ホストネームスペースへのアクセスを許可しない
  4. Linuxの機能を制限する
  5. ...

しかし、Kubernetesセキュリティのベストプラクティスに基づいてPod Security ポリシーを構築することは、現実的ではない可能性もあります。

いくつかの実例を挙げてみましょう:

パフォーマンス上の理由から、IPC_LOCK機能が必要な場合があります。これはCassandra、MySQLなどのマルチプロセスアプリケーションで見ることができます。モニタリングおよびセキュリティコンポーネントは通常、必要なものすべてを見るために拡張アクセス権限を必要とします。たとえば、PacketBeatはネットワークトラフィックをキャプチャするためにNET_ADMIN機能を必要とします。コンテナーセキュリティ製品であるSysdigは、システムコールをキャプチャし、ホストネームスペースにアクセスして、モニターおよび保護したい実行中のすべてのコンテナーを確認するために、カーネルにフックする特権コンテナーとして実行する必要があります。 Delveを使ってGolangアプリケーションをデバッグしたい場合は、ポッドにSYS_PTRACE機能を追加する必要があります。

本番セキュリティポリシーは、実行されるソフトウェアの要件とその構築方法によって異なります。 Kubernetes Podセキュリティポリシーの実装は、DevSecOpsとソフトウェア開発チームの共同作業です。両者は、Kubernetesセキュリティのベストプラクティスを、さまざまなアプリケーションからのさまざまなアクセス特権の要件に適応させる方法を考え出す必要があります。

kube-psp-advisorで簡単にKubernetes Securityポリシーを作成する

Kubernetes Podセキュリティポリシーアドバイザ(kube-psp-advisor)は、Sysdig InspectやFalcoのようなSysdigのオープンソースツールです。 kube-psp-advisorは、deployment、daemontset、replicasetsなどのKubernetesリソースから既存のセキュリティコンテキストをスキャンし、適用したい参照モデルとしてクラスタ全体のすべてのリソースに対して自動的にPodセキュリティポリシーを生成します。

kube-psp-advisorはさまざまな属性を調べて、推奨されるPodセキュリティポリシーを作成します。

  • allowPrivilegeEscalation
  • allowedCapabilities
  • allowedHostPaths
  • hostIPC
  • hostNetwork
  • hostPID
  • privileged
  • readOnlyRootFilesystem
  • runAsUser
  • Volume

Using kube-psp-advisor is really simple. First clone and build the project:

kube-psp-advisorは、非常にシンプルです。 まずプロジェクトのクローンを作成してビルドします。

$ git clone https://github.com/sysdiglabs/kube-psp-advisor
$ cd kube-psp-advisor && make build

これで使用する準備が整いました。 kube-psp-advisorはいくつかのパラメータを受け取ることができます:

--namespace デフォルトでは、Podセキュリティポリシーはクラスタ全体のリソースに対して生成されます。 このフラグを使用すると、専用のネームスペースのポリシーが分析および生成されるだけです。

--report. 各Kubernetesセキュリティ機能を利用しているリソース、たとえば、どのPod、デプロイなどがhostIPC、hostNetworkなどを使用しているかを表示します。

--kubeconfig。 kubeconfigファイルへの絶対パス。デフォルトは$ HOME / .kube / configです。

kube-psp-advisorはkubeconfigファイルをロードし、kubernetesクラスタAPIサーバーに接続してから、次のように生成されたPSPを標準出力に出力するスキャンを実行します。

$ ./kube-psp-advisor --namespace=psp-test
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  creationTimestamp: null
  name: pod-security-policy-20181130114734
spec:
  allowedCapabilities:
  - SYS_ADMIN
  - NET_ADMIN
  allowedHostPaths:
  - pathPrefix: /bin
  - pathPrefix: /tmp
  - pathPrefix: /usr/sbin
  - pathPrefix: /usr/bin
  fsGroup:
    rule: RunAsAny
  hostIPC: false
  hostNetwork: false
  hostPID: false
  privileged: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - hostPath
  - configMap
  - secret

最後に、生成されたKubernetes Podセキュリティポリシーを確認して適用します。

$ ./kube-psp-advisor --namespace psp-test > psp-test.yaml && cat psp-test.yaml
$ kubectl apply -f psp-test.yaml

どのように構築されたかについて詳細な情報を得るには、--reportフラグを使います。

$ ./kube-psp-advisor --namespace=psp-test --report | jq .podSecuritySpecs
{
  "hostIPC": [
    {
      "metadata": {
        "name": "busy-rs",
        "kind": "ReplicaSet"
      },
      "namespace": "psp-test",
      "hostPID": true,
      "hostMetwork": true,
      "hostIPC": true,
      "volumeTypes": [
        "configMap"
      ]
    },
    {
      "metadata": {
        "name": "busy-job",
        "kind": "Job"
      },
      "namespace": "psp-test",
      "hostIPC": true,
      "volumeTypes": [
        "hostPath"
      ],
      "mountedHostPath": [
        "/usr/bin"
      ]
    }
  ],
  "hostNetwork": [
    {
      "metadata": {
        "name": "busy-rs",
        "kind": "ReplicaSet"
      },
      "namespace": "psp-test",
      "hostPID": true,
      "hostMetwork": true,
      "hostIPC": true,
      "volumeTypes": [
        "configMap"
      ]
    },
    {
      "metadata": {
        "name": "busy-pod",
        "kind": "Pod"
      },
      "namespace": "psp-test",
      "hostMetwork": true,
      "volumeTypes": [
        "hostPath",
        "secret"
      ],
      "mountedHostPath": [
        "/usr/bin"
      ]
    }
  ],
  "hostPID": [
    {
      "metadata": {
        "name": "busy-deploy",
        "kind": "Deployment"
      },
      "namespace": "psp-test",
      "hostPID": true,
      "volumeTypes": [
        "hostPath"
      ],
      "mountedHostPath": [
        "/tmp"
      ]
    },
    {
      "metadata": {
        "name": "busy-rs",
        "kind": "ReplicaSet"
      },
      "namespace": "psp-test",
      "hostPID": true,
      "hostMetwork": true,
      "hostIPC": true,
      "volumeTypes": [
        "configMap"
      ]
    }
  ]
}

結論

Kubernetes Pod Security ポリシーを構築するのは難しいかもしれません。 この記事に記載されているすべてのKubernetesセキュリティベストプラクティスに従って、すべてのアプリケーションが機能するとも限りません。 しかし、それはPSPの実装を無視してスキップするべきであるという意味ではありません。 特定のPodが追加のアクセスを必要とする場合でも、それ以上のアクセス権限を制限するPod Security ポリシーを実装できることは間違いなく優れたセキュリティアプローチです。 これは実際にはほとんどの実稼働環境で見られるものです。

kube-psp-advisorを使用すると、Kubernetes Podセキュリティポリシーを簡単でわかりやすいプロセスで実行できるため、アプリケーションの要件に合わせて実行したり、アクセス権限を最小限に抑えるために細かく設定したりできます。

Sysdigに関するお問い合わせはこちらから

最近の投稿

カテゴリー

アーカイブ

ご質問・お問い合わせはこちら

top