How to secure your Kubernetes cluster on Google Cloud - セキュアなGKEクラスタのつくりかた

2021年10月14日 Google × mercari に学ぶ！Kubernetesの活用法とセキュリティ

Transcript

1. 1
   How to secure your
   Kubernetes cluster
   on Google Cloud
   セキュアなGKEクラスタのつくりかた
   Mercari Security Engineering
   末澤 裕希 (@rung)
   Oct 14, 2021
   Google × Mercari に学ぶ！
   Kubernetesの活用法とセキュリティ
   v1.00
   

   View Slide

2. 2
   Caution
   ● 本発表は、2020年4月に”Kubernetes Meetup Tokyo”にて発表した”Kubernetes
   Security For Microservices”から資料の一部を再利用した上で、発展的内容を記載し
   ています
   ○ 具体的なKubernetesへの攻撃手法などについては上記資料に記載しています
   ● 対象としては、Kubernetesを触ったことのある方を想定しています
   

   View Slide

3. 3
   伝えたいこと
   メルカリのシングルクラスタにおけるセキュリティ戦略の紹介
   

   View Slide

4. 4
   本日の流れ
   1. メルカリにおける、マルチテナント構成の
   Kubernetesをセキュア化した事例紹介
   2. セキュア化を実施してきた中での課題
   3. 今後、どのようなセキュリティ戦略を進めていくべきかについての基本方針を紹介
   

   View Slide

5. View Slide

6. 6
   ● Title
   ○ Security Engineer at Mercari, Inc.
   ● Career
   ○ https://www.suezawa.net
   ● Kubernetes/コンテナセキュリティの直近の活動
   ○ [Podcast] Container Security with rung
   ■ https://e34.fm/4/
   ○ [登壇] Kubernetes Security For Microservices
   ■ https://speakerdeck.com/rung/kubernetes-
   security-for-microservices
   ● Others
   ○ 趣味: コンピュータ (Go, Network Protocols, Linux…),
   本読み, 紅茶飲み
   ○ 資格: CKS, GXPN, GREM, OSEP, CISSP...
   @rung
   @rung
   suezawa@mercari.com
   末澤 裕希
   (Hiroki SUEZAWA)
   

   View Slide

7. 7
   Introduction
   

   View Slide

8. 8
   インフラ管理の変遷
   ● Infrastructureはインフラチームだけのものだけでなく、開発者も関わるように
   ○ DevOps
   ○ Cloud Infrastructure
   ● 全開発者がインフラに関わるように
   ○ Developer ExperienceとSecurityの両立が必要
   Infrastructure Team SRE Developers
   Cloud Infrastructure
   Development
   Deployment
   Operation
   

   View Slide

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

   View Slide

10. 10
    ● Single Cluster: 複数のMicroservices(チーム)が同じクラスタを利用
    ○ Kubernetes(Google Kubernetes Engine)を利用
    ○ 2017年より本格運用
    Kubernetes Clusters on Mercari
    API gateway
    Authority
    Service A
    Spanner
    Google Kubernetes Engine
    Cloud SQL
    Service B
    

    View Slide

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

12. 12
    Kubernetes Runtime Security
    2017〜2020: 従来クラスタの一般的なセキュア化
    (詳細は”Kubernetes Security For Microservices”を参照してください)
    

    View Slide

13. 13
    Node
    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

14. 14
    一般的なコンテナのコンセプト
    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

15. 15
    Managed by GCP
    API Server
    Node
    Kubelet kube-proxy
    Admin/
    Developer
    GCE Metadata
    Kubernetes
    API
    Pod A Pod B Pod C
    PodからNodeレベルの
    クレデンシャルにアクセス可能
    開発者は最小限の権限
    のみ所有すべき
    Pod A Pod B
    Pod C
    Network制限なし
    高権限Podを作成可能
    ※NodeからはコンテナのSecretを読み取れる
    Kubernetes is not secure by default
    GCP固有
    

    View Slide

