Kubernetes Security for Microservices

- Kubernetes Meetup Tokyo #30 ( https://k8sjp.connpass.com/event/171599/ ) で発表した資料です。
* スライド上のリンクはPDFをダウンロードしたらクリック可能です

- メルカリではMicroservices化を進めており、各サービスのコンテナをKubernetesクラスタにのせて運用しています。本セッションでは、大規模なKubernetesクラスタを運用するにあたって、セキュリティの観点から、どのような考え方で運用する
必要があると考えているか、セキュリティ戦略を説明します。

【登壇時ビデオ】
https://www.youtube.com/watch?v=5rW0T63A_P8&t=5370

【スライド内主要リンク】
■攻撃シナリオ チュートリアル
https://github.com/rung/tutorial-gke-security

■デモ
シナリオ1: 開発者の端末経由 (内部から) - https://www.youtube.com/watch?v=kfD7aK_aI0w
シナリオ2: アプリケーションの脆弱性 (外部から) - https://www.youtube.com/watch?v=fEPbsuY3PRg

【参考資料】
■Kubernetes Security
Kubernetes Security Audit Report - https://github.com/kubernetes/community/tree/master/wg-security-audit
Kubernetes Security - https://www.oreilly.com/library/view/kubernetes-security/9781492039075/
Kubernetes Multi-tenancy profile: Single Tenant Cluster - https://github.com/kubernetes-sigs/multi-tenancy/blob/master/docs/profiles/profile-single-tenant-cluster.md
Kubernetes Multi-Tenancy Proposal - https://docs.google.com/document/d/1U8RQQmTUjxgMZY05HG2f7b3KsB94BhK4Ko6aWbLNXcc/edit

■ 攻撃シナリオ1: 開発者の端末経由
The Path Less Traveled: Abusing Kubernetes Defaults - https://speakerdeck.com/iancoldwater/the-path-less-traveled-abusing-kubernetes-defaults
Kubernetes RBAC in microservices - https://speakerdeck.com/spesnova/kubernetes-rbac-in-microservices

■ 攻撃シナリオ2: アプリケーションの脆弱性
SSRF in Exchange leads to ROOT access in all instances - https://hackerone.com/reports/341876
Hacking Kubelet on Google Kubernetes Engine - https://www.4armed.com/blog/hacking-kubelet-on-gke/

■ Component of Isolation
DNS Spoofing on Kubernetes Clusters - https://blog.aquasec.com/dns-spoofing-kubernetes-clusters

Transcript

