マスター タイトルの書式設定 Container/Kubernetesのセキュリティ 対策を改めて考える

マスター タイトルの書式設定 自己紹介 ● 名前 : 秋葉 洋毅 (あきば ひろき) ● 所属 : 株式会社オージス総研 ● CNCFとの関係：kubernetes Certified Service Provider(KCSP) (Silver Member) 1

マスター タイトルの書式設定 アジェンダ • Container/kubernetesのセキュリティ対策を考える上での課題感 • Container/kubernetesのセキュリティ対策のおさらい • 我々の取り組みを紹介(現在進行形) 2

マスター タイトルの書式設定 Container/kubernetesのセキュリティ 対策を考える上での課題感 3

マスター タイトルの書式設定 Container/kubernetesのセキュリティ対策の難しさの要因 ① 従来ワークロードに比べContainer/kubernetes(＝k8s)はライフサイクルが短期化 ② 考慮すべきセキュリティ対策項目の層が増加し、より複雑化 ③ 包括的なセキュリティ対策有償製品は高額・一定期間契約などのケースがあり、 スモールスタートで始めるには導入の敷居が高い 4

マスター タイトルの書式設定 課題① Container/k8sのライフサイクルが短期化  外的な側面 ※自社でコントロール出来ない部分 • 3ヶ月毎のk8s本体のバージョンアップデート • 利用しているCNCFエコシステムツールの頻繁な機能アップデートや突然のdeprecated(非推奨、開発停止) • 利用しているパブリッククラウドサービスの頻繁且つ突然の機能アップデート  内的な側面 ※自社である程度コントロール出来る部分 • コンテナ化(≒マイクロサービス化)志向による一定粒度での頻繁なサービス・機能アップデート • 顧客始点のプロダクト開発(≒アジャイル)志向による頻繁なサービス・機能アップデート • CNCF領域(≒SoE、SoI)に向き合うエンジニア達のスキルアップデート 5

マスター タイトルの書式設定 課題② 考慮すべきセキュリティ対策項目が増加し複雑化 • AWSなどのパブリッククラウドやオンプレミスのプライベートクラウド層、仮想サーバ・ネットワーク・ ストレージなどの層に追加して、コンテナ/k8s層のセキュリティ考慮が必要 • コンテナ/k8sクラスタ層においても、セットアップや運用に関して多岐に渡るセキュリティ考慮が必要 などのPublic Cloud オンプレミスなどのPrivate Cloud サーバノード、ストレージやデータベース、ネットワークやロードバランサ、サーバレス、FireWall・暗号化・IAMなど ・kubectlのアクセス制限 ・RBAC ・Network Policy ・TLSブートストラップ ・etc Cluster Setup Hardening Protection Prevention ・k8sクラスタVerアップデート ・k8sノード最適化OS ・IAMロールの最小権限 ・プライベートIPアクセス ・監査ログの監視 ・修正バイナリのデプロイ ・etc ・k8sダッシュボード無効化 ・default SA Tokenの無効化 ・ノードメタデータの防御 ・イメージの脆弱性スキャン ・etc ・Pod Security Policy設定 ・シークレット管理/秘匿 ・サンドボックスの考慮 ・PodのUID/GID制限 ・サービスメッシュ(認証/暗号) ・etc セキュリティ考慮 セ キ ュ リ テ ィ 考 慮 Ref) https://snyk.io/learn/snykcon-securing-kubernetes-in-a-ever-changing-ecosystem/ イ ン フ ラ ・ プ ラ ッ ト フ ォ ー ム 層 6

マスター タイトルの書式設定 課題③ 包括的なセキュリティ対策有償製品は導入コストの敷居が高い Ref) https://www.gartner.com/doc/reprints?id=1-24NFGJO2&ct=201124&st=sb  Cloud Security Posture Management(CSPM) • クラウドインフラスタック全体のセキュリティアセスメント、コンプライアンス、モニタリングを集中管理  Cloud Workload Protection Platform(CWPP) • クラウドワークロード中心のセキュリティ保護と監視 など (2021年1月Redhatに買収された) (旧Twistlock) • Containerやk8s対応のセキュリティサービス群 • 正式な利用価格は各代理店に問い合わせて欲しい が、それなりに高額な価格設定 • スモールスタートだと導入コストの敷居が高いケ ースあり 7

マスター タイトルの書式設定 Container/k8sのセキュリティ対策 のおさらい 8

マスター タイトルの書式設定 Container/k8sの潜在的なセキュリティ脅威 • k8sクラスタやアプリケーションワークロードに対する様々な攻撃インターフェイスが存在する • セキュリティ脅威の例  外部からk8sコントロールプレーンの セキュリティフォールへの攻撃  コンテナやワーカーノードの セキュリティフォールへの攻撃  管理者クレデンシャルの漏洩を狙った攻撃  パーミッション設定ミスを狙った攻撃  etc Ref) https://kubernetes-security.info/ Ref) https://youtu.be/VROFKotfZzw?list=PLbzoR-pLrL6qfNemegyJ19ajZ_6f11qit 9

マスター タイトルの書式設定 Container/k8sセキュリティ対策を考慮する上でのポイント Authz Workload isolate Vulnerability Encryption Backup Firewall Monitoring Authn Governamce / Compliance Security category Boundary of each component Public Cloud k8s Cluster Worker Node Master Node Namespace Pod Container Pod Container Application Application Secret management Ref) https://youtu.be/VROFKotfZzw?list=PLbzoR-pLrL6qfNemegyJ19ajZ_6f11qit 10

マスター タイトルの書式設定 セキュリティカテゴリ毎に対策ツールをマッピング authz workload isolation firewall authn secret management vulnerability monitoring encryption backup governance/compl iance IAM KMS Secret Manager KMS kubesec Kubernetes- External-secret Sealed- secretes Inspector EC2 K8s dashboard Guard Duty ACM Backup System Manager Cloud watch ES ECR Account VPC NW ACL SG EKS WAF Shield Cognito Directory Macie Security HUb Admission Control kubeaudit Security category e.g.) AWS kubernetes Examples of CNCF ecosystem Ref) https://youtu.be/VROFKotfZzw?list=PLbzoR-pLrL6qfNemegyJ19ajZ_6f11qit 11

マスター タイトルの書式設定 限定的 CNCFセキュリティサービス・ツール群を主観で4象限に整理 有償製品 OpenSource 包括的 Popeye ECR DockerHub Synk CSPM/CWPPタイプ 企業志向タイプ など など 個人/有志タイプ クラウドマネージド型タイプ ACR など kubesec hadlint (2021年1月Redhatに買収された) (旧Twistlock) など • 我々はこの領域に特に注 目している • 足らずの部分を機能追加 していきたい • この部分の活動を後述で 説明します 12

マスター タイトルの書式設定 「CNCF cloud native security whitepaper Nov2020」を紹介 • フェーズ毎に考慮すべきセキュリティ対策が網羅的に語られている Ref) https://github.com/cncf/sig-security/blob/master/security-whitepaper/CNCF_cloud-native-security-whitepaper-Nov2020.pdf 13

マスター タイトルの書式設定 我々の取り組みを紹介 (現在進行形) 14

マスター タイトルの書式設定 我々が考える顧客課題と解決アプローチ  顧客課題(仮説設定) ① スモールスタートでContainer/k8sの開発・運用を始めたいが、一定のセキュリティ対策も確保し たい ② 深い知識が無くてもセキュリティチェック実行と、その結果を容易に確認したい  我々が考える解決アプローチ ① 利用するパブリッククラウドのセキュリティ対策機能の足らずの部分を、出来るだけ包括的にOSS セキュリティ対策ツールで補完する ② Container/k8sのセキュリティチェックアセットの提供及び、チェック結果をWeb画面で確認出来 る様にする ※OSSを採用する上での考慮事項(私の所感ですが、多くの人の共通認識だと思う) • 採用するOSSの開発アクティブ度(将来性含む)、守備/連携範囲などの目利きが必要 • 採用するOSSと向き合う覚悟と許容が必要 • 各OSSを適材適所で組み合わせ、使いこなすエンジニア能力が必要 15

マスター タイトルの書式設定 我々が考える解決アプローチ① (現在進行形) 16

