安全な Kubernetes 環境を目指して

Kubernetes Novice Tokyo #30 の登壇資料です。2024/02/08
https://k8s-novice-jp.connpass.com/event/300441/

Transcript

1. 安全な Kubernetes 環境を 目指して @kyohmizu Kubernetes Novice Tokyo #30
2. whoami Security Engineer at 3-shake inc. • Container/Kubernetes Security • AWS/Google Cloud Security • Security Operations & Technical Support for Blue Team • Cloud Native Security Assessment Others: • 3-shake SRE Tech Talk イベント運営 • 「コンテナセキュリティ」書籍監訳 Kyohei Mizumoto
3. 本セッションについて ゴール • 基本的なセキュリティの観点を知る • Kubernetes 環境のセキュリティ対策とその運用について考える ターゲット • Kubernetes クラスタの管理者、運用者 • Kubernetes のセキュリティ担当者 • Kubernetes のセキュリティに興味がある人 ※ 概念的な内容や運用の話がメインとなるため、具体的なツールの紹介は少なめです
4. Agenda 01 基本的なセキュリティの観点を知る 02 Kubernetes のセキュリティを知る ・Kubernetes の脅威動向 ・Kubernetes のセキュリティ概要 03 安全な Kubernetes 環境を目指して ・セキュリティポスチャー ・脆弱性対策 ・その他のセキュリティ対策
5. 基本的なセキュリティの観点を知る 01
6. 情報セキュリティ3要素 情報セキュリティのCIA • 機密性（Confidentiality） ◦ 許可された者だけが情報にアクセスできるようにすること • 完全性（Integrity） ◦ 保有する情報が正確であり、完全である状態を保持すること ◦ 報が不正に改ざんされたり、破壊されたりしないこと • 可用性（Availability） ◦ 許可された者が必要なときにいつでも情報にアクセスできるようにすること ◦ 情報を提供するサービスが常に動作すること 情報セキュリティ ＝ 情報資産をCIAに対する脅威から保護する取り組み https://www.soumu.go.jp/main_sosiki/cybersecurity/kokumin/business/business_executive_02.html
7. 情報セキュリティの脅威とCIA ランサムウェア • データを暗号化されることによる完全性、可用性への影響 • 情報窃取による機密性への影響（二重強迫） サプライチェーンの弱点を悪用した攻撃 • データへの不正アクセスによる機密性への影響 • データの改ざんや破壊による完全性、可用性への影響 標的型攻撃による機密情報の窃取 • データへの不正アクセスによる機密性への影響 https://www.ipa.go.jp/security/10threats/10threats2023.html （情報セキュリティ10大脅威 2023 より）
8. 最小権限（Least Privilege）は、 認証・認可を管理する上で不可欠 の原則です。 クラウドネイティブ環境における最 小権限の原則は、アカウント管理 に限らず、コードレベルからクラウ ドインフラに至るまですべてのレイ ヤーで適用することを求められま す。 職務分掌（Separation of Duties）は、担当者の持つ役割 と権限、責任範囲を明確にする ことを指します。 DevOpsのような境界が曖昧な 環境では、開発者と運用者が担 うセキュリティ対策の責任範囲 について、あらかじめ定義してお くことは特に重要です。 セキュリティの原則 多層防御（Defense in Depth） は、複数レイヤーのセキュリティ対 策を組み合わせることで、システム 全体のセキュリティを包括的に高 めるアプローチです。 クラウドネイティブ環境では、従来 のアプリ・インフラレイヤーに加え て、コンテナ・クラスタレイヤーのセ キュリティ対策を実施する必要が あります。 Defense in Depth Least Privilege Separation of Duties
9. セキュリティ対策の分類 侵入防止策 • システム内に侵入されることを未然に防ぐ、または追加の侵入を防ぐ • 攻撃コストを高くすることで、攻撃を諦めさせる 検知策 • システム内に侵入を試みる活動や、侵入後の活動を検知し対応策に繋げる • データの改ざんや破壊による完全性、可用性への影響 侵入後対策 • システム内に侵入された際の影響範囲を小さくする、攻撃コストを高くする • 影響範囲や被害状況の調査、攻撃者の排除、システムの復旧など FIRST STEP!!
10. セキュリティ対策の費用対効果 費用（Cost） • 導入運用費（サービス利用料、人件費）、対策導入に伴う 生産性（競争力）の低下 効果（Effectiveness） • 対策導入によるリスク 差分、セキュリティ品質向上に伴う競争力向上、運用効率化による生産 性（競争力）向上 セキュリティ予算の範囲内で 「効果 - 費用」を最大化する
11. Rule-Based vs Risk-Based システムを取り巻くリスクを評価し、システ ムの状況や求められるセキュリティ水準を 踏まえて、リスクの最小化に取り組みます。 リスクベースアプローチは、組織やシステム 固有のリスクに対応しやすく、本当に必要 なセキュリティ対策に注力できます。 一方で、リスク評価にはセキュリティの専門 性や自組織・システムへの深い理解が必要 であり、成熟度の高い組織でなければ有効 活用は難しいでしょう。 あらかじめ実現すべきセキュリティレベルを 定義し、必要な対策をシステムに一律に適 用します。 ルールベースアプローチには、明確なセ キュリティ基準が確立される、全従業員・全 システムへの展開が容易、リスク評価を待 たずに実装できるなどのメリットがありま す。 一方で、全ルールを適用するコストが高 い、ルールが陳腐化しやすい、特定のシス テムに固有のリスクに対応しづらいなどの デメリットがあります。 Rule-Based Risk-Based FIRST STEP!!
12. 参考：脅威モデリング システムの潜在的な脅威を特定し、対策の優先順位を決定するプロセス アーキテクチャの理解 • システムのコアコンポーネント、ソースコードの場所や開発ライフサイクルなど 脅威の特定 • STRIDE、OCTAVE などの脅威モデルを利用 脅威アクターの定義 • 外部攻撃者 - 外部からインターネット、サプライチェーンなどを介した攻撃を行う • 内部攻撃者 - システムに侵入することに成功した攻撃者、悪意のある組織内の関係者 • 内部関係者 - 不注意などで問題を引き起こす可能性のある組織内の関係者
13. 参考：脅威インテリジェンス 潜在的な脅威について収集されたデータ、またはデータを収集、処理、分析するプロセス 収集方針の決定 • 保護すべきシステムの理解と優先順位づけ データ収集 • システム内のメトリクスやトラフィックログ • 利害関係者やセキュリティ機関からもたらされる情報、オープンなニュース記事など 分析・対処 • 収集されたデータを利用できる形式に変換、他データとの照合 • 脅威に対するアクションの決定
14. Kubernetes のセキュリティを知る 02
15. Kubernetes の脅威動向
16. TeamTNT: Cloud Attack Campaign https://blog.aquasec.com/teamtnt-reemerged-with-new-aggressive-cloud-campaign Docker/Kubernetes を標的としたボットネット感染、情報窃取の攻撃キャンペーン
17. Kinsing Malware PHPUnit や WordPress などの脆弱なコンテナイメー ジを主に悪用。 また PostgreSQL コンテナの設定ミスを利用し、 Kubernetes 環境への初期アクセスを獲得。 コンテナ環境を標的とするクリプトマイナー https://techcommunity.microsoft.com/t5/microsoft-defender-for-cloud/initial-access-techniques-in-kubernetes-environments-used-by/ba-p/3697975
18. Threat Matrix https://attack.mitre.org/matrices/enterprise/ https://www.microsoft.com/en-us/security/blog/2020/04/02/attack-matrix-kubernetes/
19. OWASP Kubernetes Top 10 • K01: Insecure Workload Configurations（安全でないワークロードの設定） • K02: Supply Chain Vulnerabilities（サプライチェーンにおける脆弱性） • K03: Overly Permissive RBAC Configurations（過剰なRBACの権限設定） • K04: Lack of Centralized Policy Enforcement（一元化されたポリシー適用の欠如） • K05: Inadequate Logging and Monitoring（不十分なロギングと監視） • K06: Broken Authentication Mechanisms（認証メカニズムの欠陥） • K07: Missing Network Segmentation Controls（ネットワーク分離の欠如） • K08: Secrets Management Failures（シークレット管理の失敗） • K09: Misconfigured Cluster Components（クラスタコンポーネントの設定ミス） • K10: Outdated and Vulnerable Kubernetes Components（古く脆弱なk8sコンポーネ ント） https://owasp.org/www-project-kubernetes-top-ten/
20. Kubernetes のセキュリティ概要
21. クラウドネイティブセキュリティの4C アプリケーションコードの脆弱性対策、依存 関係の脆弱性管理と安全性評価、コードへ のアクセス制御など。 Dockerfileの堅牢化、コンテナイメージの脆 弱性管理と信頼性確認、分離レベルの高い コンテナランタイムの導入など。 クラスタコンポーネントの堅牢化と脆弱性管 理、クラスタ内リソースの堅牢化、ポスチャー 管理、Admission Control、ランタイムセ キュリティなど。 責任共有モデルの理解、セキュリティサービ スを利用したアクセス制御、ポスチャー管 理、不審なアクティビティの監視など。 Code Cluster Container Cloud https://kubernetes.io/docs/concepts/security/overview/
22. 開発ライフサイクルのセキュリティ アプリケーションコードやIaCのコード解析、 テストの開発、開発者によるコードレビューな ど。 CIパイプラインにおけるコード解析、コンテナ イメージの脆弱性スキャン、イメージ署名や 暗号化、アプリケーションの動的解析など。 デプロイ前のセキュリティチェック（イメージ署 名の検証、各種ポリシーの検証）、監視やロ グ機能のデプロイなど。 コンテナホストのセキュリティ、クラスタのセ キュリティ、ID管理とアクセス制御、可用性 の維持など。 Develop Deploy Distribute Runtime https://cnsmap.netlify.app/
23. 4Cと開発ライフサイクル Develop Distribute Deploy Runtime Code SAST、SCA、DAST、OSS の安全性評価、テスト開 発、コードレビュー SAST、SCA、DAST、リポ ジトリのセキュリティ SCA、DAST、脆弱性診断 Container Dockerfile設計、SAST、 SCA、イメージの安全性評 価 SAST、SCA、イメージ署名 ・暗号化 SCA、イメージ署名の検証 サンドボックスコンテナ、ラン タイムセキュリティ、 SCA Cluster Manifest設計、SAST、 SAST ポリシーチェック、監視・ログ ツールの導入 KSPM、クラスタバージョン管 理、ワークロード監視、監査 ログ監視 Cloud IaC設計、SAST SAST ポリシーチェック CSPM、ログ監視
24. Kubernetes Security Best Practices Securing a Cluster - Kubernetes Documentation https://kubernetes.io/docs/tasks/administer-cluster/securing-a-cluster/ Security Checklist - Kubernetes Documentation https://kubernetes.io/docs/concepts/security/security-checklist/ Kubernetes Security Cheat Sheet - OWASP Cheat Sheet Series https://cheatsheetseries.owasp.org/cheatsheets/Kubernetes_Security_Cheat_Sheet.html Security best practices - docker docs https://docs.docker.com/develop/security-best-practices/ Docker Security Cheat Sheet - OWASP Cheat Sheet Series https://cheatsheetseries.owasp.org/cheatsheets/Docker_Security_Cheat_Sheet.html
25. https://speakerdeck.com/kyohmizu/saibagong-ji-kara-kubernetes-kurasutawoshou-rutamefalsexiao-guo-de-nasekiyuriteidui-ce
26. Kubernetes Attack Surface Kubernetes コンポーネントの利用ポート • クラスタの利用ポートと公開範囲を把握 • 不要なポートを閉じる、アクセスを制限する APIサーバへの匿名アクセス • system:anonymous ユーザ • system:unauthenticated グループ • Roleがバインドされないように管理する 正規ユーザの認証情報 • 人やアプリが利用する認証情報の管理と漏洩対策 Port Process 443, 6443, 8443, 8080/TCP kube-apiserver 2379-2380, 6666-6667/TCP etcd 4194/TCP cAdvisor 10257/TCP kube-controller-manager 10259/TCP kube-scheduler 10250, 10255/TCP kubelet 10256/TCP kube-proxy 30000-32767/TCP NodePort
27. 安全な Kubernetes 環境を目指して 03
28. セキュリティポスチャー
29. ポスチャー管理（KSPM） KSPMツール • Kubernetes クラスタの網羅的なセキュリティスキャンと状態管理の機能 • ベストプラクティスを適用するためのルールベースのセキュリティ対策 • OSSのスキャンツール ＋ 手動管理 or 有償製品での統合管理 KSPMの運用 • まずはスキャンを実施し、クラスタの状態把握する • 非準拠項目の対応要否、優先度を決定 ◦ リスクの大きさや費用対効果の観点から • 継続的スキャンによるポスチャー監視（設定変更時、定期スキャンなど） • Admission Control に適用することで設定の強制も
30. trivy k8s Kubernetes クラスタの設定ミスを検出 • クラスタコンポーネント、ワークロードの設定ミスや脆弱性のスキャン • 複数データソースをベースにした独自の検出項目 ◦ https://avd.aquasec.com/misconfig/kubernetes/ • Kubernetes Operator による継続的スキャン $ trivy k8s cluster --scanners misconfig --report all --components infra $ trivy k8s cluster --scanners vuln --report summary $ trivy k8s cluster --compliance k8s-cis --report all https://aquasecurity.github.io/trivy/v0.49/docs/target/kubernetes/
31. GKE Security Posture GKEクラスタのセキュリティ管理・運用ダッシュボード • クラスタとワークロードの構成チェック、イメージ脆弱性スキャン • 無料で利用できるのは PSSベースの構成チェックとイメージの OSスキャンのみ • 追加のセキュリティポリシーは GKE Enterprise クラスタのみ利用可能 https://cloud.google.com/kubernetes-engine/docs/concepts/about-security-posture-dashboard?hl=ja
32. 脆弱性対策
33. Kubernetes 環境の脆弱性 アプリケーションコード • ソースコードの脆弱性 • 依存ライブラリの脆弱性 コンテナ • 依存パッケージの脆弱性 Kubernetes クラスタ • クラスタコンポーネント（ kubelet、APIサーバなど）の脆弱性 • コンテナランタイムの脆弱性 • ノードの依存パッケージの脆弱性
34. Kubernetes 環境の脆弱性 アプリケーションコード • ソースコードの脆弱性 • 依存ライブラリの脆弱性 コンテナ • 依存パッケージの脆弱性 Kubernetes クラスタ • クラスタコンポーネント（ kubelet、APIサーバなど）の脆弱性 • コンテナランタイムの脆弱性 • ノードの依存パッケージの脆弱性 公開された脆弱性情報（ CVE） アプリケーション固有の脆弱性
35. 開発ライフサイクルと脆弱性対策 Develop Distribute Deploy Runtime Code SAST、SCA、DAST、OSS の安全性評価、テスト開 発、コードレビュー SAST、SCA、DAST、リポ ジトリのセキュリティ SCA、DAST、脆弱性診断 Container Dockerfile設計、SAST、 SCA、イメージの安全性評 価 SAST、SCA、イメージ署名 ・暗号化 SCA、イメージ署名の検証 サンドボックスコンテナ、ラン タイムセキュリティ、 SCA Cluster Manifest設計、SAST、 SAST ポリシーチェック、監視・ログ ツールの導入 KSPM、クラスタバージョン管 理、ワークロード監視、監査 ログ監視 コードリポジトリ、コンテナリポジトリの定期スキャン
36. 脆弱性対策のポイント 運用負荷の軽減 • コンテナやホストマシンに不要なパッケージを含まない • 脆弱性の通知や評価、修正をできるだけ自動化する • 役割と対応フローを明確にする（例：修正担当者が直接通知を受け取る） 脆弱性の早期発見と網羅性 • ライフサイクルの早い段階で脆弱性を見つけることで、脆弱性の対応コストが低くなる • ライフサイクルの後半になるほど、脆弱性を広範囲に見つけることができる • 複数フェーズで脆弱性対策を導入し、早期発見と網羅性を両立する
37. 脆弱性スキャン（SCA） スキャンツールの選定 • 機能差は気にする程ではないため、基本的には運用しやすいツールを選定する ◦ 同一のツールによる複数レイヤーの脆弱性スキャン ◦ 既存ツールとの統合のしやすさ、脆弱性管理の容易性など • 脆弱性のデータソース、スキャン結果の CVSSバージョンは要確認 SBOM（Software Bill of Materials） • 脆弱性スキャンにおいては、従来のツールとあまり差がない ◦ 資産管理の観点では有用な可能性はある • 網羅性や管理・運用の面で課題が多い印象
38. 脆弱性評価 脆弱性評価の目的 • すべての脆弱性に即時対応するのが理想だが、現実的ではない • 脆弱性の緊急度を判断することで、対応のタイミングを遅らせることができる 評価の際に考慮すべき項目 • システムへの影響の有無 → システム担当者による判断 • 脆弱性の重大度 → CVSSの活用 • 脆弱性の悪用の可能性 → PoCの存在や悪用情報の確認、 EPSSの活用など 評価の自動化 • 人による判断が必要な脆弱性以外を自動処理
39. KubeClarity Kubernetes のSBOMと脆弱性管理 • コンテナイメージからの SBOM生成、イメージ脆弱性と Dockerfileのスキャン • ランタイムスキャン、 CLIツールによるCI/CD連携に対応 https://github.com/openclarity/kubeclarity
40. その他のセキュリティ対策
41. ランタイムセキュリティ 実行中コンテナの追加のセキュリティ対策 • seccomp や AppArmor/SELinux によるコンテナの機能制限 • 振る舞い検知ツールによるプロセスの監視（ Falco, Tracee, Tetragon） 振る舞い検知ツールの導入 • 必要な機能と要件の整理 ◦ デフォルトルールの充実度、プロセス停止機能、管理・運用の容易さ • 有償製品による統合管理（ CNAPP）の検討 振る舞い検知ツールの運用 • まずは実行プロセスのログを保存する • 過検知により対応が難しい場合は、優先度が高い検知項目のみ通知する
42. サプライチェーンセキュリティ 依存関係の安全性評価（≠ 脆弱性） • サードパーティのアプリケーションコードや IaC、ライブラリ、コンテナイメージなど ビルド・デプロイパイプラインのセキュリティ • ジョブ実行基盤へのアクセス制御 • ジョブ定義の変更管理、ジョブに与える権限の最小化 サプライチェーンの対策例 • イメージ署名と検証、信頼性の高い OSSパッケージやコンテナイメージの利用 • SLSAフレームワークを活用したセキュリティ成熟度の向上 • OpenSSF Scorecard によるOSSの安全性評価
43. CREDITS: This presentation template was created by Slidesgo, and includes icons by Flaticon, and infographics & images by Freepik Thanks! Do you have any questions? https://twitter.com/kyohmizu