Upgrade to Pro — share decks privately, control downloads, hide ads and more …

KEP持ち寄り会#1 - KEP-3619: Fine-grained Supplement...

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

Shingo Omura

November 27, 2023
Tweet

More Decks by Shingo Omura

Other Decks in Technology

Transcript

  1. @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可能
  2. @everpeace Supplementary Groupsは PodSecurityContextで指定できる spec: securityContext: runAsUser:1000 runAsGroup:1000 supplementalGroups:[60000] containers:

    - name: ctr securityContext: # supplementalGroupsなし 👈あまり知られていない &セキュリティ的に不安 な挙動があるんです
  3. @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す ることができるので注意!!
  4. @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]
  5. @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が反映されてしまう状況
  6. @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でなんとかする 方針を取っている
  7. @everpeace 提案2: ContainerStatusの拡張 status: containerStatuses: - name: ctr user: linux:

    uid: 1000 gid: 1000 supplementalGroups: [1000, 60000] 実際にどのidentityが割り当てられたか確認できる (もしかしたら仕様が変わるかもしれない(参照)) 📝あとはこれらに付随するCRIの変更提案もありますが 今回は割愛。詳細はKEP-3619を参照ください🙇
  8. @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 でなんとか できる
  9. @everpeace こぼれ話 • 最初はKubernetes Security and Disclosure Informationに従ってSecurity Committeeに挙動を報告 →

    ”Works as Intendedなのでk/k issueで議論される べき”と回答された • k/k#112879 Can bypass PodSecurityContext.SupplementalGroupsを作って sig-nodeで相談した • まずはドキュメント(仕様)の修正を先にして • 変更自体はKEPで議論しようということになって今に至ります