KEP持ち寄り会#1 - KEP-3619: Fine-grained SupplementalGroups Control

KEP-3619: Fine-grained SupplementalGroups Controlについて解説します

Presented at KEP持ち寄り会 #1 on 2023-11-27

Transcript

1. KEP-3619: Fine-grained SupplementalGroups Control https://kep.k8s.io/3619 Shingo Omura @everpeace KEP持ち寄り会 #1
2. @everpeace Supplementary Groups とは $ id uid=1000(codespace) gid=1000(codespace) groups=1000(codespace),106(ssh),107(docker),... User ID Primary Group ID Supplementary Group IDs 今日はコレの話！ 📰Linuxではgroupsの先頭はprimary groupが入っていることが想定されていますが 各種container runtimeがそうなっていなくてCVEが出たことも → "Vulnerability in Linux containers ‒ investigation and mitigation" TL;DR; setgidで完全にprimary groupを抜けることができてnegative permission (特定のグループのpermissionが000)をbypass可能
3. @everpeace Supplementary Groupsは PodSecurityContextで指定できる spec: securityContext: runAsUser:1000 runAsGroup:1000 supplementalGroups:[60000] containers: - name: ctr securityContext: # supplementalGroupsなし 👈あまり知られていない &セキュリティ的に不安 な挙動があるんです
4. @everpeace KEP-3619が問題視している挙動 =コンテナイメージ内のグループ情報がマージされる # Dockerfile FROM ubuntu:22.04 # /etc/groupでalice(1000)はgroup-in-image(50000)に所属 RUN groupadd -g 50000 group-in-image \ && useradd -m -u 1000 alice \ && gpasswd -a alice group-in-image --- # Pod Spec spec: securityContext: runAsUser: 1000 # alice runAsGroup: 1000 # alice supplementalGroups: [60000] containers: - image: image-above command: ["id"] uid=1000(alice) gid=1000(alice) groups=1000(alice),50000(group-in-image),60000 🔥Policy Engineでチェックしても Image焼くだけで簡単にgroup制御可 😱HostPath Volumeを使ってるとContainerのUID/GIDが ファイルアクセスに使われるので、この挙動を使うことで 意図的にHostPathボリュームのパーミッションをbypassす ることができるので注意！！
5. @everpeace Kubernetesにおける Containerのuid/gid/groups決定の流れ OCI Image Configuration(User) (DockerfileのUSER) PodSecurityContext Container SecurityContext Kubelet CRI LinuxContainer SecurityContext (Highlevel) Container Runtime OCI Runtime Spec process.user (Lowlevel) Container Runtime # CRI (protobuf) security_context { run_as_user: 1000 run_as_group: 1000 supplemental_groups: [60000] } # runtime spec (json) "user": { "uid": 1000, "gid": 1000, "additionalGids": [ 50000, 60000 ] } # Dockerfile USER 1000:1000 --- # PodSpec spec: securityContext: runAsUser:1000 # alice runAsGroup:1000 # alice supplementalGroups:[60000]
6. 仕様を追ってみる
7. @everpeace OCI Image ConfigurationのUserの仕様 ちゃんと書いてある！！！ 💡Kubernetesはこの仕様に厳密に従っていません。 Dockerfileで"USER 1000:1000"＆空SecurityContext 　でも/etc/groupに定義されたsupplementary groupを含めて しまいます。(docker run はこの仕様を満たしてます) 🤔/etc/groupも必要 　では？
8. @everpeace PodSpec.PodSecurityContextの仕様 ちゃんと書いてある！！！ 💡OCI Image Configuration Specとねじれている (runAsGroupが指定されているかどうかに関わらず 　　/etc/groupのグループを含むと書かれている) 💡v1.25まではこの記述はなく実装依存でしたが、 　v1.26で実装に沿う記述に修正されました(k/k#113047)
9. @everpeace CRIのLinuxContainerSecurityContext (仕様はPod側とほぼ同様) ちゃんと書いてある！！！ 💡OCI Image Configuration Specとねじれている (runAsGroupが指定されているかどうかに関わらず 　　/etc/groupのグループを含むと書かれている) 💡v1.25まではこの記述はなく実装依存でしたが、 　v1.26で実装に沿う記述に修正されました(k/k#113047)
10. 結局どこが悪いのか？ (どこを直せばいいのか？)
11. @everpeace 悪いのは仕様のねじれ OCI Image Configuration Spec USER 1000:1000 # /etc/group 読まない USER 1000 # /etc/group 読む (USER指定なし) # /etc/group 読む (uid=0) PodSecurityContext securityContext: {} # /etc/group 読む # uid/gidはイメージ見る securityContext: runAsUser: 1000 # /etc/group 読む securityContext: runAsUser: 1000 # /etc/group 読む runAsGroup: 1000 😱現状Kubernetesはどうやっても /etc/groupが反映されてしまう状況
12. KEP-3619の提案内容 📝実はKEP-3619は私が書きました&実装はちょっと放置気味です🙇
13. @everpeace 提案1: SupplementalGroupsPolicy APIの追加 securityContext: runAsUser: 1000 # alice runAsGroup: 1000 # alice supplementalGroups:[60000] # default=Merge supplementalGroupsPolicy: Merge|Strict uid=1000(alice) gid=1000(alice) groups=1000(alice),50000(group-in-image),60000 Merge uid=1000(alice) gid=1000(alice) groups=1000(alice),60000 Strict 💡仕様がねじれてしまっているのをOCIに寄せる変更は 影響が大きすぎるのでKubernetes APIでなんとかする 方針を取っている
14. @everpeace 提案2: ContainerStatusの拡張 status: containerStatuses: - name: ctr user: linux: uid: 1000 gid: 1000 supplementalGroups: [1000, 60000] 実際にどのidentityが割り当てられたか確認できる (もしかしたら仕様が変わるかもしれない(参照)) 📝あとはこれらに付随するCRIの変更提案もありますが 今回は割愛。詳細はKEP-3619を参照ください🙇
15. KEP-3619のステータス
16. @everpeace KEP-3619のステータス (in v1.29) • 未リリース、かつ、まだ開発中の段階 • 先述の通りContainerStatusの構造が変わるかもしれない • CRI実装の変更も必要なので少し時間がかかるかも • SupplementalGroupsの仕様自体が不明瞭だったのを修正したものは v1.26でリリース済み(k/k#113047)
17. @everpeace Workaroundはあるのか？ → YES OCI Image Configuration(User) (DockerfileのUSER) PodSecurityContext Container SecurityContext Kubelet CRI LinuxContainer SecurityContext (Highlevel) Container Runtime OCI Runtime Spec process.user (Lowlevel) Container Runtime Kubelet & Highlevel Runtimeが Kubernetes & CRIの仕様で OCI Runtime Spec まで変換してしまうので RuntimeClass でなんとか できる
18. @everpeace RuntimeClassで SupplementalGroupsPolicy=Strictを実現する pfnet-research/strict-supplementalgroups-container-runtime podSpec.runtimeClassで指定するとStrictモードと同等にできる ✏OCI Runtime SpecのadditionalGroupsから SupplementalGroups以外のgidを除去して 上書きしてcontainer runtimeを呼ぶ
19. こぼれ話
20. @everpeace こぼれ話 • 最初はKubernetes Security and Disclosure Informationに従ってSecurity Committeeに挙動を報告 → ”Works as Intendedなのでk/k issueで議論される べき”と回答された • k/k#112879 Can bypass PodSecurityContext.SupplementalGroupsを作って sig-nodeで相談した • まずはドキュメント(仕様)の修正を先にして • 変更自体はKEPで議論しようということになって今に至ります
21. ありがとうございました Questions? 🙇