1. 1 Kubernetes Security for Microservices Mercari Security Team Hiroki Suezawa (@rung) Apr 23, 2020 Kubernetes Meetup Tokyo #30
2. 2 Caution • 本発表は日本のKubernetesコミュニティのセキュリティ向上を目的としています • 本発表の内容を、絶対に悪用しないでください ◦ 対策と併せて扱っている攻撃については、既存の一般的な攻撃手法のみ扱っていま す
3. 3 • Microservices化を進めているメルカリにおける Kubernetesセキュリティ戦略 ◦ 何を考えてセキュリティ強化をしようとしているのか 伝えたいこと 開発者向けの基盤をつくる - Taichi Nakashima
4. 4 • Name ◦ 末澤 裕希 (SUEZAWA Hiroki) • Title ◦ Security Engineer at Mercari, Inc. ◦ Contribution: Sysdig Falco, gosecなど ◦ Likes: Go言語, TLSなどのネットワークプロトコル • 趣味 ◦ 紅茶 ▪ 先月、noteで、リモートワークをしている方に向けて おすすめ紅茶の紹介を書きました ▪ 自宅で美味しい紅茶を飲む - note @rung @rung suezawa@gmail.com
6. 6 Introduction
7. 7 インフラ管理の変遷 • Infrastructureはインフラチームだけのものだけでなく、開発者も関わるように ◦ DevOps ◦ Cloud Infrastructure • 全開発者がインフラを触ることを想定したセキュリティが必要に ◦ Developer ExperienceとSecurityの両立が必要 Infrastructure Team SRE SRE Developers Cloud Infrastructure Development Deployment Operation
8. 8 Microservices • Microservicesは組織のプラクティスでもある ▪ 各チームが、それぞれのMicroservicesの開発・運用に責任 SRE Practices in Mercari Microservices - Taichi Nakashima
9. 9 • Single Cluster: 複数のMicroservices(チーム)が同じクラスタを利用 ◦ 複数のセキュリティレベルのMicroservicesがクラスタに同居 ◦ GKE(Google Kubernetes Engine)を利用 * 本発表はGKE固有の話も含むが、その他のマネージドKubernetesでも通じる考え方を説明 Kubernetes Clusters on Mercari API gateway Authority Service A Spanner Google Kubernetes Engine Cloud SQL Service B 機密情報 機密情報なし
10. 10 Kubernetes Security • 本発表のフォーカス: Runtime Security Building Shipping Runtime • 設定内容の監視 • 静的解析(SAST) • 動的解析(DAST) • パッケージ管理 • シークレット管理 • イメージScanning ...etc • Secure Supply Chain • Image Signing ...etc • Kubernetesの堅牢化 • Activityの記録・監視 • CIS Benchmark • Secure runtime engine • Network Policy(L3/L7) • AppArmor/SELinux • Runtime Image Scanning ...etc Kubernetes GitHub, CI/CD
11. 11 Kubernetes Runtime Security
12. 12 Node Concept of Kubernetes Runtime Security • 目標: Isolation(分離) の実現 ◦ 様々なセキュリティレベルのMicroservicesが同一クラスタに同居 ◦ 各チーム・各Microservicesが影響を及ぼせる範囲を最小限に Team A Team B Team C SRE Microservice A Namespace A (機密情報なし) Microservice B Microservice C Cluster Monitoring SRE Namespace Deployment Tool Least Privilege Namespace B (機密情報あり) Namespace C (機密情報あり) Defense in Depth
13. 13 Concept of Container Guest OS Linux Node Process 1 (Host) Process 2 (Namespace A) Process 3 (Namespace B) Kernel Container Host OS Kernel VM (Type-1) Guest OS Kernel Kernel hypervisor
14. 14 • コンテナはLinux Kernelの機能で実現 ◦ コンテナは、Linuxのプロセスとして起動 ◦ Node(ホスト)からは、Node上の各コンテナに入ることができる ▪ Nodeは配下のコンテナのSecretなどを読み取れる ◦ Namespaces, Capabilities, Cgroups... Concept of Container [Node] # ps -e -o pid,pidns,cmd … 16435 4026532707 python server.py 18510 4026532319 /go-server 18666 4026531836 /init.sh … * コンテナ上のプロセスはNodeでpsコマンドで表示可能 Node [Container A] python server.py [Container B] /go-server [Container C] /init.sh
15. 15 Concept of Kubernetes Namespace A Deployment Services Namespace B Deployment Services Namespace C Deployment Services Virtual
16. 16 Managed by GCP API Server Kubernetes API Real Node Kubelet kube-proxy Pod A Pod B Pod C Node Kubelet kube-proxy Pod B Pod C Pod D Node Kubelet kube-proxy Pod A Admin/ Developer Pod C Pod D GCE Metadata
17. 17 Managed by GCP API Server Node Kubelet kube-proxy Admin/ Developer GCE Metadata Kubernetes API Pod A Pod B Pod C PodからCloudベンダの Metadataにアクセス可能 開発者は最小限の権限 のみ所有すべき Pod A Pod B Pod C Network制限なし 高権限Podを作成可能 ※NodeからはコンテナのSecretを読み取れる Kubernetes is not secure by default GCP固有
18. 18 攻撃シナリオ Tutorial: github.com/rung/tutorial-gke-security
19. 19 • 一番防ぎたいシナリオ ◦ 攻撃者によるコンテナへの侵入 -> Nodeへの権限昇格 ▪ NodeからはNode上の全コンテナのSecretを取得できる 1. 開発者の端末経由 (内部から) 主な攻撃シナリオ Privileged Container Node 盗難/マルウェア感染 開発者端末 K8S API Privileged Container作成 権限昇格 2. コンテナ上のアプリケーション脆弱性 (外部から) Node *コンテナ上の情報閲覧可能 Pod A Pod B Pod C Application on Pod Node 権限昇格 Exploit The Internet 情報窃取 情報窃取
20. 20 MITRE ATT&CK Framework
21. 21 シナリオ1: 開発者の端末経由 (内部から) • 攻撃ターゲット ◦ 開発者端末の~/.kube/config ▪ kubectlのCredentialsを含む $ cat ~/.kube/config | head apiVersion: v1 clusters: - cluster: certificate-authority-data: YWZhZm5haXNvZm9pb3NhZmFzZm93cnVmaW91bzRoM3doZmFvaGZhb2hmb2Fob2Fza... Privileged Container Node 盗難/マルウェア感染 開発者端末 K8S API Privileged Container作成 権限昇格 情報窃取
22. 22 (Case Study) コインチェック - 2018 コインチェックの仮想通貨不正流出、過去最大 580億円 Ref: https://piyolog.hatenadiary.jp/entry/20180126/1517012654 Initial Access: 従業員のマルウェア感染 * 本件の場合はKubernetesがターゲットではない マルウェアへのリンク付きメール
23. 23 シナリオ1: Demo • 攻撃の流れ ◦ Privileged Containerを作成 ▪ LinuxのNodeに権限昇格 ◦ Nodeから、他コンテナ上のSecretにアクセス Privileged Container Node 盗難/マルウェア感染 開発者端末 K8S API Privileged Container作成 権限昇格 情報窃取 pod.yaml Pod A [CAP_SYS_ADMIN/CAP_CHOWN/…] Node NodeのNamespacesに移動 https://www.youtube.com/watch?v=kfD7aK_aI0w
24. 24 シナリオ1: 対策 • Challenging Point: 様々なセキュリティレベルが同一クラスタ上に存在 
 Team A Team B Team C SRE Microservice A Namespace A (機密情報なし) Microservice B Namespace B (機密情報あり) Microservice C Namespace C (機密情報あり) Cluster Monitoring SRE Namespace Deployment Tool Node Get pod Create pod Get pod Get pod Get pod Create pod PSP: Block High Privilege • RBACとPodSecurityPolicyを組み合わせて最小限の権限付与 
 ◦ RBAC: 各チームにNamespacesごとの権限付与が可能 
 ◦ PodSecurityPolicy(Gatekeeper): 高権限Podの作成を禁止できる