マスター タイトルの書式設定 我々が注目したAqua Security社のStarboardを紹介 Ref) https://github.com/aquasecurity/starboard ・Starboard-cli ・Kubectl-cli ・IDE ・Web browser ・Starboard-cli ・Starboard-OLM Check target with starboard namespace master/worker node ,etc 各ツールがk8sクラスタやk8sオブジェクト リソースをチェック & レポート • Aqua Security社が開発するk8sランフェーズのOSSセキュリティチェックツールキット • 複数OSSチェックツールを同一の実行インターフェースでチェック&レポート ※CRDで実装 • Operator LifeCycle Manager(OLM)、Krew、Octant Plugin、Lens extensionなどに対応 Pull Container Image 17

マスター タイトルの書式設定 Aqua Security社のStarboardの守備範囲を再確認 • あくまでk8s Runフェーズ向けのチェックツール • 現時点でStarboardは4つのOSSツールのみをサポート • レポート可視化(Octant Plugin、Lens Extension)は、一定の知識を有する開発者/SRE者向け Ref) https://medium.com/microservices-for-net-developers/how-to-run-your-devops-using-kubernetes-e640a461d726 Devs/SREなど Lens (IDE風) Octant (Desktop Application風) チェックレポート の閲覧(k8s API) チェック実行 (k8s API) 18

マスター タイトルの書式設定 Starboardへのチェック機能拡張の検討プロセス  Starboardの足らずのチェック機能の拡張を検討するにあたり前提とした方針 • 一から新たなチェックツールを開発するには我々のスキルが不足していると判断し既存OSSで模索 • Starboardと親和性の高いRunフェーズをカバーするチェックツールで模索 • Starboardの既存4つのチェックツールでカバー出来ていない領域で模索  候補にあがったOSS例  Podのワーカノード再配置  旧k8s、旧Helm API Verチェック  K8s manifest best practiceチェック  Docker file best practiceチェック  未使用なk8sリソースチェック  k8sワークロードのリスクアセスメント  コンテナAnomaly検知  k8sポリシーチェック Popeye  CPU/MEM定義と使用率チェック hadlint monitoring governance/compliance vulnerability workload isolation Descheduler など 19

マスター タイトルの書式設定 OSS候補の中からPopeyeを選定しStarboardに組み込んでみた コンテナイメージの静的な脆弱性チェック CIS k8s Benchmark準拠チェック k8sクラスタのペネトレーションテスト k8s pod/container manifestベストプラクティスチェック Ref) https://aquasecurity.github.io/starboard/latest/ Ref) https://github.com/derailed/popeye • コンセプトは「k8s cluster sanitizer」 • pod/node statusやCPU/MEM使用率高チェック • k8s manifestベストプラクティスチェック • 未使用k8sオブジェクトリソースチェック • etc • 社内開発環境では実装及び動作確認済み • 当該アイデアをStarboard Github > Discussionで相談中 • 最終的にはStarboard Github > Issue/PRのコントリビュートを視野にアップデート中 Popeye 20

マスター タイトルの書式設定 OSS候補の中から、なぜPopeyeを選定したのか  機能性の観点 • Starboardがカバーしていない未使用k8sオブジェクトリソース(SA,ClusterRole,Secretなど) のチェックが出来る • 野良クラウドやk8sオブジェクトリソースの棚卸問題は、我々も強い課題意識を持っていた  実装容易性の観点 • JSONなど複数アウトプットフォーマットに対応している事による組み込み易さを期待 • k8sクラスタ外部からのPopeye-cli実行以外に、既にk8sクラスタ内でのJob実行サンプルあり  将来性の観点 • Githubを見る限りアクティブに開発されていると判断 Ref) https://github.com/derailed/popeye Github ・star数：2.5k ・contributor数：34人 ・latest release：2020年11月 21

マスター タイトルの書式設定 StarboardへのPopeye実装概要(4ステップで進めた) ① Starboardソースコードリーディング。内部構造のシーケンス図を作成しながら解読 ② Starboard-cli実行引数に、Popeyeを呼び出す定義を追加 ③ Popeye用k8s APIカスタムリソース定義(CRD)の作成・削除処理を追加 ④ Popeyeチェック要求、チェックレポートの加工、カスタムレポート生成の処理を追加 KubeBench KubeHunter Trivy Polaris Popeye ② ③ Init & Cleanup for CRD Starboard-cli Some Code & Tool KubeBench KubeHunter Trivy Polaris Popeye CustomResouce定義 Popeye関連 他ツール関連(Polarisなど) ④ Scanner Model Writer Check target namespace node ,etc Popeyeコンテナ Pullコンテナ チェック処理 CustomResoucrReport ① 4つのステップで実装を進めた CRD作成 チェック要求 チェック結果 レポート加工 レポート生成 具体的なコーディング内容は、話が長く なるので別の機会に話したいと思います 22

