Slide 1
Slide 1 text
Kubernetes Security for
penetration testers
攻撃者のための Kubernetes セキュリティ
OWASP Fukuoka Meeting #1 / Kohei Morita @mrtc0 / blog.ssrf.in
Slide 2
Slide 2 text
Kohei Morita @mrtc0
GMO Pepabo, inc. セキュリティ対策室
OWASP Fukuoka Chapter Leader
https://blog.ssrf.in/
https://container-security.dev/ をちま
ちま書いています。
Slide 3
Slide 3 text
Outline
・コンテナと Kubernetes の仕組み
・Kubernetes の Attack Surfaces
・Kubernetes クラスタの守り方
コンテナや Kubernetes をプラットフォームとしたアプリケーションに対する攻
撃の勘所を理解するのが目的
Slide 4
Slide 4 text
Docker を知っている🙋
Slide 5
Slide 5 text
Linux コンテナの仕組みを知っている🙋
コンテナとホストのリソース分離技術について知っている
Slide 6
Slide 6 text
Linux コンテナのセキュリティを知っている
🙋
Slide 7
Slide 7 text
Kubernetes を知っている🙋
Slide 8
Slide 8 text
Kubernetes セキュリティを知っている🙋
Slide 9
Slide 9 text
# コンテナと Kubernetes の仕組み
Slide 10
Slide 10 text
Linux Container
● LXC や Docker などを筆頭にホストマシンから隔離した環境でプロセス
を動かす仕組み
● 隔離 = chroot よりは強固だが VM よりは弱い
● Namespace や cgroup などリソースを分離する既存の技術を組み合
わせることで実現している
Slide 11
Slide 11 text
Container Runtime Architecture
Slide 12
Slide 12 text
CRI / OCI
● CRI (Container Runtime Interface) … OCI を制御するための規格化
されたインターフェイスを持つ
● OCI (Open Container Initiative) … CRI から受け取った命令を元にコ
ンテナを実行する主体
● それぞれの実装を切り替えることを可能とした高い拡張性が特徴
Slide 13
Slide 13 text
リソース分離のための主要素
● Namespace
● Capability
● seccomp
● cgroup
● LSM
● chroot / pivot_root
Slide 14
Slide 14 text
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]'
Slide 15
Slide 15 text
主要な Namespace
● UTS Namespace
○ ホスト名の分離
● PID Namespace
○ プロセスの分離
● Network Namespace
○ ネットワークの分離
● IPC Namespace
○ IPC の分離
● Mount Namespace
○ マウントテーブルの分離
Slide 16
Slide 16 text
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
Slide 17
Slide 17 text
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
Slide 18
Slide 18 text
seccomp
● Firefox や Snap などを始め様々なアプリケーションで利用されている
● コンテナではホスト側に影響を与えかねないシステムコールを禁止してい
る
○ kexec_file_load
○ mount
○ ptrace
Docker のデフォルトのプロファイルについては
https://docs.docker.com/engine/security/seccomp/#significant-syscalls-blocked-by-the-default-profile を参照
Slide 19
Slide 19 text
seccomp bypass
https://asciinema.org/a/jTJmL1VVyCcFk387isJXPOENk
Slide 20
Slide 20 text
LSM
● SELinux / AppArmor などが利用されている
● seccomp や Capability などが破られた場合に最後の砦として機能す
る
○ 具体的には procfs などへのアクセス制御をしている
● コンテナごとに適用するプロファイルを生成することで、より堅牢にするこ
とができる
Slide 21
Slide 21 text
chroot と pivot_root
● コンテナのファイルシステムをホストと分離する
● chroot は条件によって脱獄可能なので、多くのコンテナランタイムでは
pivot_root が使われている
○ Mount Namespace と組み合わせることで古い(ホストの) root
ディレクトリにアクセスできなくなる
Slide 22
Slide 22 text
User Namespace / ID Mapping
● 非特権コンテナで利用される機能
● User Namespace を分離した際に、ホストとコンテナでのユーザーID /
グループID の mapping を行う
● もし Break Out されても非特権ユーザーの権限となる
Slide 23
Slide 23 text
# コンテナのセキュリティ
Slide 24
Slide 24 text
Sensitive File Mount
● コンテナから読み書きできてはいけないファイルが多数ある
○ 主に /proc や /sys 配下
○ ReadOnly にする, bind-mount するなどの対応が必要
● /var/run/docker.sock などもマウントすると Docker API 経由でホスト
側で任意のコマンドが実行できる
Slide 25
Slide 25 text
Privileged Container
● 特権(Privileged Container)は非常に強力な権限を持っている
○ CAP_SYS_ADMIN, CAP_SYS_PTRACE など
○ mount(2) の呼び出しによるファイルシステムマウント
● Privileged Container への侵入 = ホストへの侵入と同じ
● call_usermodehelper_exec() を利用したホスト側へのエスケープ
Slide 26
Slide 26 text
Breakout with uevent_helper
https://asciinema.org/a/KbToy20RnDlycB0tkh4v8HGhP
Slide 27
Slide 27 text
# Kubernetes の仕組み
Slide 28
Slide 28 text
Kubernetes とは
● 複数のマシン(ノード)でクラスタを作り、その上でコンテナを管理するオー
ケストレーションツール
● manifest と呼ばれる YAML や JSON 等でコンテナの状態を定義し、そ
れを維持してくれる宣言的なアーキテクチャ
● 拡張性が高く様々なデプロイ方式をサポートしているのが特徴
Slide 29
Slide 29 text
クラスタの構成
Slide 30
Slide 30 text
クラスタの構成
https://kubernetes.io/ja/docs/concepts/overview/components/
Slide 31
Slide 31 text
クラスタの構成
● (構成に依存するが) 実際には他のアプリケーションも動作している
○ CoreDNS などの DNS Server
○ Prometheus や cAdvisor などのリソース監視ツール
○ ダッシュボード (kube-dashboard / Grafana)
○ td-agent などの Log Collector
● これらすべて Pod で動いていることが多い
Slide 32
Slide 32 text
# Kubernetes Attack Surfaces
Slide 33
Slide 33 text
Kubernetes Attack Matrix
https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/
Slide 34
Slide 34 text
● コンテナから Node への Break out
○ コンテナの設定不備 (Privileged Container など)
○ カーネルの脆弱性 (Dirty CoW など)
○ ランタイムの脆弱性 (CVE-2019-5736 など)
Runtime Security
Slide 35
Slide 35 text
Image Vulnerability
● イメージに含まれるパッケージの脆弱性
● クレデンシャルを誤ってイメージに含めてしまう
● レジストリの不正操作
Slide 36
Slide 36 text
ServiceAccount
● Mount している ServiceAccount Token を利用して、その権限でクラスタを
操作する
Slide 37
Slide 37 text
API
● Kubernetes API と kubelet API の2つがある
● 認証不要な場合、クラスタの制御や Information
Leak が可能
● パブリッククラウドだと Metadata API から
Information Leak も可能
Slide 38
Slide 38 text
Secret
● Base64 でエンコードされた値となっている
○ うっかり git push しちゃった...... というケースも
Slide 39
Slide 39 text
Networking
● デフォルトでは Pod 間同士で通信し放題
● そのため、Pod への侵入等からさらなる権限昇格につながる
Slide 40
Slide 40 text
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
Slide 41
Slide 41 text
etcd
● Secret やクラスタの情報を格納している KVS
● クライアント証明書を使って接続するのが普通だが...
Slide 42
Slide 42 text
Metadata API
● クラウドプロバイダーが提供しているエンドポイント 169.254.169.254
● IAM のクレデンシャルや Kubernetes クラスタに必要な環境変数などが
格納されている
● アプリケーションレイヤからは SSRF などを利用して窃取されるケースも
考えられる
Slide 43
Slide 43 text
EKS
● インスタンス情報の取得
● VPC, SecurityGroup 情報の取得
● ECR リポジトリからイメージの取得
https://docs.aws.amazon.com/eks/latest/userguide/restrict-ec2-credential-access.html
Slide 44
Slide 44 text
GKE
● kube-env に bootstrap 処理で仕様される証明書等を保持
● そのクレデンシャルを使ってクラスタにノードとして Join できる
● これを利用して kubelet になりすますことが可能
Slide 45
Slide 45 text
# How to Kubernetes cluster
Slide 46
Slide 46 text
How to protect Kubernetes cluster
● Kubernetes はコンポーネントが多いので、守るところも多い
● Pod が一つ侵害されるとクラスタ全体が危険になることがある
Slide 47
Slide 47 text
基本の対策まとめ
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 など、より分離レベルの強いランタイムへの変更。
Slide 48
Slide 48 text
Service Mesh
Slide 49
Slide 49 text
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
Slide 50
Slide 50 text
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
Slide 51
Slide 51 text
Training
● 守るべきところが増えたので、トレーニングも重要
○ CKS (Certified Kubernetes Security Specialist) の取得
○ https://github.com/madhuakula/kubernetes-goat
○ https://github.com/kubernetes-simulator/simulator
○ https://github.com/mrtc0/kubectf
Slide 52
Slide 52 text
Sec ができることはガードレールを作ること
● 崖から落ちないような仕組みを用意する
○ Gatekeeper や Open Policy Agent による保護
○ Dev / Ops / Sec でポリシーを育てていく
○ CI での manifest のテスト
● CIS Benchmark や NIST SP 800-190 などへの準拠
○ 「そこまでするの...」という内容もあるので、脅威分析をした上で、妥
協点を決めるのが良い
Slide 53
Slide 53 text
インシデントへの対応
● Kubernetes API の auditd ログを取得しておく
○ リソースの作成や削除などを追跡できるように
● falco などを用いたコンテナの監査
○ auditd では Pod / コンテナ名などを取得できない
○ セキュリティイベント発生時に自動でノードを切り離すなど
○ https://github.com/falcosecurity/kubernetes-response-en
gine
● ノードのセキュリティモニタリングにも falco や Wazuh を利用
Slide 54
Slide 54 text
まとめ
● コンテナは多層防御の仕組みを取っている
● Kubernetes は複雑で守るところも多く、攻撃を受けた場合の影響が深
刻になるケースがある
● しかし、これまでとは少し違うアプローチの対策も取れて、Security に加
えて Observability の向上も期待できる
● OPA を始めとしたポリシー言語は波が来ている
Slide 55
Slide 55 text
参考文献
● イラストでわかる Docker と Kubernetes / 技術評論社
● Docker / Kubernetes 開発・運用のためのセキュリティ実践ガイド / マ
イナビ出版
● コンテナ型仮想化概論 / カットシステム