25. 25 シナリオ2: アプリケーションの脆弱性 (外部から) • 攻撃ターゲット ◦ GCE Instance Metadata *GKE固有 (http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env?alt=json) ▪ デフォルトでは全PodからMetadataにアクセス可能 • MetadataはNodeに昇格できるCredentialsを持っている • ※AWSの場合でいうInstance Metadataと同等 root@curl-image:/# curl http://metadata.google.internal/computeMetadata/v1/instance/attributes/kube-env?alt=json -H 'Metadata-Flavor: Google' ...KUBELET_KEY: YWZhZm5haXNvZm9pb3NhZmFzZm93cnVmaW91bzRoM3doZmFvaGZhb2hmb2Fob2Fza... Pod A GCE Metadata (Credentials) Application on Pod Node 権限昇格 Exploit The Internet 情報窃取
26. 26 (Case Study) Shopify - 2018 Ref: https://hackerone.com/reports/341876 Initial Access: アプリケーションのSSRF(Server Side Request Forgery)脆弱性 * 脆弱性報酬プログラムにて報告 全クラスタが侵 害 Kubernetes Engine アプリケーション脆弱性 ※Metadataを表示
27. 27 シナリオ2: Demo Metadata Pod Node [KUBELET_KEY/...] Application on Pod Node 権限昇格 Exploit The Internet 情報窃取 • 攻撃の流れ ◦ GCE MetadataをSSRF脆弱性を利用し取得 ▪ KUBELET_CERT, KUBELET_KEYを取得 ◦ 取得した鍵を利用し、NodeのSecretを取得 https://www.youtube.com/watch?v=fEPbsuY3PRg
28. 28 シナリオ2: 対策 • Workload Identity *GKE固有
 ◦ GKE(Google Kubernetes Engine)の場合はWorkload Identity機能により対策が可能 
 
 
 • Iptables
 ◦ IptablesによりMetadataのIPアドレスへのアクセスを禁止 
 • Falco/Sysdig Secure(有償) 
 ◦ 不正検知ツールを用いてMetadata利用の検知を行うことが可能 
 Pod A GCE Metadata Workload Identity
