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
   

   View Slide

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

   View Slide

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

   View Slide

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
   

   View Slide

5. View Slide

6. 6
   Introduction
   

   View Slide

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

   View Slide

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

   View Slide

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
   機密情報 機密情報なし
   

   View Slide

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
    

    View Slide

11. 11
    Kubernetes Runtime Security
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

15. 15
    Concept of Kubernetes
    Namespace A
    Deployment Services
    Namespace B
    Deployment Services
    Namespace C
    Deployment Services
    Virtual
    

    View Slide

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
    

    View Slide

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

    View Slide

18. 18
    攻撃シナリオ
    Tutorial: github.com/rung/tutorial-gke-security
    

    View Slide

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
    情報窃取
    情報窃取
    

    View Slide

20. 20
    MITRE ATT&CK Framework
    

    View Slide

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作成 権限昇格 情報窃取
    

    View Slide

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

    View Slide

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
    

    View Slide

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の作成を禁止できる
    

    View Slide

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
    情報窃取
    

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

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
    

    View Slide

31. 31
    Summary
    

    View Slide

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

    View Slide

33. 33
    Thank you!
    

    View Slide

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と同等の制限を実施
    

    View Slide

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
    

    View Slide