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ポッドセキュリティポリシーは、Kubernetesポッドのアクセス権限を制限する、ポッド仕様のセキュリティ上重要な側面を制御するクラスタレベルのリソースです。 たとえば、Kubernetes PSPを使用して制限することができます：
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セキュリティポリシーを実装することは、クラスタ内に他の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セキュリティに関しては、ベストプラクティスがあります。
しかし、Kubernetesセキュリティのベストプラクティスに基づいてPod Security ポリシーを構築することは、現実的ではない可能性もあります。
いくつかの実例を挙げてみましょう：
パフォーマンス上の理由から、IPC_LOCK機能が必要な場合があります。これはCassandra、MySQLなどのマルチプロセスアプリケーションで見ることができます。モニタリングおよびセキュリティコンポーネントは通常、必要なものすべてを見るために拡張アクセス権限を必要とします。たとえば、PacketBeatはネットワークトラフィックをキャプチャするためにNET_ADMIN機能を必要とします。コンテナーセキュリティ製品であるSysdigは、システムコールをキャプチャし、ホストネームスペースにアクセスして、モニターおよび保護したい実行中のすべてのコンテナーを確認するために、カーネルにフックする特権コンテナーとして実行する必要があります。 Delveを使ってGolangアプリケーションをデバッグしたい場合は、ポッドにSYS_PTRACE機能を追加する必要があります。
本番セキュリティポリシーは、実行されるソフトウェアの要件とその構築方法によって異なります。 Kubernetes Podセキュリティポリシーの実装は、DevSecOpsとソフトウェア開発チームの共同作業です。両者は、Kubernetesセキュリティのベストプラクティスを、さまざまなアプリケーションからのさまざまなアクセス特権の要件に適応させる方法を考え出す必要があります。
Kubernetes Podセキュリティポリシーアドバイザ（kube-psp-advisor）は、Sysdig InspectやFalcoのようなSysdigのオープンソースツールです。 kube-psp-advisorは、deployment、daemontset、replicasetsなどのKubernetesリソースから既存のセキュリティコンテキストをスキャンし、適用したい参照モデルとしてクラスタ全体のすべてのリソースに対して自動的にPodセキュリティポリシーを生成します。
kube-psp-advisorはさまざまな属性を調べて、推奨されるPodセキュリティポリシーを作成します。
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セキュリティポリシーを簡単でわかりやすいプロセスで実行できるため、アプリケーションの要件に合わせて実行したり、アクセス権限を最小限に抑えるために細かく設定したりできます。