Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

hiropinponpan

March 06, 2021
Tweet

More Decks by hiropinponpan

Other Decks in Technology

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  7. マスター タイトルの書式設定
    課題② 考慮すべきセキュリティ対策項目が増加し複雑化
    • 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

  8. マスター タイトルの書式設定
    課題③ 包括的なセキュリティ対策有償製品は導入コストの敷居が高い
    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

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

    View Slide

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

    View Slide

  11. マスター タイトルの書式設定
    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

    View Slide

  12. マスター タイトルの書式設定
    セキュリティカテゴリ毎に対策ツールをマッピング
    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

    View Slide

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

    View Slide

  14. マスター タイトルの書式設定
    「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

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

    View Slide

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

    View Slide

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

    View Slide

  18. マスター タイトルの書式設定
    我々が注目した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

  19. マスター タイトルの書式設定
    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

  20. マスター タイトルの書式設定
    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

  21. マスター タイトルの書式設定
    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

  22. マスター タイトルの書式設定
    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

  23. マスター タイトルの書式設定
    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

  24. マスター タイトルの書式設定
    組み込む上で、直面した課題や解決話を一部紹介
     その一
    • 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

  25. マスター タイトルの書式設定
    組み込む上で、直面した課題や解決話を一部紹介
     その五
    • 我々自身が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

  26. マスター タイトルの書式設定
    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

  27. マスター タイトルの書式設定
    現時点でのオージス総研の運用自動化ソリューション「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

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

    View Slide

  29. マスター タイトルの書式設定
    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

  30. マスター タイトルの書式設定
    ライフサイクル全体のセキュリティチェック結果を可視化(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

  31. マスター タイトルの書式設定
    現時点でのアーキテクチャ概要の紹介(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

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide