root権限無しでKubernetesを動かす

Copyright©2019 NTT Corp. All Rights Reserved.
NTT ソフトウェアイノベーションセンタ
須田瑛大
root権限無しでKubernetesを動かす
Kubernetes Meetup Tokyo #17 (2019/03/18)
https://slideshare.net/AkihiroSuda

2
• コンテナ関連OSSのメンテナ(いわゆるコミッタ)を務めている
• Docker Moby メンテナ (2016年11月～)
• 2017年4月，OSSプロジェクトとしてのDockerはMobyに名前が変わった
• 商用製品としてのDockerはMobyをベースとして開発されている
• Moby BuildKitメンテナ (2017年夏プロジェクト発足時～)
• 次世代 `docker build`
• CNCF containerdメンテナ (2017年9月～)
• Kubernetesなどで利用できる次世代コンテナランタイム
: ≒ :
RHEL Fedora
自己紹介

3
デモ

4
• Kubernetes全体を非特権ユーザで動作させることにより，セキ
ュリティを強化
• OCIランタイム (runc)
• CRIランタイム (containerd, CRI-O, Docker)
• CNIプラグイン (Flannel)
• kubelet, kube-proxy, kube-apiserver, kube-scheduler, kube-
controller-manager
• securityContext.runAsUser とか Node-level UserNSとは別
• これらはコンテナを非特権ユーザで動作させるが，Kubernetesそのもの
やコンテナランタイムはrootで動作
Rootless Kubernetes

5
•Kubernetesやランタイムが抱えうる脆弱性の影響範囲を
限定
•root権限を与えられない環境へのKubernetesのデプロイ
(特にHPC)
•Kubernetes-on-Kubernetes
Rootless Kubernetesの目的

6
•Kubernetes CVE-2017-1002101, CVE-2017-
1002102
• volume関係の脆弱性を通じて，ホストのファイルシステムへのアクセス
が可能
•Git CVE-2018-11235 (KubernetesのgitRepo volume
に影響)
• 不正なリポジトリをcloneすると，任意のバイナリがホスト上のrootで実
行される
•Kubernetes CVE-2018-1002105
• 不正なAPI呼び出しにより，cluster-adminの奪取が可能
Kubernetesの脆弱性

7
•2019年初，須田が発見，Giuseppe Scrivano (Red
Hat)が修正
•DOCKER_RAMDISK=1 が設定されている環境で，/proc
や /sys に対するマスクを解除することが可能だった
• /proc/sys/kernel/core_pattern や /sys/kernel/uevent_helper
を通じて，ホスト上のroot権限で任意のコマンドの実行が可能
•Minikube v0.33.0以前のbreakoutが可能
runc #1962

8
•/proc/self を通じてruncバイナリの書き換えが可能
•LXCやOpenVZなど，runc以外のコンテナ実装にも同じ脆
弱性が存在していた
•コンテナをセキュアに実装することは本質的に難しい
→今後も色々な脆弱性が見つかることが予想される
runc CVE-2019-5736

9
仕組み

10
•非特権ユーザをrootに見せかけることが出来る
• 見かけのUIDが0になる
• Network namespacesやmount namespacesを作成できるようになる
•真のroot権限を与えるわけではない (sudoとは全く異なる)
• user namespace外でアクセスできないファイルは，user namespace内の
rootでもやはりアクセスできない (UID 65534で所有されているように見え
る)
• カーネルモジュールの読み込みは出来ない
• 再起動出来ない
User namespaces

11
•非特権ユーザでは，UID 0のみが存在するuser
namespaceしか作れないので，コンテナには不都合
•SETUIDバイナリ /usr/bin/newuidmap,
/usr/bin/newgidmapを用いることで，複数ユーザのマッ
ピングが可能
• カーネル 4.14ではCAP_SETUID, CAP_SETGID file capabilityさえ設定し
ておけば，SETUID不要
User namespaces

12
User namespaces
/etc/subuid:
1000:420000:65536
/proc/42/uid_map:
0 1000 1
1 420000 65536
rootで予め設定を記述しておく
(最近のdistroではたいてい
adduser時に自動的に記述される)
UID 1000がNS内では0
420000-485535がNS内では1-65536
にマップされる

13
•subuidはLDAP環境だと設定が困難
•案1: LDAPに対応したSETUIDバイナリを作る
• https://github.com/shadow-maint/shadow/issues/154
• 正しく実装しないとホストのrootを奪われる可能性がある
•案2: ptraceやseccomp from user space (kernel 5.0)を
用いて，単一UIDでsubuidをエミュレートする
• ptraceによるPOC: https://github.com/rootless-containers/runrootless
• 正しく実装しないとNS内の非rootにNS内のrootを奪われる可能性がある
(が，ホストのrootは守られる)
User namespaces: Future work

14
•User namespaceを作ることで，非特権ユーザでも
network namespacesを作れるようになる
• iptables, VXLANなどを操作できるようになる他， abstract socketのアイ
ソレーションなども可能になる
• tcpdumpなども使えるようになるので，コンテナ以外にもユースケースが色
々ありそう
•ただし，ホスト上にbridgeデバイスを作成したり，NSと繋
がるveth pairを作成したりはできない
• インターネットに出られないので，従来はあまり役に立たなかった
Network namespaces

15
•veth pairの代わりにSlirpを用いることで，インターネット
に出ることが可能
• ユーザモードのTCP/IP実装
•NS内にTAPデバイスを作成し，NS外のSlirpとUNIX
domain socketで通信する
•slirp4netnsやVPNKitなど，複数の実装がある
• slirp4netnsは qemuの –netdev userをベースとし，須田が中心となって
開発
• VPNKitはMirageOSをベースとし，Docker社が開発
• Docker for MacやDocker for Windowsで使われている
Network namespaces

16
•slirp4netnsが最も高速
• network namespacesに用途を絞っているので，パケットを余計にコピー
しなくて済んでいる
• 未だ改善の余地あり
Network namespaces
MTU=1500 MTU=4000 MTU=16384 MTU=65520
vde_plug 763 Mbps Unsupported Unsupported Unsupported
VPNKit 514 Mbps 526 Mbps 540 Mbps Unsupported
slirp4netns 1.07 Gbps 2.78 Gbps 4.55 Gbps 9.21 Gbps
cf. rootful veth 52.1 Gbps 45.4 Gbps 43.6 Gbps 51.5 Gbps
ベンチマーク: iperf3 (netns -> host), Travis上で測定 rootless-containers/rootlesskit#12

17
•NS内のportには外から接続できないので，個別にexposeす
る必要がある
•slirp4netns: 7.82 Gbps
•socat: 8.50 Gbps
•RootlessKit: 23.7 Gbps
Network namespaces: inbound
ベンチマーク: iperf3 (host -> netns), Travis上で測定 rootless-containers/rootlesskit#33
L2を飛ばして直接L3で転送できる
余計なパケットコピーを更に削減

18
•SETUIDバイナリ lxc-user-nicを用いた，非slirpモードも
対応予定
• ただし過去にCVE-2017-5985, CVE-2018-6556が見つかっている (いず
れもCVSS v3スコア 3.3)
•パフォーマンスとセキュリティのバランスを柔軟に調節で
きるようになる
Network namespaces: future work

19
•User namespaceを作ることで，非特権ユーザでもmount
namespacesを作れるようになる
•しかし，bind-mount, tmpfs, procfs, sysfsくらいしか
mountできない
•特にoverlayfsが使えないことがコンテナ用途では問題
• ただしUbuntuではカーネルにパッチが当てられているので使える
Mount namespaces

20
•XFSでは copy_file_range (2) を用いてCoW出来る
•kernel 4.18以降では，fuse-overlayfsを利用できる
• 今のところCRIランタイムではCRI-Oのみが対応
Mount namespaces

21
•cgroup2では，非特権ユーザへの権限委譲が正式にサポー
トされている (nsdelegate)
•OCIランタイムでは，未だcgroup2は正式にサポートされて
いない
• https://github.com/opencontainers/runtime-spec/issues/1002
•Kubernetesエコシステム全体でcgroup2が使えるようにな
るには，1年くらいはかかりそう
• 今のところは，単にcgroupを無効化するのが安全
Cgroup

22
実装状況

23
•kubelet と kube-proxy にパッチを当てる必要がある
• cgroup 及び，sysctl関連のコードを無効化
•kubeadmは未だ使えない
•OCIランタイム: runcに加え，nvidia-container-runtime
が利用可能
•CRIランタイム: containerd, CRI-O, Docker いずれも利
用可能 (experimental)
•CNIプラグイン: Flannelが利用可能
実装状況

24
•root権限を不要化した，実験的なKubernetesディストリビ
ューション
https://github.com/rootless-containers/usernetes
•ホームディレクトリに簡単にインストールできる
Usernetes
$ tar xjvf usernetes-x86_64.tbz
$ cd usernetes
$ ./run.sh
$ ./kubectl.sh apply –f foo.yaml

25
•Rancher社が開発する軽量Kubernetesディストリビューシ
ョン https://github.com/rancher/k3s
• "5 less than k8s"
• etcdをsqlite3で置き換えたり，かなり大規模な変更がなされている
•Usernetesの成果物がマージされつつある
• https://github.com/rancher/k3s/pull/195
k3s

root権限無しでKubernetesを動かす

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a root権限無しでKubernetesを動かす

Similar a root権限無しでKubernetesを動かす (20)

Más de Akihiro Suda

Más de Akihiro Suda (20)

root権限無しでKubernetesを動かす