16. 16
    ● 一番防ぎたいシナリオ
    ○ 攻撃者によるコンテナへの侵入 -> 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

17. 17
    MITRE ATT&CK for Kubernetes
    Microsoft “Secure containerized environments with updated threat matrix for Kubernetes”
    ● 攻撃のTTPs(Tactics, Techniques and Procedures)
    

    View Slide

18. 18
    2017-: Secure Kubernetes Infrastructure
    RBACによる
    最小権限
    他者承認必須
    Auth
    Infrastructure
    as code
    CI/CD
    Admission
    Controller
    Standard Node
    webhook
    Gatekeeper
    ・高権限Podの制限
    *その他ImageScanning、
    Binary Authorizationも実施
    API Requestへ
    のNetwork制限
    Microservice A
    Microservice B
    Microservice C
    弱いIsolation
    - 高権限Podの各種制限
    - Workload Identity (Cloud Metadata無効化)
    - Network Policyによるネットワーク制限
    - Sysdig Secureを用いたMonitoring, Audit
    Keyless
    Keyless
    Keyless
    Kubernetesのオペレーション
    障害対応など
    ● セキュリティ対策をクラスタに足していく
    発想
    ○ Gatekeeper
    ○ Network Policy
    ○ Workload Identity
    ○ Sysdig Secure
    

    View Slide

19. 19
    Security Monitoring, Audit, Incident Response
    ● Kubernetesクラスタのセキュア化を実施しても、攻撃自体を全て防ぐことはできない
    ○ Detect, Respondにも目を向ける必要性
    ● Prevensionだけでなく、監視やインシデント対応を見据える
    ○ メルカリではSysdig Secureを活用
    ■ オープンソースとの親和性, 検知ルールの柔軟さ
    ○ Security Monitoringの実施
    ■ 重要な観点: いかに権限昇格を防ぐか
    ○ Security Audit Logsの取得
    ○ Sysdig InspectによるForensics
    * NIST “The Cybersecurity Framework”より
    

    View Slide

20. 20
    (参考) Sysdig Secure
    ● Sysdig SecureはオープンソースのFalcoルールを使用
    ○ メルカリでは独自ルールの作成および、デフォルトの
    Falcoルールを利用して監視に
    活用
    ○ インシデント発生時に追加ルールを即時入れられる点も評価
    ● Sysdig Secureの持つAudit機能によりコマンドやネットワーク履歴を保持し、統制・イン
    シデント時の活用
    ● Sysdig Inspectによるインシデント時のフォレンジック調査
    ● その他、Runtimeの領域以外にもコンテナイメージスキャンなども活用
    

    View Slide

21. 21
    (参考) Sysdig Inspect
    ●
    Sysdig Inspect | Container Troubleshooting and Securityより
    

    View Slide

22. 22
    Kubernetesセキュア化の課題
    

    View Slide

23. 23
    大規模クラスタ運用 4年の変化
    ● Kubernetesのエコシステムは急速に発展
    ○ 2017
    ■ セキュリティを守るためのコンポーネントの安定化を待ちながら、新たなセキュリ
    ティ対策を、都度導入していく
    ○ 2021
    ■ 最初からセキュリティを設計に組み込むことができる
    ● Complexity vs Understandability
    2017〜 2021〜
    - Securityをアドオンする発想
    “複雑な対策”・”成熟していないセキュリティ対
    策”を組み合わせてセキュリティを強化
    - Securityが組み込まれている発想
    成熟したセキュリティ対策を活用し、 Secure
    By Defaultになっている間違えないクラスタ
    構成へ
    

    View Slide

24. 24
    (参考) コンテナに起因する複雑なセキュリティ対策
    Mercari Engineering Blog
    “Enhance Kubernetes Security with OPA
    Gatekeeper”
    ● メルカリセキュリティチームが危険な
    Kubernetes設定を一覧化
    ○ 例: 各Capabilityなどの持つ各危険性を説明
    ○ Platform Team(SRE)との協力を行い、Gatekeeperを用いて、危険なコンテナの
    デプロイを防ぐ
    ■ 課題: 危険な設定を、Block List方式で潰していくアプローチになっており、予期
    せぬ設定漏れなどが発生しやすい
    【検討項目例】
    ● Local HostPath
    ● hostIPC
    ● hostPID
    ● hostNetwork
    ● securityContext
    ○ Privileged
    ○ Additional capabilities
    ○ allowPrivilegeEscalation
    ○ readOnlyRootFilesystem...
    

    View Slide

25. 25
    なぜKubernetes Securityが難しかったのか
    ● Kubernetes is not secure by default
    ○ Isolationを実現するためのコンポーネントの複雑性
    ■ Gatekeeper - 高権限コンテナ制限
    ● 適切な設定管理: Privileged Container, Capability, AppArmor,
    host mount, host network...
    ■ Network Policy - Network制限
    ■ RBAC - Namespacesごとの権限分離
    ■ Cloud Metadataの無効化
    ■ Mutual TLS
    ● 間違えやすいSecurity対策
    ○ Block List方式で追加すると抜け漏れも発生しやすい
    Kubernetesの成熟に伴い、 間違えないSecure by defaultな
    クラスタ設計を目指していく
    

    View Slide

26. 26
    これからのGKEセキュリティ戦略
    Secure by defaultなクラスタ設計
    

    View Slide

27. 27
    2021: Secure Kubernetes 全体像
    Tooling and
    Automation
    Breakglass 他者承認必須
    Auth
    Infrastructure
    as code
    CI/CD
    Access granting in
    emergency (Clutch)
    Reliable
    automation(Clutch)
    Admission
    Controller
    Shielded GKE nodes
    webhook
    Gatekeeper
    ・gVisor強制
    *その他ImageScanning、
    コンテナの署名確認も実施
    Private Node
    API Requestへ
    のNetwork制限
    Microservice A
    Microservice B
    Microservice C
    強いIsolation
    - gVisor (高権限Podの廃止)
    - Workload Identity (NodeレベルのCloud Metadata無効化)
    - Network Policy (Deny Allのネットワーク制御)
    - Istio (mtls)
    * Shielded GKE nodes (Metadata上のk8s認証情報削除)
    Keyless
    Keyless
    Keyless
    Kubernetesのオペレーション Keyword: Secure by default
    

    View Slide

28. 28
    GKE Sandbox (gVisor)
    ● gVisor: Secure Container Runtimeの一般化
    ○ 脆弱性に繋がる高権限なコンテナをふせぐ
    ○ Kernelの脆弱性への耐性も持つ
    ● Gatekeeper設定のシンプル化
    “gVisor Security Basics - Part 1”
    Kubernetes Manifestの複雑な制限
    【検討項目例】
    ● Local HostPath
    ● hostIPC
    ● hostPID
    ● hostNetwork
    ● securityContext
    ○ Privileged
    ○ Additional capabilities
    ○ allowPrivilegeEscalation
    ○ readOnlyRootFilesystem...
    シンプル化
    ● runtimeClassName: gvisorの強制
    ● NET_RAW capabilityの禁止
    

    View Slide

29. 29
    (参考) GKE AutoPilot
    ● GKE AutoPilot Mode: 2021年2月に登場
    ○ gVisorを強制するクラスタ
    ■ 高い権限を持ったコンテナはそもそも利用できない
    ■ 従来モードだと可能だったノードへの接続もできない
    ○ Standard Mode(従来モード)の柔軟性が必要ない場合は、AutoPilotの活用で
    Kubernetesの柔軟性・エコシステムの利用と、セキュリティの確保の両方をシンプル
    に実現可能
    ○ Shared Responsibility Model観点での変化
    ■ ユーザが責任を持っていたノードの管理が
    Google管理に
    

    View Slide