マスター タイトルの書式設定 組み込む上で、直面した課題や解決話を一部紹介  その一 • Popeye本体の仕様として実行結果に何かしらのissueレポートが含まれるとリターンコードがゼロ以外になる。Starboardの既 存チェックツール(kubehunterなど)と同様にPopeye実行をコーディングするとPopeye JobがFailedしてしまう。 ⇒ Starboard内の既存チェックツールの実行コーディングとは異なる事を承知の上で、実行リターンコードがゼロ以外でも 後続処理出来る様なコーディングとした。  その二 • Starboard本体の仕様として各チェックツール(kubehunterなど)実行権限はStarboard内で定義された共通のk8s RBACを利用し ている。これにPopeyeに必要な権限を追加してもPopeyeが実行エラーになる。 ⇒ 原因特定出来ず、代替策としてStarboard管理外でPopeye用のRBAC/SAを作成した。  その三 • Popeyeの実行結果アウトプットレポートのJSON構造が複雑だった。これは我々の主観。 ⇒ Starboard内でPopeye実行レポートを加工するコーディングを頑張った。  その四 • StarboardにPopeyeを組み込んでいる間に、Starboard本体の機能アップデートが入った。Starboardから各チェックツールの実 行引数の仕様が変わり従来型の実行引数はDeprecatedとなった。 実行例：旧) $starboard find vulnerabilities deployment/nginx 新) $starboard scan vulnerabilityreports deployment/nginx ⇒ 組み込み開発中だったPopeyeを新仕様にあわせた。 StarboardやPopeye本体の仕様変更や機能アップデートに継続的に対応する覚悟が必要である事を再認識した。 23

マスター タイトルの書式設定 組み込む上で、直面した課題や解決話を一部紹介  その五 • 我々自身がk8s Custom Resource Definition関連の知識が乏しい。 • StarboardはGolangで書かれているのだが、我々自身がGolangの知識が乏しい。 • Starboard GithubのCONTRIBUTING.mdは役に立ったが情報量が少ない。これは我々の主観。 ⇒ Starboardの既存チェックツールのソースコードを頑張って読んで理解した。  その六 • 新たに組み込んだPopeyeソースコードのUnitTestはどうする？ ⇒ Starboardの既存ツール(kubehunberなど)で用意されているTestコード個所やフレームワーク(testing/testifyな ど)を参考に、我々のカスタマイズ要素が多いコード部分(チェックレポートの加工処理)に対して用意した。  その七 • Starboardがサポートしている各プラグインなどの対応(OLM,Krew,Octant,Lens,HTML Reportなど)はどうする？ ⇒ 追加したPopeyeについて今後どこまで対応するか検討中。個人的には継続的に追随していきたい。  その八 • 我々が想定する適用環境の一つであるRedHat OpenShift Platform(OCP)で、そもそもStarboard本体(v0.9.2 :2021年2月18日時 点の最新版)が動作しない ⇒ 我々が動作確認した範囲で、OCP v4.6の標準Security Context Constraints(SCC)のセキュリティガードレール仕様に Starboardが準拠していない。Starboard側の改修 or SCC側の設定変更のいずれかで検討中。 24

