1 Kubernetes Security for Microservices Mercari Security Team Hiroki Suezawa (@rung) Apr 23, 2020 Kubernetes Meetup Tokyo #30

2 Caution ● 本発表は日本のKubernetesコミュニティのセキュリティ向上を目的としています ● 本発表の内容を、絶対に悪用しないでください ○ 対策と併せて扱っている攻撃については、既存の一般的な攻撃手法のみ扱っていま す

3 ● Microservices化を進めているメルカリにおける Kubernetesセキュリティ戦略 ○ 何を考えてセキュリティ強化をしようとしているのか 伝えたいこと 開発者向けの基盤をつくる - Taichi Nakashima

4 ● Name ○ 末澤 裕希 (SUEZAWA Hiroki) ● Title ○ Security Engineer at Mercari, Inc. ○ Contribution: Sysdig Falco, gosecなど ○ Likes: Go言語, TLSなどのネットワークプロトコル ● 趣味 ○ 紅茶 ■ 先月、noteで、リモートワークをしている方に向けて おすすめ紅茶の紹介を書きました ■ 自宅で美味しい紅茶を飲む - note @rung @rung [email protected]

5

6 Introduction

7 インフラ管理の変遷 ● Infrastructureはインフラチームだけのものだけでなく、開発者も関わるように ○ DevOps ○ Cloud Infrastructure ● 全開発者がインフラを触ることを想定したセキュリティが必要に ○ Developer ExperienceとSecurityの両立が必要 Infrastructure Team SRE SRE Developers Cloud Infrastructure Development Deployment Operation

8 Microservices ● Microservicesは組織のプラクティスでもある ■ 各チームが、それぞれのMicroservicesの開発・運用に責任 SRE Practices in Mercari Microservices - Taichi Nakashima

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 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 Kubernetes Runtime Security

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 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 ● コンテナは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 Concept of Kubernetes Namespace A Deployment Services Namespace B Deployment Services Namespace C Deployment Services Virtual

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 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 攻撃シナリオ Tutorial: github.com/rung/tutorial-gke-security

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 MITRE ATT&CK Framework

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 (Case Study) コインチェック - 2018 コインチェックの仮想通貨不正流出、過去最大 580億円 Ref: https://piyolog.hatenadiary.jp/entry/20180126/1517012654 Initial Access: 従業員のマルウェア感染 * 本件の場合はKubernetesがターゲットではない マルウェアへのリンク付きメール

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 シナリオ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 シナリオ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 (Case Study) Shopify - 2018 Ref: https://hackerone.com/reports/341876 Initial Access: アプリケーションのSSRF(Server Side Request Forgery)脆弱性 * 脆弱性報酬プログラムにて報告 全クラスタが侵 害 Kubernetes Engine アプリケーション脆弱性 ※Metadataを表示

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 シナリオ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 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 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 Summary

32 ● メルカリにおけるKubernetesセキュリティ戦略 ○ シングルクラスタ上でも、Isolation(分離)を強化 ■ RBAC, PodSecurityPolicy(Gatekeeper), Network Policyなど... ○ SecurityとDeveloper Experienceの両立も必要 ■ 各チームがMicroservicesにオーナーシップを持ちつつ、セキュアな状況を実 現する必要がある ■ (参考)各チームがSecurityについても考慮できる環境作り ● Ref: セキュリティチャンピオンプログラム Summary

33 Thank you!

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 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