30. 30
    Access Control - Zero Touch Prod
    ● Zero Touch Prod
    ○ Googleの提唱する概念
    SRECon2019 EMEA “Zero Touch Prod”
    人が直接クラスタを触らない構成へ
    

    View Slide

31. 31
    Access Control - Automation for Zero Touch Prod
    ● Infrastructure as codeだけでなく、必要に応じて、ツール・オートメーションを通じてプロダクション
    の操作を行う
    ○ Googleは”Secure Proxy”を通して、CLIでの設定変更の安全性チェック , Rate Limitの制御
    など実現
    ○ 安全な設定変更を、他者の承認なども通した上で実施する
    ■ MPA (Multi-Party Authorization)
    ● アクセス権限付与には他者承認を必須にする
    ○ 設定のミスやInsider Riskを防ぐ
    ■ Three-Factor Authorization (3FA)
    ● 特定の操作リクエストに対する、他の社内 Platform(モバイル端末など)からの承
    認を行う * ユーザ認証を承認するのではなく、操作リクエストを承認する
    ○ Workstationの侵害による影響を防ぐ
    ■ Temporary Access
    ● アクセスは一時的なものに絞る
    Building Secure & Reliable Systemsより
    

    View Slide

32. 32
    Access Control - Least Privilege
    ● Audited Breakglass mechanism
    ○ 非常時に、ツール・オートメーションの
    Policyをバイパスして操作を行うための仕組み
    ○ Reliability vs Security
    ■ ユースケース: 即座の障害復旧などが求められる場面
    ■ ツール・オートメーションで対応しきれないとき、強い権限での緊急マニュアルオ
    ペレーションを許可
    ● 例外的な操作であり、セキュリティチームなどに、厳しくモニターされる
    

    View Slide

33. 33
    (参考) Clutch
    ● メルカリではClutchなどを活用しZero Touch Prodの実現を推進
    ○ 例: Least Privilegeを徹底. 通常は必要最小限の権限しか与えずに、必要に応じて
    他者承認による一時的な権限付与を実施
    (Breakglass)
    ● 各レイヤの操作手段を用意することによる、
    SecurityとReliabilityの両立
    https://github.com/lyft/clutch
    Layer Description
    Infrastructure as
    Code
    Infrastructure as codeによる設定変更
    Tooling and
    Automation
    Safety Checksなどを通じた本番への
    indirectな操作での安全なオペレーション
    Breakglass 非常時の緊急オペレーション
    

    View Slide

34. 34
    Network Restriction
    ● Private clusters with authorized networks
    ○ Kubernetes API(Master Node)はアクセス制御
    ○ 各NodeはPublic IPを持たない状態にする
    ● Network Policies (コンテナの通信ルール制御)
    ○ Deny allをデフォルトとする設計
    ○ 必要に応じて許可していく設計にする
    ■ コンテナ間通信・コンテナ外通信が許可ベースの制御に
    ● Mtls (Istio)
    ○ コンテナ間認証および暗号化
    Microservice A Microservice B
    Microservice C
    allow
    deny
    ☓
    K8s API
    allow deny
    ☓
    

    View Slide

35. 35
    Workload Identity
    ● 以前は、コンテナからMetadataサービスNodeレベルのクレデンシャルが取得できた
    ○ Workload Identityの有効化により取得できなくなる
    ● Workload Identity: Workload(コンテナ)単位でのコンテナへの権限付与が行える
    ○ Keylessの実現
    ■ コンテナからGoogleのデータベースなどに接続する際、静的なクレデンシャル
    をKubernetes Secretなどを用いて設定する必要がない
    ■ 一時的なトークンをコンテナ上から取得できる
    (Metadataサービス経由)
    ● GCPサービスアカウントキーのダウンロードが不要
    Microservice A
    Namespace A
    GCP Service Account
    binding
    keyless Cloud
    Spanner
    

    View Slide