29. 29 Component of Isolation • Isolationのためのコンポーネント (一部) ◦ Network Policy - Network制限 ◦ PodSecurityPolicy / Gatekeeper- 高権限コンテナ制限 ▪ PodSecurityPolicyは廃止の議論あり. MercariではGatekeeperを利用 ▪ conftestとルールを組み合わせ、 CI/CDにもチェックを組み込み ◦ RBAC - Namespacesごとの権限分離 ◦ Workload Identity - Metadataの無効化 *GKE固有 ◦ Falco/Sysdig Secure(有償ツール) - 不正検知/Command Audit ▪ 権限を制限しすぎると Developer Experienceを損なう場合がある • ”許可するが検知”と”禁止”のバランス 例: pingを使う権限のあるコンテナは 、他コンテナの通信の乗っ取り も可能 　 ping(raw socket)を使う権限をコンテナに許可するが、乗っ取りは検知 • 検討中 ◦ Mutual TLS with Istio - ProxyでのMutual authentication/Encryption ◦ gVisor - Secure Container Runtime
30. 30 Secure Kubernetes Infrastructure Security & Developer Experience 各チームに必要な最小権限を与えた上で、 Isolationを実施 Team A Team B Team C SRE Microservice A Namespace A (機密情報なし) Microservice B Namespace B (機密情報あり) Microservice C Namespace C (機密情報あり) Cluster Monitoring SRE Namespace Deployment Tool Node Get pod Create pod Get pod Get pod Get pod Create pod PSP: Block High Privilege Sysdig Secure/Falco: Security Monitoring + Security Audit
31. 31 Summary
32. 32 • メルカリにおけるKubernetesセキュリティ戦略 ◦ シングルクラスタ上でも、Isolation(分離)を強化 ▪ RBAC, PodSecurityPolicy(Gatekeeper), Network Policyなど... ◦ SecurityとDeveloper Experienceの両立も必要 ▪ 各チームがMicroservicesにオーナーシップを持ちつつ、セキュアな状況を実 現する必要がある ▪ (参考)各チームがSecurityについても考慮できる環境作り • Ref: セキュリティチャンピオンプログラム Summary
33. 33 Thank you!
34. 34 Appendix • 攻撃シナリオのTutorial ◦ github.com/rung/tutorial-gke-security • Kubernetes Securityを考える際にはコミュニティ動向も参考になる ◦ Multi-Tenancy SIG ◦ Auth SIG • PodSecurityPolicy ◦ PodSecurityPolicyは廃止される可能性あり ▪ Gatekeeperが移行先候補 ◦ ただし該当Issueを確認する限り、PodSecurityPolicyからのMigration方法は用 意される想定 ▪ Ref: Issue: Pod Security Policy #5 ◦ MercariではGatekeeperを利用してPodSecurityPolicyと同等の制限を実施
35. 35 References • Kubernetes Security ◦ Kubernetes Security Audit Report ◦ Kubernetes Security - Liz Rice, Michael Hausenblas ◦ Kubernetes Multi-tenancy profile: Single Tenant Cluster ◦ Kubernetes Multi-Tenancy Proposal • 攻撃シナリオ1: 開発者の端末経由 ◦ The Path Less Traveled: Abusing Kubernetes Defaults ◦ Kubernetes RBAC in microservices • 攻撃シナリオ2: アプリケーションの脆弱性 ◦ SSRF in Exchange leads to ROOT access in all instances ◦ Hacking Kubelet on Google Kubernetes Engine • Component of Isolation ◦ DNS Spoofing on Kubernetes Clusters