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
2. 2 Caution • 本発表は、2020年4月に”Kubernetes Meetup Tokyo”にて発表した”Kubernetes Security For Microservices”から資料の一部を再利用した上で、発展的内容を記載し ています ◦ 具体的なKubernetesへの攻撃手法などについては上記資料に記載しています • 対象としては、Kubernetesを触ったことのある方を想定しています
3. 3 伝えたいこと メルカリのシングルクラスタにおけるセキュリティ戦略の紹介
4. 4 本日の流れ 1. メルカリにおける、マルチテナント構成の Kubernetesをセキュア化した事例紹介 2. セキュア化を実施してきた中での課題 3. 今後、どのようなセキュリティ戦略を進めていくべきかについての基本方針を紹介
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)
7. 7 Introduction
8. 8 インフラ管理の変遷 • Infrastructureはインフラチームだけのものだけでなく、開発者も関わるように ◦ DevOps ◦ Cloud Infrastructure • 全開発者がインフラに関わるように ◦ Developer ExperienceとSecurityの両立が必要 Infrastructure Team SRE Developers Cloud Infrastructure Development Deployment Operation
9. 9 Microservices • Microservicesは組織のプラクティスでもある ▪ 各チームが、それぞれのMicroservicesの開発・運用に責任 SRE Practices in Mercari Microservices - Taichi Nakashima
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
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
12. 12 Kubernetes Runtime Security 2017〜2020: 従来クラスタの一般的なセキュア化 (詳細は”Kubernetes Security For Microservices”を参照してください)
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
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 コンテナ上からノードに権限昇格されてしまうと、別のコンテナを侵害されてしまう
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固有
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 情報窃取 情報窃取
17. 17 MITRE ATT&CK for Kubernetes Microsoft “Secure containerized environments with updated threat matrix for Kubernetes” • 攻撃のTTPs(Tactics, Techniques and Procedures)
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
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”より
20. 20 (参考) Sysdig Secure • Sysdig SecureはオープンソースのFalcoルールを使用 ◦ メルカリでは独自ルールの作成および、デフォルトの Falcoルールを利用して監視に 活用 ◦ インシデント発生時に追加ルールを即時入れられる点も評価 • Sysdig Secureの持つAudit機能によりコマンドやネットワーク履歴を保持し、統制・イン シデント時の活用 • Sysdig Inspectによるインシデント時のフォレンジック調査 • その他、Runtimeの領域以外にもコンテナイメージスキャンなども活用
21. 21 (参考) Sysdig Inspect • Sysdig Inspect | Container Troubleshooting and Securityより
22. 22 Kubernetesセキュア化の課題
23. 23 大規模クラスタ運用 4年の変化 • Kubernetesのエコシステムは急速に発展 ◦ 2017 ▪ セキュリティを守るためのコンポーネントの安定化を待ちながら、新たなセキュリ ティ対策を、都度導入していく ◦ 2021 ▪ 最初からセキュリティを設計に組み込むことができる • Complexity vs Understandability 2017〜 2021〜 - Securityをアドオンする発想 “複雑な対策”・”成熟していないセキュリティ対 策”を組み合わせてセキュリティを強化 - Securityが組み込まれている発想 成熟したセキュリティ対策を活用し、 Secure By Defaultになっている間違えないクラスタ 構成へ
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...
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な クラスタ設計を目指していく
26. 26 これからのGKEセキュリティ戦略 Secure by defaultなクラスタ設計
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
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の禁止
29. 29 (参考) GKE AutoPilot • GKE AutoPilot Mode: 2021年2月に登場 ◦ gVisorを強制するクラスタ ▪ 高い権限を持ったコンテナはそもそも利用できない ▪ 従来モードだと可能だったノードへの接続もできない ◦ Standard Mode(従来モード)の柔軟性が必要ない場合は、AutoPilotの活用で Kubernetesの柔軟性・エコシステムの利用と、セキュリティの確保の両方をシンプル に実現可能 ◦ Shared Responsibility Model観点での変化 ▪ ユーザが責任を持っていたノードの管理が Google管理に
30. 30 Access Control - Zero Touch Prod • Zero Touch Prod ◦ Googleの提唱する概念 SRECon2019 EMEA “Zero Touch Prod” 人が直接クラスタを触らない構成へ
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より
32. 32 Access Control - Least Privilege • Audited Breakglass mechanism ◦ 非常時に、ツール・オートメーションの Policyをバイパスして操作を行うための仕組み ◦ Reliability vs Security ▪ ユースケース: 即座の障害復旧などが求められる場面 ▪ ツール・オートメーションで対応しきれないとき、強い権限での緊急マニュアルオ ペレーションを許可 • 例外的な操作であり、セキュリティチームなどに、厳しくモニターされる
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 非常時の緊急オペレーション
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 ☓
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
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
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
38. 38 課題および今後の期待 • 各セキュリティソリューションはGKE Sandbox(gVisor)にいまだ未対応 ◦ 現状: SysdigおよびGoogle Cloud提供の”Container Threat Detection”は gVisorに未対応 ◦ GoogleおよびSysdigの対応に期待 • Detect, Respondの観点のソリューションの必要性と期待 ◦ インテリジェントなSecurity Monitoring ▪ Nodeへの権限昇格よりも、クラスタをセキュア化しても残る下記のような攻撃を 検知したい • Supply Chain攻撃 • アプリケーション脆弱性を突いた攻撃 ◦ Security Audit ▪ コンテナ上の動作記録 ◦ Forensics ▪ コンテナ上で発生している事象の詳細把握
39. 39 Summary • メルカリのシングルクラスタにおけるセキュリティ戦略の紹介 ◦ 従来のKubernetes Securityの振り返り ◦ Kubernetesの成熟化・エコシステムの発展により可能になった、セキュリ ティ戦略について紹介 ▪ Secure by defaultの徹底 ▪ 安全なクラスタ運用の実現
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
41. 41 We are hiring! • メルカリのセキュリティチームは新しい仲間を探しています ◦ エンジニアだけではなく、各種セキュリティのポジションがあります “YOUR CHOICE” 日本全国から働けるようになりました