Kubernetes Security for penetration testers

OWASP Fukuoka Meeting #1 の発表資料 https://owasp-kyushu.connpass.com/event/200714/

Transcript

1. Kubernetes Security for penetration testers 攻撃者のための Kubernetes セキュリティ OWASP Fukuoka Meeting #1 / Kohei Morita @mrtc0 / blog.ssrf.in
2. Kohei Morita @mrtc0 GMO Pepabo, inc. セキュリティ対策室 OWASP Fukuoka Chapter Leader https://blog.ssrf.in/ https://container-security.dev/ をちま ちま書いています。
3. Outline ・コンテナと Kubernetes の仕組み ・Kubernetes の Attack Surfaces ・Kubernetes クラスタの守り方 コンテナや Kubernetes をプラットフォームとしたアプリケーションに対する攻 撃の勘所を理解するのが目的
4. Docker を知っている🙋
5. Linux コンテナの仕組みを知っている🙋 コンテナとホストのリソース分離技術について知っている
6. Linux コンテナのセキュリティを知っている 🙋
7. Kubernetes を知っている🙋
8. Kubernetes セキュリティを知っている🙋
9. # コンテナと Kubernetes の仕組み
10. Linux Container • LXC や Docker などを筆頭にホストマシンから隔離した環境でプロセス を動かす仕組み • 隔離 = chroot よりは強固だが VM よりは弱い • Namespace や cgroup などリソースを分離する既存の技術を組み合 わせることで実現している
11. Container Runtime Architecture
12. CRI / OCI • CRI (Container Runtime Interface) … OCI を制御するための規格化 されたインターフェイスを持つ • OCI (Open Container Initiative) … CRI から受け取った命令を元にコ ンテナを実行する主体 • それぞれの実装を切り替えることを可能とした高い拡張性が特徴
13. リソース分離のための主要素 • Namespace • Capability • seccomp • cgroup • LSM • chroot / pivot_root
14. Namespace ・名前空間内のプロセスに対して、そのプロセスがあたかも専用のグローバル リソースを持っているかのように見せる仕組み ・PID, Network, Mount, IPC, User, UTS などが提供されている ubuntu@sandbox ~> docker run --rm -it ubuntu:20.10 sleep 100 ubuntu@sandbox ~> sudo ls -l /proc/(pidof sleep)/ns/pid lrwxrwxrwx 1 root root 0 Feb 14 19:45 /proc/15112/ns/pid -> 'pid:[4026532224]' ubuntu@sandbox ~> ls -l /proc/self/ns/pid lrwxrwxrwx 1 ubuntu ubuntu 0 Feb 14 19:43 /proc/self/ns/pid -> 'pid:[4026531836]'
15. 主要な Namespace • UTS Namespace ◦ ホスト名の分離 • PID Namespace ◦ プロセスの分離 • Network Namespace ◦ ネットワークの分離 • IPC Namespace ◦ IPC の分離 • Mount Namespace ◦ マウントテーブルの分離
16. Capability • setuid で root を与えるのではなく、最小権限のみを与える ◦ 1024 以下のポートで Listen するには CAP_NET_BIND_SERVICE が必要 ◦ chroot(2) を呼び出すには CAP_SYS_CHROOT が必要 root@sandbox /h/ubuntu# nc -lp 80 -v Listening on [0.0.0.0] (family 0, port 80) ^C⏎ root@sandbox /h/ubuntu# capsh --drop="cap_net_bind_service" -- -c 'nc -lp 80 -v' nc: Permission denied
17. cgroup • メモリの使用量やプロセス数などを制限する目的で利用される ubuntu@sandbox ~> docker run --rm -it ubuntu:20.10 bash root@sandbox /h/ubuntu# CID=6b2304c98dcdd530fd8dca2b936097c849126eee05f500b3e3d57ac5218b75cb root@sandbox /h/ubuntu# cat /sys/fs/cgroup/pids/docker/$CID/pids.max max root@sandbox /h/ubuntu# echo 10 > /sys/fs/cgroup/pids/docker/$CID/pids.max root@sandbox /h/ubuntu# cat /sys/fs/cgroup/pids/docker/$CID/pids.max 10 root@6b2304c98dcd:/# :(){ :|: & };: bash: fork: retry: Resource temporarily unavailable bash: fork: retry: Resource temporarily unavailable
18. seccomp • Firefox や Snap などを始め様々なアプリケーションで利用されている • コンテナではホスト側に影響を与えかねないシステムコールを禁止してい る ◦ kexec_file_load ◦ mount ◦ ptrace Docker のデフォルトのプロファイルについては https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile を参照
19. seccomp bypass https://asciinema.org/a/jTJmL1VVyCcFk387isJXPOENk
20. LSM • SELinux / AppArmor などが利用されている • seccomp や Capability などが破られた場合に最後の砦として機能す る ◦ 具体的には procfs などへのアクセス制御をしている • コンテナごとに適用するプロファイルを生成することで、より堅牢にするこ とができる
21. chroot と pivot_root • コンテナのファイルシステムをホストと分離する • chroot は条件によって脱獄可能なので、多くのコンテナランタイムでは pivot_root が使われている ◦ Mount Namespace と組み合わせることで古い(ホストの) root ディレクトリにアクセスできなくなる
22. User Namespace / ID Mapping • 非特権コンテナで利用される機能 • User Namespace を分離した際に、ホストとコンテナでのユーザーID / グループID の mapping を行う • もし Break Out されても非特権ユーザーの権限となる
23. # コンテナのセキュリティ
24. Sensitive File Mount • コンテナから読み書きできてはいけないファイルが多数ある ◦ 主に /proc や /sys 配下 ◦ ReadOnly にする, bind-mount するなどの対応が必要 • /var/run/docker.sock などもマウントすると Docker API 経由でホスト 側で任意のコマンドが実行できる
25. Privileged Container • 特権(Privileged Container)は非常に強力な権限を持っている ◦ CAP_SYS_ADMIN, CAP_SYS_PTRACE など ◦ mount(2) の呼び出しによるファイルシステムマウント • Privileged Container への侵入 = ホストへの侵入と同じ • call_usermodehelper_exec() を利用したホスト側へのエスケープ
26. Breakout with uevent_helper https://asciinema.org/a/KbToy20RnDlycB0tkh4v8HGhP
27. # Kubernetes の仕組み
28. Kubernetes とは • 複数のマシン(ノード)でクラスタを作り、その上でコンテナを管理するオー ケストレーションツール • manifest と呼ばれる YAML や JSON 等でコンテナの状態を定義し、そ れを維持してくれる宣言的なアーキテクチャ • 拡張性が高く様々なデプロイ方式をサポートしているのが特徴
29. クラスタの構成
30. クラスタの構成 https://kubernetes.io/ja/docs/concepts/overview/components/
31. クラスタの構成 • (構成に依存するが) 実際には他のアプリケーションも動作している ◦ CoreDNS などの DNS Server ◦ Prometheus や cAdvisor などのリソース監視ツール ◦ ダッシュボード (kube-dashboard / Grafana) ◦ td-agent などの Log Collector • これらすべて Pod で動いていることが多い
32. # Kubernetes Attack Surfaces
33. Kubernetes Attack Matrix https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
34. • コンテナから Node への Break out ◦ コンテナの設定不備 (Privileged Container など) ◦ カーネルの脆弱性 (Dirty CoW など) ◦ ランタイムの脆弱性 (CVE-2019-5736 など) Runtime Security
35. Image Vulnerability • イメージに含まれるパッケージの脆弱性 • クレデンシャルを誤ってイメージに含めてしまう • レジストリの不正操作
36. ServiceAccount • Mount している ServiceAccount Token を利用して、その権限でクラスタを 操作する
37. API • Kubernetes API と kubelet API の2つがある • 認証不要な場合、クラスタの制御や Information Leak が可能 • パブリッククラウドだと Metadata API から Information Leak も可能
38. Secret • Base64 でエンコードされた値となっている ◦ うっかり git push しちゃった...... というケースも
39. Networking • デフォルトでは Pod 間同士で通信し放題 • そのため、Pod への侵入等からさらなる権限昇格につながる
40. Tiller Pod • Helm v2 では Helm Server (Tiller) を通して機能する • Tiller はデフォルトで認証設定がされていないため、Pod から接続できた 場合、任意のリソースをクラスタに作成できる ◦ ServiceAccount に権限がなくても、これを利用して RBAC を新規 に作成し、cluster-admin に権限昇格できる in-pod:/# helm --host tiller-deploy.kube-system.svc.cluster.local:44134 install /pwnchart
41. etcd • Secret やクラスタの情報を格納している KVS • クライアント証明書を使って接続するのが普通だが...
42. Metadata API • クラウドプロバイダーが提供しているエンドポイント 169.254.169.254 • IAM のクレデンシャルや Kubernetes クラスタに必要な環境変数などが 格納されている • アプリケーションレイヤからは SSRF などを利用して窃取されるケースも 考えられる
43. EKS • インスタンス情報の取得 • VPC, SecurityGroup 情報の取得 • ECR リポジトリからイメージの取得 https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html
44. GKE • kube-env に bootstrap 処理で仕様される証明書等を保持 • そのクレデンシャルを使ってクラスタにノードとして Join できる • これを利用して kubelet になりすますことが可能
45. # How to Kubernetes cluster
46. How to protect Kubernetes cluster • Kubernetes はコンポーネントが多いので、守るところも多い • Pod が一つ侵害されるとクラスタ全体が危険になることがある
47. 基本の対策まとめ ServiceAccount Token … 自動でマウントしない。RBAC を適切に設定する。 Unauthorized API … API に認証を設定する。 etcd … 認証を設定する。暗号化を施す。 Secret の管理 … 暗号化を施したり Hashicorp Vault や KMS などの利用。 Network … Network Policy や Service Mesh を利用した mTLS などの利用。 Metadata API … クラウドプロバイダに保護策が提示されているのでそれに従う。 Runtime … Gatekeeper でポリシーに従わない Pod を作成させない。 ※ gVisor や Kata Container など、より分離レベルの強いランタイムへの変更。
48. Service Mesh
49. Envoy CSRF Filter • Envoy Sidecar で CSRF 対策ができる ◦ Origin ヘッダと Referrer ヘッダを見る実装 ◦ https://www.envoyproxy.io/docs/envoy/latest/start/sandb oxes/csrf ◦ https://www.envoyproxy.io/docs/envoy/latest/configuratio n/http/http_filters/csrf_filter.html
50. Authorization with Open Policy Agent // authz.rego package httpapi.authz import input default allow = false allow { some username input.method == "GET" input.path = ["user", username] input.user == username } ❯ curl --user alice:password localhost:5000/user/alice Success: user alice is authorized ❯ curl --user alice:password localhost:5000/user/bob Error: user alice is not authorized to GET url /user/bob
51. Training • 守るべきところが増えたので、トレーニングも重要 ◦ CKS (Certified Kubernetes Security Specialist) の取得 ◦ https://github.com/madhuakula/kubernetes-goat ◦ https://github.com/kubernetes-simulator/simulator ◦ https://github.com/mrtc0/kubectf
52. Sec ができることはガードレールを作ること • 崖から落ちないような仕組みを用意する ◦ Gatekeeper や Open Policy Agent による保護 ◦ Dev / Ops / Sec でポリシーを育てていく ◦ CI での manifest のテスト • CIS Benchmark や NIST SP 800-190 などへの準拠 ◦ 「そこまでするの...」という内容もあるので、脅威分析をした上で、妥 協点を決めるのが良い
53. インシデントへの対応 • Kubernetes API の auditd ログを取得しておく ◦ リソースの作成や削除などを追跡できるように • falco などを用いたコンテナの監査 ◦ auditd では Pod / コンテナ名などを取得できない ◦ セキュリティイベント発生時に自動でノードを切り離すなど ◦ https://github.com/falcosecurity/kubernetes-response-en gine • ノードのセキュリティモニタリングにも falco や Wazuh を利用
54. まとめ • コンテナは多層防御の仕組みを取っている • Kubernetes は複雑で守るところも多く、攻撃を受けた場合の影響が深 刻になるケースがある • しかし、これまでとは少し違うアプローチの対策も取れて、Security に加 えて Observability の向上も期待できる • OPA を始めとしたポリシー言語は波が来ている
55. 参考文献 • イラストでわかる Docker と Kubernetes / 技術評論社 • Docker / Kubernetes 開発・運用のためのセキュリティ実践ガイド / マ イナビ出版 • コンテナ型仮想化概論 / カットシステム