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

How to secure container environment

How to secure container environment

コンテナ環境をセキュアに運用する方法
OSC2021 Online/Spring

アプリケーションコンテナであるDockerや、そのオーケストレーションツールであるKubernetesが使われ始める昨今。今やその価値はデファクトスタンダードとも言える。だが待ってほしい。君たちは、DockerやKubernetesが安全なものだと考えているのではないか?しかしそうではない。なぜならば日々脆弱性は発見され、新たな攻撃手法が発見し続けるからである。そのため、我らは知らなければならない。アプリケーションコンテナとそのライフサイクルのセキュリティをどう保っていけば良いかを。

Satoru MIYAZAKI

March 06, 2021
Tweet

More Decks by Satoru MIYAZAKI

Other Decks in Technology

Transcript

  1. myzkstr.com みやざきさとる 宮﨑悟 [email protected] @s_miyaza satoru.miyazaki.31  Solaris/ZFS/Solaris Zoneがすき 

    フリーランスのエンジニア  北海道函館市からリモートワーク  主な仕事  某WordPress仮想マシン  コンテナセキュリティ製品評価  技術コラム掲載
  2. アジェンダ 話すこと:  コンテナセキュリティとは  コンテナをセキュアに運用するためには  コンテナセキュリティの怖い話 話さないこと: 

    コンテナ/Kubernetesの詳細 ※SpeakerDeckで資料公開中 https://speakerdeck.com/smiyaza/how-to-secure- container-environment-osc21on 2021-03-06 OSC2021 Online/Spring #osc21on 3
  3. コンテナはセキュア?  コンテナ内のアプリケーションを非特権ユーザで動作させる  コンテナホスト上で非特権ユーザでプロセスが動作  コンテナ内で1アプリケーションのみ動作させる  コンテナ内で余計なプロセスを動作させない 

    複数のコンテナやコンテナホスト間をつなぐネットワークは、 分離もしくは暗号化可能  コンテナ外部からの通信は、必要なポートのみ接続される 2021-03-06 OSC2021 Online/Spring #osc21on 6
  4. コンテナは(デフォルトでは) セキュアと言えない  コンテナ内のアプリケーションを特権ユーザでも動作可能  コンテナホスト上で特権ユーザでプロセスが動作  コンテナ内でsystemdを起動可能  複数プロセス起動可能

     ホストの特権機能もprivilegedオプションで使用可能  複数のコンテナやコンテナホスト間をつなぐネットワークは、 デフォルトではフラットなネットワークで暗号化されない  コンテナ外部への通信は、制限されない 2021-03-06 OSC2021 Online/Spring #osc21on 7
  5. コンテナ環境で 必須なセキュリティポリシー  攻撃者からホストへのアクセス防止  意図しないコンテナ起動防止  ホスト/コンテナの不要な通信防止  コンテナで使用するリソース制限

     ホスト/コンテナの脆弱性の排除  CIS benchmarkなど 業界標準セキュリティベンチマークの適用 2021-03-06 OSC2021 Online/Spring #osc21on 11
  6. サービスで扱うデータで変わるもの  会員情報  匿名情報  個人情報を除いた、アクセス情報、購買情報など  個人情報/ペイメントカード情報 

    業界セキュリティ基準(GDPR/PCI-DSS/HIPPAなど)への準拠  データ保管時の暗号化  暗号鍵の外部管理  通信の暗号化(外部/コンテナ間) 2021-03-06 OSC2021 Online/Spring #osc21on 12
  7. コンテナホストを堅牢化するために  自分でKubernetes環境を作成する場合  ホストをクローズドな環境に配置  KubernetesやDocker APIのアクセス元を制限  Kubernetesのアカウント・ロールを設定

     Kubernetesへアクセスする際のアカウント管理  Managed Kubernetesの使用  Kubernetes、ホスト設定の確認 2021-03-06 OSC2021 Online/Spring #osc21on 14
  8. ホストをクローズドな環境に配置  コンテナホストの構築は、Ansible/Terraform などで構築  Kubernetes コントローラの導入  ワーカーノードの追加 

    監視/ログ収集ツール/セキュリティソフトの導入  コンテナを動かすため最低限のソフトウェアで構成  Core OSなどのベースOS 2021-03-06 OSC2021 Online/Spring #osc21on 16
  9.  個人単位でアカウントを発行  もう令和なんだから、共用アカウントとか使用しない  ロールを定義  ネームスペース  サービス

     アクセス権限  Kubernetesアカウントへのロール割当 2021-03-06 OSC2021 Online/Spring #osc21on 18 Kubernetesの アカウント・ロールを設定
  10. Kubernetes、ホスト設定の確認  CSPM(Cloud Security Posture Management)を使用する  クラウド上のセキュリティ状態を検査する  Kubernetesとホストの設定を検査し、設定ミスを検知

     クラウドプロバイダ設定ミスも検知(IAM、公開範囲など)  CIS benchmarkの実行  Kubernetes環境の設定変更を検知 2021-03-06 OSC2021 Online/Spring #osc21on 20
  11. コンテナイメージ内の脆弱性  ライブラリやソフトウェアの脆弱性は日々発見され続ける  開発段階でコンテナイメージの脆弱性を確認  デプロイしたコンテナイメージの脆弱性を確認  コンテナイメージは脆弱性が見つかるたびに更新/対処する 

    コンテナ内で動作させるアプリケーションの脆弱性の対処  コンテナイメージの脆弱性を視覚化  脆弱性をレベル分けし、危険度が高いものだけを表示 2021-03-06 OSC2021 Online/Spring #osc21on 22
  12. 特権ユーザでの コンテナアプリケーション実行(1) 2021-03-06 OSC2021 Online/Spring #osc21on 27  コンテナ内でアプリケーションのrootユーザ権限 実行→コンテナ外でもroot権限で実行される

     Docker rootless(非特権ユーザでのコンテナ実行) で回避可能  Podmanは、デフォルトでコンテナ内のUIDは、 ホストからは別UIDとして扱う  KubernetesのPod Security Policyでrootユーザで の実行を禁止(runAsUser)
  13. 特権ユーザでの コンテナアプリケーション実行(2) 2021-03-06 OSC2021 Online/Spring #osc21on 28  --privileged オプション付きでコンテナ起動

    →コンテナホストの特権操作がコンテナで可能  KubernetesのPod Security Policy により privilegedオプションをつけたコンテナ起動を禁止 (privileged/allowedCapabilities/defaultAddCapabilities)
  14. ローカルボリュームをマウントして コンテナ起動 2021-03-06 OSC2021 Online/Spring #osc21on 29  /var や

    /etc などのディレクトリを読書き可能で マウントしてコンテナ起動 →/var以下のdockerソケットにアクセスすること で、コンテナから別のコンテナを起動可能  KubernetesのPod Security Policy によりマウント 可能なディレクトリ(allowedHostPaths)を指定  KubernetesのPod Security Policy によりマウント できるVolume Plugin(volumes)を指定可能
  15. 不要なコンテナ外への通信 2021-03-06 OSC2021 Online/Spring #osc21on 30  外部からPodへの通信は制御するが、 Podから外部への通信は制限されない →不要なファイルをダウンロードされる可能性

    →内部の不正なPod/コンテナから通信される可能性  KubernetesのServiceリソースにより、 Service配下のPodの通信先を制御  Firewall による制御
  16. Kubernetesで設定できる Pod Security Policy 制御事項 ポリシー名 特権(privileged)コンテナの実行 privileged ホスト名空間の使用 hostPID,

    hostIPC 使用可能なホストネットワークとポート hostNetwork, hostPorts Podで使用可能なFSGroupの割当て fsGroup 使用可能なボリュームタイプ volumes 使用可能なホストファイルシステム allowedHostPaths Read Only rootファイルシステムの使用 readOnlyRootFilesystem コンテナのユーザID/グループID runAsUser, runAsGroup, supplementalGroups ルート権限への昇格を制限する allowPrivilegeEscalation, defaultAllowPrivilegeEscalation 2021-03-06 OSC2021 Online/Spring #osc21on 31
  17. Kubernetes PSP(Pod Security Poricy)から PSS(Pod Security Standard)への変更  Kubernetes 1.21以降で、PSP(Pod

    Security Policy)は非推奨 (1.25で削除)  PSS(Pod Security Standard)が推奨 以下の3種類がある。  特権(Privileged)  ベースライン(Baseline)  制限(Restricted) 参照:https://kubernetes.io/ja/docs/concepts/security/pod-security-standards/ 2021-03-06 OSC2021 Online/Spring #osc20on 32
  18. Pod Security Standardの特権(参考)  特権ポリシーは意図的に開放されており、 完全に制限がかけられていない  通常、特権ユーザーまたは信頼されたユーザーが管理する、 システムまたはインフラレベルのワークロードに対して適用 

    特権ポリシーは制限がないことと定義される。  デフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定しない →何も制限を適用しない(allow all → 個別にdeny)  デフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化 →その他でコントロールできるようにする必要がある(deny all → 個別にallow) 2021-03-06 OSC2021 Online/Spring #osc20on 33
  19. Pod Security Standardのベースライン (参考) PSS コントロール PSP コントロールの相当する機能 ホストのネームスペース ホストのネームスペースの使用

    ホストネットワークとポートの使用 特権コンテナ 特権コンテナの使用 ケーパビリティー Linuxのケーパビリティ HostPathボリューム ホストのファイルシステムの使用 ホストのポート PSP サポート対象外 AppArmor (オプション) コンテナの AppArmor プロファイルの使用 SELinux (オプション) コンテナの SELinuxのコンテキスト /procマウントタイプ コンテナの Proc マウントタイプ許可 Sysctls コンテナの sysctl の使用 2021-03-06 OSC2021 Online/Spring #osc20on 34
  20. Pod Security Standardの制限(参考) PSSの機能 PSPの相当機能 Volume Types Volumeタイプの使用 特定のボリュームドライバーの許可 read-only

    の root ファイルシステムの使用の必要性 Privilege Escalation 特権昇格の禁止 Running as Non-root PSP サポート対象外 Non-root groups Pod のボリュームを所有する FS グループを割り当てる コンテナの UID 及び GID Seccomp コンテナの seccomp プロファイルの使用 2021-03-06 OSC2021 Online/Spring #osc20on 35
  21. Kubernetesで制御不可能な 意図しないコマンド実行 2021-03-06 OSC2021 Online/Spring #osc21on 36  使用できるコマンドの制限 

    使用するsystem callの制限  イメージに含まれていないファイル/イメージと 異なるファイルを実行しない  設定ファイルを変更してプロセス再起動
  22. セキュリティソフトウェアによる ランタイム監視 2021-03-06 OSC2021 Online/Spring #osc21on 37  ランタイム監視=実行中のコンテナの監視 

    ランタイム監視に求められること  実行中コンテナの脆弱性検知  ファイルインジェクションの検知  起動時から変更されたファイルの実行阻止  コンテナ内で実行可能・不可能なコマンド/system callの設定  コンテナ間・コンテナ外への不正な通信の禁止(Firewall)
  23. 機密データ保管時の暗号化  暗号化機能付きのDBに保管  DB機能で、暗号化/復号を行う  DBへの通信経路を暗号化する必要あり  暗号化してPVに保管 

    コントローラ/ネームスペース/ホスト/PVでデータを分離  データを公開鍵暗号方式で暗号化して保管  暗号化するサービスと復号するサービスで鍵を分離 2021-03-06 OSC2021 Online/Spring #osc21on 40
  24. 暗号鍵の扱い  暗号鍵はKubernetesのSecurityリソースで管理  Secret自体はただのbase64エンコードされた文字列  YAMLファイルで管理するのはセキュアではない  KMS(鍵管理システム=Key Management

    System)の併用  Hashicorp Vault/クラウドプロバイダのKMS/pgpなどで暗号化  鍵をSecretに配置するリソース/ソフトウェアとの併用  ExternalSecretリソース/kubesec/SealedSecretリソースなど 2021-03-06 OSC2021 Online/Spring #osc21on 41
  25. gRPC(https://grpc.io/)  Google社が開発したRPC(Remote Procedure Call) 実装  Web経由のAPIなどで使用  経路としてhttp/2を使用

    →TLS暗号化済み  セッション開始時に認証も可能  TLS用の証明書管理が必要 2021-03-06 OSC2021 Online/Spring #osc21on 44
  26. セキュリティはプロセス  コンテナホスト自体の脆弱性チェック  定期的なイメージ再作成  イメージ検査  テスト(アプリケーション、ペネトレーション、負荷など) 

    デプロイ  未知のマルウェア、インジェクションなどへの対応  コンテナの寿命を短くする  ランタイム監視の実施  障害発生時のエスカレーション 2021-03-06 OSC2021 Online/Spring #osc21on 47
  27. DevSecOpsの実践  一貫した開発・セキュリティ・運用が必要  シフトレフト  バグを運用でカバーすると高コスト  バグを開発で出し切る 

    運用、セキュリティコストの削減  DevSecOpsの自動化  CI/CDの考え方の導入+セキュアな考え方 2021-03-06 OSC2021 Online/Spring #osc21on 48
  28. Security  セキュリティ基準の策定  CIS/NIST  GDPR/PCI-DSS/HIPS  DevとOpsに対するセキュリティ対策支援 

    開発のセキュリティ基準  コンテナセキュリティの方針決定  開発環境→デプロイ→本番環境のすべてをセキュアにする 2021-03-06 OSC2021 Online/Spring #osc21on 50
  29. コンテナイメージの脆弱性スキャン  スキャンにより脆弱性が見つかった場合  ベースイメージ、パッケージ、使用ライブラリの更新  イメージの再作成→脆弱性検査  新コンテナイメージのデプロイ 

    ローリングアップデート  カナリアデプロイ  ブルー/グリーンデプロイ  脆弱性は日々発見される 定期的に脆弱性スキャン実施する必要がある 2021-03-06 OSC2021 Online/Spring #osc21on 52
  30. アプリケーションの脆弱性  アプリケーションの脆弱性  SQLインジェクション  CSR/CSRF  ファイルのインジェクション 

    コマンド実行  アプリケーション脆弱性の対応  アプリケーションで使用するライブラリは、最新のものを選択  脆弱性を意識したアプリケーション開発  ペネトレーションテストの実施 2021-03-06 OSC2021 Online/Spring #osc21on 53
  31. CI/CDツールと 静的イメージスキャンの組み合わせ  CI/CDツール  Gitlab  GitHub Actions 

    Jenkins  Circle CI  Travis CI  アプリケーションのテスト/脆弱性スキャン  イメージ作成後に静的イメージスキャン 2021-03-06 OSC2021 Online/Spring #osc21on 54
  32. ルーチンワークは自動化する  CI/CDツールで出来ることは自動化する  アプリケーションテスト  アプリケーション静的解析  イメージの静的スキャン 

    コンテナ群へのペネトレーションテスト  デプロイ  リリース中のコンテナイメージに対する脆弱性スキャン  Wazuhなど、脆弱性検査及び監視を行うツールもある 2021-03-06 OSC2021 Online/Spring #osc21on 55
  33. 人間の脆弱性も考える  セキュリティは一番弱いところ(=人間)から狙われる  ソーシャルハック最強  アカウント管理を厳格にする?  厳格にしすぎると、逆に回避策を考えるのが人間 

    パスワードマネージャなどのツールに任せる  もしくはパスワードを使用しない  ゼロトラストの採用も考慮する 2021-03-06 OSC2021 Online/Spring #osc21on 57
  34. Docker APIが外部に公開されてた例(1)  コンテナ環境を対象としたマルウェアKinsing(日本語化記事)  間違って設定されたオープン状態のDocker APIポートを攻撃対象  セキュリティ対策の無効化とログのクリア 

    多数のアプリケーション(クリプトマイナーを含む)を停止/削除  競合する悪意のあるコンテナを強制終了/イメージを削除  Kinsingマルウェアのダウンロードと実行  Kinsing自体の拡散 2021-03-06 OSC2021 Online/Spring #osc21on 59
  35. Docker APIが外部に公開されてた例(2)  攻撃者が悪意あるイメージをホスト上に直接ビルド (日本語化記事)  公開されているDocker APIを使用  コンテナイメージを攻撃対象のホストでビルド

     作成されたイメージはどこのレジストリにも保存されない →確認/対応しにくい  イメージの名前/IDをランダムに生成  クリプトマイニングを実行 2021-03-06 OSC2021 Online/Spring #osc21on 60
  36. セキュリティよくわからない  自分で学ぶ  ThinkITで連載してます(ダイマ) https://thinkit.co.jp/series/9523  金で解決する  セキュリティに強い人材を確保・育成する

     セキュリティコンサルタントを雇う  商用のコンテナセキュリティツールを使う 2021-03-06 OSC2021 Online/Spring #osc21on 63
  37. 商用コンテナセキュリティ製品  Aqua Security  イメージスキャン、ランタイムスキャン、監視、L3FW  日本販社あり  Prisma

    Cloud  イメージスキャン、ランタイムスキャン、監視、L7FW  日本販社あり  sysdig  イメージスキャン、ランタイムスキャン、監視  日本販社あり 2020-10-24 OSC2021 Online/Spring #osc21on 64