マスター タイトルの書式設定 Aqua Security社のEnterprise版(有償製品)とOSS群(Starboardなど)の違い 25 Aqua Enterprise(有償製品)で提供されている機能 Aqua OSS群(○は同じ程度対応, △は一部対応) Image Scan イメージ内に内在する既知の脆弱性ややるウエアなどのリスクをスキャン ○ Trivyで静的なコンテナイメージチェック Image Assurance イメージのセキュリティポリシーを設定、未承認のイメージを検知/ブロック Runtime Protection 「Drift Prevention」で実行中のContainerをリアルタイムで保護(変更禁止) Aqua DTA 静的イメージスキャンだけで無く動的な脅威分析(Dynamic Threat Analysis) K8s Assurance k8sワークロードのセキュリティポリシーを設定、違反を検知 ○ Polarisでk8s manifestベストプラクティスチェック Aqua vShield 検知された脆弱性の仮想的なパッチ Dashboard 各利用者向けWebブラウザ ユーザインターフェース △ Starboardの可視化ツール(Lens、Octant)に対応 Risk Explorer k8sワークロードのセキュリティ状態、通信状況を可視化 Risk Based Insights 脆弱性の深刻度に応じて表示 △ JSONやTable形式でSeverity毎に表示 Multi Application RBAC 複雑な開発・運用環境のアクセス権限(RBAC)を統合的に管理 Multi Platform AWSやAzure、OpenShiftなどのマルチプラットフォームに対応 △ Containerやk8s互換の環境であれば動作可 External Cooperation 各CICDツール(Jenkins、GitLabなど)、各レジストリ(GCR、ECRなど)、各ログ管理サービス (Stackdriver、CloudWatchなど)、各シークレット管理(AWS KMS、HashiCorp Vault)、Apolicyと連携 △ CICDツールへ各チェックツールの組み込み可 レジストリやログ管理サービスへの連携可 Other feature 各セキュリティフレームワーク準拠(NIST SP800-190、PCI-DSS、HIPPAなど)、CIS Benckmark、 Workloads Firewall、シークレット管理 △ CIS k8s Benckmarkチェック可 未使用k8sオブジェクトリソースチェック(Popeye) Ref) 国内販売代理店から提供頂いた入手資料(AquaEnterprise概要)から提供されている機能内容を記載 • Aqua Security社のEnterprise版(有償製品)とOSS群(Starboard,Trivy,kubehunterなど)の守備範囲を、国内 販売代理店からの入手資料と、Githubで確認出来る範囲で整理 • そもそもOSS群は利用者で連携ツールへの組み込みや、CLIやIDEを使いこなすノウハウやテクニックが必要

マスター タイトルの書式設定 現時点でのオージス総研の運用自動化ソリューション「Cloud Arch」におけるStarboardの利用 26 ① k8sクラスタへstarboard-cliを実行しチェックレポートが生成出来ている状態が前提 ② Grafanaからk8sクラスタへのアクセス認証は、GrafanaサーバOS上でkubectl proxy機能を利用 ※Grafanaから直接k8sアクセス認証を設定出来る様な機能アップデートを検討中 ③ 開発したGrafanaプラグインでStarboardのチェックレポートをサマライズ表示 ④ Popeyeチェックレポートのサマライズ表示もGrafanaプラグインで追加開発中 trivyチェック結果 CustomResouceReport polarisチェック結果 kubebenchチェック結果 kubehunterチェック結果 k8s API (get/listなど) 顧客 開発/運用者 Starboard-cli 顧客専用の可視化サーバ 作業端末/サーバ チェック レポート生成 k8s API(create/updateなど) Popeye popeyeチェック結果 前のスライドで説明したstarboardにpopeyeを追加開発した オージス総研の運用自動化ソリューション 「Cloud Arch」のイチ提供機能 GET /localhost:8001/apis/apps/v1/＊＊ K8s auth config file $kubectl proxy ① ② ③ ④ Ref) https://www.ogis-ri.co.jp/feature/hybridcloud/

マスター タイトルの書式設定 我々が考える解決アプローチ② (現在進行形) 27

マスター タイトルの書式設定 k8sセキュリティチェック統合管理サービス(ToBe) セキュリティチェック レポートアップロード k8sクラスタ環境 ・・ ユーザ(閲覧者/編集者など)管理、レポートのエクスポート、通知設定(SNS、メ ール)、API連携、ダッシュボードカスタマイズ、k8sクラスタ閲覧/操作など 認証/認可、ID/IAM管理、証跡管理、MFA、SSO/フェデ レーション連携，APIキー管理など オンライン契約/課金/請求/支払い/契約プラン管理 (ユーザ/使用料ベース、定額/超過料金、支払い決済など) ID管理 契約管理 管理コンソール 各顧客向けWebユーザインターフェース ダッシュボード レポート表示(サマライズ、フィルタ、ソート、詳細、除外/解決フラグ、クエ リなど)、ガバナンス/コンプライアンス準拠設定(PCI-DSS、HIPPA、CISなど) ・・ 初期設定 Webアクセス(閲覧・操作) 顧客A 顧客B 顧客C K8sクラスタ 閲覧・操作 • 各顧客向けダッシュボード、管理コンソール、ID管理、契約管理などのWebユーザインターフ ェースの提供 • 各顧客の各k8sクラスタやチェックレポートを閲覧/操作するマルチテナント型のSaaS 28