36. 36
    (再掲)2021: Secure Kubernetes 全体像
    Tooling and
    Automation
    Breakglass 他者承認必須
    Auth
    Infrastructure
    as code
    CI/CD
    Access granting in
    emergency (Clutch)
    Reliable
    automation(Clutch)
    Admission
    Controller
    Shielded GKE nodes
    webhook
    Gatekeeper
    ・gVisor強制
    *その他ImageScanning、
    コンテナの署名確認も実施
    Private Node
    API Requestへ
    のNetwork制限
    Microservice A
    Microservice B
    Microservice C
    強いIsolation
    - gVisor (高権限Podの廃止)
    - Workload Identity (NodeレベルのCloud Metadata無効化)
    - Network Policy (Deny Allのネットワーク制御)
    - Istio (mtls)
    * Shielded GKE nodes (Metadata上のk8s認証情報削除)
    Keyless
    Keyless
    Keyless
    Kubernetesのオペレーション Keyword: Secure by default
    

    View Slide

37. 37
    ● Secure by defaultなクラスタ設計により、安心して多くの攻撃からの防御・緩
    和が可能な状態に
    MITRE ATT&CK for Kubernetes
    Microsoft “Secure containerized environments with updated threat matrix for Kubernetes”
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation
    Mitigation Mitigation
    

    View Slide

38. 38
    課題および今後の期待
    ● 各セキュリティソリューションはGKE Sandbox(gVisor)にいまだ未対応
    ○ 現状: SysdigおよびGoogle Cloud提供の”Container Threat Detection”は
    gVisorに未対応
    ○ GoogleおよびSysdigの対応に期待
    ● Detect, Respondの観点のソリューションの必要性と期待
    ○ インテリジェントなSecurity Monitoring
    ■ Nodeへの権限昇格よりも、クラスタをセキュア化しても残る下記のような攻撃を
    検知したい
    ● Supply Chain攻撃
    ● アプリケーション脆弱性を突いた攻撃
    ○ Security Audit
    ■ コンテナ上の動作記録
    ○ Forensics
    ■ コンテナ上で発生している事象の詳細把握
    

    View Slide

39. 39
    Summary
    ● メルカリのシングルクラスタにおけるセキュリティ戦略の紹介
    ○ 従来のKubernetes Securityの振り返り
    ○ Kubernetesの成熟化・エコシステムの発展により可能になった、セキュリ
    ティ戦略について紹介
    ■ Secure by defaultの徹底
    ■ 安全なクラスタ運用の実現
    

    View Slide

40. 40
    References
    ● Mercari’s presentation and blogs 

    ○ Kubernetes Security for Microservices 

    ○ Scaling Kubernetes Tenant Management with Hierarchical Namespaces
    Controller
    ○ Enhance Kubernetes Security with OPA Gatekeeper
    ● Taichi Nakashima “Zero Touch Productionとは何か”
    ● Heather Adkins, Betsy Beyer, Paul Blankinship, Ana Oprea, Piotr Lewandowski, Adam
    Stubblefield “Building Secure & Reliable Systems”
    ● Michał Czapiński, Rainer Wolafka “Zero Touch Prod: Towards Safer and More Secure
    Production Environments”
    ● Maya Kaczorowski, Ann Wallace”Container Forensics: What to Do When Your Cluster
    is a Cluster”
    ● Liz Rice “Container Security”
    ● Microsoft “Secure containerized environments with updated threat matrix for
    Kubernetes”
    ● Special Thanks: @keke, @deeeet
    

    View Slide

41. 41
    We are hiring!
    ● メルカリのセキュリティチームは新しい仲間を探しています
    ○ エンジニアだけではなく、各種セキュリティのポジションがあります
    “YOUR CHOICE”
    日本全国から働けるようになりました
    

    View Slide