Container Kubernetesのセキュリティ対策を改めて考える

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

View Slide

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

View Slide

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

View Slide

Container/kubernetesのセキュリティ
対策を考える上での課題感
3

View Slide

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

View Slide

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

View Slide

課題② 考慮すべきセキュリティ対策項目が増加し複雑化
• 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

View Slide

課題③ 包括的なセキュリティ対策有償製品は導入コストの敷居が高い
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

View Slide

Container/k8sのセキュリティ対策
のおさらい
8

View Slide

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

View Slide

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
10

View Slide

セキュリティカテゴリ毎に対策ツールをマッピング
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
11

View Slide

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

View Slide

「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

View Slide

我々の取り組みを紹介
(現在進行形)
14

View Slide

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

View Slide

我々が考える解決アプローチ①
(現在進行形)
16

View Slide

我々が注目した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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

組み込む上で、直面した課題や解決話を一部紹介
 その一
• 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

View Slide

組み込む上で、直面した課題や解決話を一部紹介
 その五
• 我々自身が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

View Slide

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を使いこなすノウハウやテクニックが必要

View Slide

現時点でのオージス総研の運用自動化ソリューション「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/

View Slide

我々が考える解決アプローチ②
(現在進行形)
27

View Slide

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

View Slide

ライフサイクル全体のセキュリティチェック結果を可視化(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

View Slide

現時点でのアーキテクチャ概要の紹介(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

View Slide

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

View Slide

まとめ
32

View Slide

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

View Slide

ご清聴ありがとうございました
34

View Slide

Container Kubernetesのセキュリティ対策を改めて考える

Container Kubernetesのセキュリティ対策を改めて考える

hiropinponpan

More Decks by hiropinponpan

Other Decks in Technology

Featured

Transcript