マスター タイトルの書式設定 ライフサイクル全体のセキュリティチェック結果を可視化(ToBe) Container registry k8s Manifest Dev Ops/SRE IaC Config Check Base Image Check Artifact Check CIS Benchmark Penetration test Check Config チェックレポート データ Biz/QA/Dev/Ops/SREなど 可視化、傾向分析など • コンテナ、k8sのCICDライフサイクル全体のセキュリティチェック結果を統合的に可視化 • 各チェックレポートを分析し潜在的なセキュリティリスクをレポート、是正リコメンド • 世の中にあるCSPM、CWPPのイメージに近い Docker file etc ・SW Library ・etc Base Image Check Config Check App/Library App Code ・Observability tool ・mTLS、encrypt tool ・etc develop Build Deploy etc Prod Stage observability Ops/SRE Buildフェーズ Shipフェーズ Runフェーズ Insightフェーズ コンテナタグや環 境変数の更新など k8s Manifest IaC Config まずはk8sクラスタのRunフェーズのチ ェックレポートから取り組み中 各顧客向けWebユーザインターフェース 29

マスター タイトルの書式設定 現時点でのアーキテクチャ概要の紹介(MVP) in vpc APIGateway S3 Lambda (プロキシ統合) Athena QuickSight Lambda(オーソライザ) RDS 各顧客(Biz/QA/Dev/Ops/SREなど) ① 顧客、またはオージス総研がk8sクラスタへStarboard実行環境をセットアップ ② Starboardで定期セキュリティチェックしカスタムレポート結果を生成 ③ カスタムレポート結果をk8s CronJobでAWSクラウドへ定期連携(HTTPS POST) ④ APIGW+LambdaオーソライザでHTTPヘッダー認証。Lambdaプロキシ統合経由でS3へレポート保存 ⑤ レポート結果を各顧客向けにUI提供 各顧客のk8sクラスタ環境 各顧客向けにUI提供するオージスクラウド環境 HTTPS POST (定期実行) Pull Container Image Popeye Check target namespace master/worker ・・ ,etc 顧客 deploy 定期実行 アセットを提供 オージスが操作 するケース 顧客で操作 するケース ① ② ③ ④ ⑤ 30

マスター タイトルの書式設定 実装する上での課題や解決話を一部紹介  その一 • セキュリティチェックレポートをk8sクラスタからクラウドへHTTP POSTする際の認証ヘッダーキーをどうい うロジックで生成するか？ ⇒ 中身は話せませんが、HTTP POST専用のAPI認証の為、セキュリティレベルとのトレードオフで 認証キーの生成ロジックを考慮した。  その二 • Starboardのチェック実行とチェックレポートのHTTP POSTタイミングをどうするか？ ⇒ イベントドリブンだと処理が少し複雑になると判断し、MVPではスケジュール実行とした。  その三 • 暫定とはいえ、S3の複数チェックレポートを可視化する際に、AWSで完結出来る事を意図しAthenaと QuickSightを利用したのだが、あまり触った事が無く知識に乏しい。 ⇒ 公式ドキュメント見たり、実際に手を動かして触る。 31

マスター タイトルの書式設定 まとめ 32

マスター タイトルの書式設定 まとめ • Container/k8sの潮流により考慮すべきセキュリティ対策項目が増加 & 複雑化 • 世の中に公開されているセキュリティ対策指針などを参考にしながら継続的に キャッチアップ • 自分達のフェーズにFitするセキュリティ対策方針の策定と、チェックツールや ソリューションの採用を検討 • OSSも一つの選択肢だが向き合う覚悟と許容が必要。但し、そこから得られる知 見も多大 33

マスター タイトルの書式設定 ご清聴ありがとうございました 34