How to secure container environment

myzkstr.com
みやざきさとる
コンテナ環境をセキュアに
運用する方法

View Slide

myzkstr.com
みやざきさとる
宮﨑悟
[email protected]
@s_miyaza
satoru.miyazaki.31
 Solaris/ZFS/Solaris Zoneがすき
 フリーランスのエンジニア
 北海道函館市からリモートワーク
 主な仕事
 某WordPress仮想マシン
 コンテナセキュリティ製品評価
 技術コラム掲載

View Slide

アジェンダ
話すこと:
 コンテナセキュリティとは
 コンテナをセキュアに運用するためには
 コンテナセキュリティの怖い話
話さないこと:
 コンテナ/Kubernetesの詳細
※SpeakerDeckで資料公開中
https://speakerdeck.com/smiyaza/how-to-secure-
container-environment-osc21on
2021-03-06
OSC2021 Online/Spring #osc21on 3

View Slide

本資料でのコンテナの定義
 コンテナ=アプリケーションコンテナとする
 アプリケーションコンテナ＝Docker(もしくはDocker
互換のコンテナ)を想定
 コンテナのオーケストレーションサービスとして
Kubernetesを想定
 ホスト=コンテナが動作するマシンのこと
KubernetesのNodeに相当
2021-03-06

View Slide

View Slide

コンテナはセキュア?
 コンテナ内のアプリケーションを非特権ユーザで動作させる
 コンテナホスト上で非特権ユーザでプロセスが動作
 コンテナ内で1アプリケーションのみ動作させる
 コンテナ内で余計なプロセスを動作させない
 複数のコンテナやコンテナホスト間をつなぐネットワークは、
分離もしくは暗号化可能
 コンテナ外部からの通信は、必要なポートのみ接続される
2021-03-06

View Slide

コンテナは(デフォルトでは)
セキュアと言えない
 コンテナ内のアプリケーションを特権ユーザでも動作可能
 コンテナホスト上で特権ユーザでプロセスが動作
 コンテナ内でsystemdを起動可能
 複数プロセス起動可能
 ホストの特権機能もprivilegedオプションで使用可能
 複数のコンテナやコンテナホスト間をつなぐネットワークは、
デフォルトではフラットなネットワークで暗号化されない
 コンテナ外部への通信は、制限されない
2021-03-06

View Slide

View Slide

コンテナをセキュアにするには
 コンテナのセキュリティポリシー
 ホストの堅牢化
 コンテナイメージの検査
 起動したコンテナの動作を監視・制御
 機密データの扱い
 DevSecOpsサイクルの維持
2021-03-06

View Slide

View Slide

コンテナ環境で
必須なセキュリティポリシー
 攻撃者からホストへのアクセス防止
 意図しないコンテナ起動防止
 ホスト/コンテナの不要な通信防止
 コンテナで使用するリソース制限
 ホスト/コンテナの脆弱性の排除
 CIS benchmarkなど
業界標準セキュリティベンチマークの適用
2021-03-06

View Slide

サービスで扱うデータで変わるもの
 会員情報
 匿名情報
 個人情報を除いた、アクセス情報、購買情報など
 個人情報/ペイメントカード情報
 業界セキュリティ基準(GDPR/PCI-DSS/HIPPAなど)への準拠
 データ保管時の暗号化
 暗号鍵の外部管理
 通信の暗号化(外部/コンテナ間)
2021-03-06

View Slide

View Slide

コンテナホストを堅牢化するために
 自分でKubernetes環境を作成する場合
 ホストをクローズドな環境に配置
 KubernetesやDocker APIのアクセス元を制限
 Kubernetesのアカウント・ロールを設定
 Kubernetesへアクセスする際のアカウント管理
 Managed Kubernetesの使用
 Kubernetes、ホスト設定の確認
2021-03-06

View Slide

ホストをクローズドな環境に配置
 コンテナホストをクローズドネットワークに接続
 ベアメタル、仮想化環境
 クラウドサービス(IaaS/CaaS/KaaS)
 SSHなどでアクセスせず、APIのみでアクセス
2021-03-06

View Slide

ホストをクローズドな環境に配置
 コンテナホストの構築は、Ansible/Terraform などで構築
 Kubernetes コントローラの導入
 ワーカーノードの追加
 監視/ログ収集ツール/セキュリティソフトの導入
 コンテナを動かすため最低限のソフトウェアで構成
 Core OSなどのベースOS
2021-03-06

View Slide

Kubernetes/Docker APIの
アクセス元を制限
 APIのアクセス元を制限し、公開状態にしない
 IPアドレス指定
 クラウドプロバイダによる認証
 IdP(Identity Provider)/IDaaSによる認証
2021-03-06

View Slide

 個人単位でアカウントを発行
 もう令和なんだから、共用アカウントとか使用しない
 ロールを定義
 ネームスペース
 サービス
 アクセス権限
 Kubernetesアカウントへのロール割当
2021-03-06
Kubernetesの
アカウント・ロールを設定

View Slide

Kubernetesへアクセスする際の
アカウント管理
 Kubernetesアカウントと外部アカウントの紐付け
 クラウドプロバイダ
 IdP(Azure AD/G Suiteなど)、IDaaS
 もう令和なんだから、共用アカウントなんか使用しない
2021-03-06

View Slide

Kubernetes、ホスト設定の確認
 CSPM(Cloud Security Posture Management)を使用する
 クラウド上のセキュリティ状態を検査する
 Kubernetesとホストの設定を検査し、設定ミスを検知
 クラウドプロバイダ設定ミスも検知(IAM、公開範囲など)
 CIS benchmarkの実行
 Kubernetes環境の設定変更を検知
2021-03-06

View Slide

View Slide

コンテナイメージ内の脆弱性
 ライブラリやソフトウェアの脆弱性は日々発見され続ける
 開発段階でコンテナイメージの脆弱性を確認
 デプロイしたコンテナイメージの脆弱性を確認
 コンテナイメージは脆弱性が見つかるたびに更新/対処する
 コンテナ内で動作させるアプリケーションの脆弱性の対処
 コンテナイメージの脆弱性を視覚化
 脆弱性をレベル分けし、危険度が高いものだけを表示
2021-03-06

View Slide

コンテナの脆弱性スキャン
 コンテナホストに対する脆弱性スキャン
 コンテナイメージに対する脆弱性スキャン
 コンテナのレイヤ単位でスキャンが可能
 実行中コンテナに対する脆弱性スキャン
 継続的スキャン
2021-03-06

View Slide

静的スキャンツール
 コンテナ内に含まれるライブラリパッケージから、いくつか
の基準で脆弱性を検知
 NVD/CVE/OSベンダーなどの脆弱性情報
 言語ライブラリ(Python/Node.js/Rubyなど)の脆弱性情報
 脆弱性の脅威度によってレベル分け
 既存のマルウェアの検知
 鍵情報などが埋め込まれていないか
2021-03-06

View Slide

継続的スキャン
 コンテナ静的スキャンを、開発中からデプロイ後まで実施
 実行中コンテナのイメージに脆弱性があるか
 CI/CDの一部に含むことで、脆弱性の素早い対処が可能
 シフトレフト
障害対応を開発に寄せること(シフトレフト)で、
開発から運用までの人的コストを下げる
2021-03-06

View Slide

View Slide

特権ユーザでの
コンテナアプリケーション実行(1)
2021-03-06
 コンテナ内でアプリケーションのrootユーザ権限
実行→コンテナ外でもroot権限で実行される
 Docker rootless(非特権ユーザでのコンテナ実行)
で回避可能
 Podmanは、デフォルトでコンテナ内のUIDは、
ホストからは別UIDとして扱う
 KubernetesのPod Security Policyでrootユーザで
の実行を禁止(runAsUser)

View Slide

特権ユーザでの
コンテナアプリケーション実行(2)
2021-03-06
 --privileged オプション付きでコンテナ起動
→コンテナホストの特権操作がコンテナで可能
 KubernetesのPod Security Policy により
privilegedオプションをつけたコンテナ起動を禁止
(privileged/allowedCapabilities/defaultAddCapabilities)

View Slide

ローカルボリュームをマウントして
コンテナ起動
2021-03-06
 /var や /etc などのディレクトリを読書き可能で
マウントしてコンテナ起動
→/var以下のdockerソケットにアクセスすること
で、コンテナから別のコンテナを起動可能
 KubernetesのPod Security Policy によりマウント
可能なディレクトリ(allowedHostPaths)を指定
 KubernetesのPod Security Policy によりマウント
できるVolume Plugin(volumes)を指定可能

View Slide

不要なコンテナ外への通信
2021-03-06
 外部からPodへの通信は制御するが、
Podから外部への通信は制限されない
→不要なファイルをダウンロードされる可能性
→内部の不正なPod/コンテナから通信される可能性
 KubernetesのServiceリソースにより、
Service配下のPodの通信先を制御
 Firewall による制御

View Slide

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

View Slide

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

View Slide

Pod Security Standardの特権(参考)
 特権ポリシーは意図的に開放されており、
完全に制限がかけられていない
 通常、特権ユーザーまたは信頼されたユーザーが管理する、
システムまたはインフラレベルのワークロードに対して適用
 特権ポリシーは制限がないことと定義される。
 デフォルトで許可される仕組みでは、特権プロファイルはポリシーを設定しない
→何も制限を適用しない(allow all → 個別にdeny)
 デフォルトで拒否される仕組みでは、特権ポリシーでは全ての制限を無効化
→その他でコントロールできるようにする必要がある(deny all → 個別にallow)
2021-03-06

View Slide

Pod Security Standardのベースライン
(参考)
PSS コントロール PSP コントロールの相当する機能
ホストのネームスペース
ホストのネームスペースの使用
ホストネットワークとポートの使用
特権コンテナ特権コンテナの使用
ケーパビリティー Linuxのケーパビリティ
HostPathボリュームホストのファイルシステムの使用
ホストのポート PSP サポート対象外
AppArmor (オプション) コンテナの AppArmor プロファイルの使用
SELinux (オプション) コンテナの SELinuxのコンテキスト
/procマウントタイプコンテナの Proc マウントタイプ許可
Sysctls コンテナの sysctl の使用
2021-03-06

View Slide

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

View Slide

Kubernetesで制御不可能な
意図しないコマンド実行
2021-03-06
 使用できるコマンドの制限
 使用するsystem callの制限
 イメージに含まれていないファイル/イメージと
異なるファイルを実行しない
 設定ファイルを変更してプロセス再起動

View Slide

セキュリティソフトウェアによる
ランタイム監視
2021-03-06
 ランタイム監視=実行中のコンテナの監視
 ランタイム監視に求められること
 実行中コンテナの脆弱性検知
 ファイルインジェクションの検知
 起動時から変更されたファイルの実行阻止
 コンテナ内で実行可能・不可能なコマンド/system callの設定
 コンテナ間・コンテナ外への不正な通信の禁止(Firewall)

View Slide

View Slide

機密データの分離
 セキュリティレベルが違うデータを分離
 会員情報/匿名情報
 個人情報/ペイメント情報
 リソースで分離
 Kubernetes コントローラ
 Node
 Namespace
2021-03-06

View Slide

機密データ保管時の暗号化
 暗号化機能付きのDBに保管
 DB機能で、暗号化/復号を行う
 DBへの通信経路を暗号化する必要あり
 暗号化してPVに保管
 コントローラ/ネームスペース/ホスト/PVでデータを分離
 データを公開鍵暗号方式で暗号化して保管
 暗号化するサービスと復号するサービスで鍵を分離
2021-03-06

View Slide

暗号鍵の扱い
 暗号鍵はKubernetesのSecurityリソースで管理
 Secret自体はただのbase64エンコードされた文字列
 YAMLファイルで管理するのはセキュアではない
 KMS(鍵管理システム=Key Management System)の併用
 Hashicorp Vault/クラウドプロバイダのKMS/pgpなどで暗号化
 鍵をSecretに配置するリソース/ソフトウェアとの併用
 ExternalSecretリソース/kubesec/SealedSecretリソースなど
2021-03-06

View Slide

機密データを使用したPodを破棄
 機密データを不用意に再使用しない
 Podを停止することで機密データを削除
 Pod上のアプリケーションでメモリ上の機密データ削除
2021-03-06

View Slide

機密データを含む通信の暗号化
 KubernetesはNode間の通信を暗号化可能
 Pod間の通信は暗号化も認証もされない
 解決策
 アプリケーション側で経路を暗号化
 既存の経路暗号化されるソリューションを使用
gRPC
Istio
2021-03-06

View Slide

gRPC(https://grpc.io/)
 Google社が開発したRPC(Remote Procedure Call) 実装
 Web経由のAPIなどで使用
 経路としてhttp/2を使用
→TLS暗号化済み
 セッション開始時に認証も可能
 TLS用の証明書管理が必要
2021-03-06

View Slide

Istio(https://istio.io/)
 Istioはサービスメッシュを
コントロールするソフトウェア
 Istioコントロール配下のPodに、
Proxyをサイドカーパターンで配置
 Proxy間の通信をmTLSで暗号化
 Pod間の通信をIstioコントローラで制御可能
 Istio Ingressで、Istioとの連携も可能
2021-03-06

View Slide

View Slide

セキュリティはプロセス
 コンテナホスト自体の脆弱性チェック
 定期的なイメージ再作成
 イメージ検査
 テスト(アプリケーション、ペネトレーション、負荷など)
 デプロイ
 未知のマルウェア、インジェクションなどへの対応
 コンテナの寿命を短くする
 ランタイム監視の実施
 障害発生時のエスカレーション
2021-03-06

View Slide

DevSecOpsの実践
 一貫した開発・セキュリティ・運用が必要
 シフトレフト
 バグを運用でカバーすると高コスト
 バグを開発で出し切る
 運用、セキュリティコストの削減
 DevSecOpsの自動化
 CI/CDの考え方の導入+セキュアな考え方
2021-03-06

View Slide

Development
 ベースOSの選定
 言語、ライブラリ、パッケージの選定
 セキュリティ基準に則った開発
 アプリケーションの静的解析
 ペネトレーションテスト
2021-03-06

View Slide

Security
 セキュリティ基準の策定
 CIS/NIST
 GDPR/PCI-DSS/HIPS
 DevとOpsに対するセキュリティ対策支援
 開発のセキュリティ基準
 コンテナセキュリティの方針決定
 開発環境→デプロイ→本番環境のすべてをセキュアにする
2021-03-06

View Slide

Operations
 イメージアップデートとデプロイ
 脆弱性スキャンの反映
 動的スキャナとの組み合わせ
 ログ/障害監視
 障害検知時のエスカレーション
2021-03-06

View Slide

コンテナイメージの脆弱性スキャン
 スキャンにより脆弱性が見つかった場合
 ベースイメージ、パッケージ、使用ライブラリの更新
 イメージの再作成→脆弱性検査
 新コンテナイメージのデプロイ
 ローリングアップデート
 カナリアデプロイ
 ブルー/グリーンデプロイ
 脆弱性は日々発見される
定期的に脆弱性スキャン実施する必要がある
2021-03-06

View Slide

アプリケーションの脆弱性
 アプリケーションの脆弱性
 SQLインジェクション
 CSR/CSRF
 ファイルのインジェクション
 コマンド実行
 アプリケーション脆弱性の対応
 アプリケーションで使用するライブラリは、最新のものを選択
 脆弱性を意識したアプリケーション開発
 ペネトレーションテストの実施
2021-03-06

View Slide

CI/CDツールと
静的イメージスキャンの組み合わせ
 CI/CDツール
 Gitlab
 GitHub Actions
 Jenkins
 Circle CI
 Travis CI
 アプリケーションのテスト/脆弱性スキャン
 イメージ作成後に静的イメージスキャン
2021-03-06

View Slide

ルーチンワークは自動化する
 CI/CDツールで出来ることは自動化する
 アプリケーションテスト
 アプリケーション静的解析
 イメージの静的スキャン
 コンテナ群へのペネトレーションテスト
 デプロイ
 リリース中のコンテナイメージに対する脆弱性スキャン
 Wazuhなど、脆弱性検査及び監視を行うツールもある
2021-03-06

View Slide

人間は、人間に出来ることだけ行う
 コード、テストの作成
 レヴュー
 セキュリティ設計
 リリースのOK/NG
 インシデント発生時の対応
2021-03-06

View Slide

人間の脆弱性も考える
 セキュリティは一番弱いところ(=人間)から狙われる
 ソーシャルハック最強
 アカウント管理を厳格にする?
 厳格にしすぎると、逆に回避策を考えるのが人間
 パスワードマネージャなどのツールに任せる
 もしくはパスワードを使用しない
 ゼロトラストの採用も考慮する
2021-03-06

View Slide

View Slide

Docker APIが外部に公開されてた例(1)
 コンテナ環境を対象としたマルウェアKinsing(日本語化記事)
 間違って設定されたオープン状態のDocker APIポートを攻撃対象
 セキュリティ対策の無効化とログのクリア
 多数のアプリケーション(クリプトマイナーを含む)を停止/削除
 競合する悪意のあるコンテナを強制終了/イメージを削除
 Kinsingマルウェアのダウンロードと実行
 Kinsing自体の拡散
2021-03-06

View Slide

Docker APIが外部に公開されてた例(2)
 攻撃者が悪意あるイメージをホスト上に直接ビルド
(日本語化記事)
 公開されているDocker APIを使用
 コンテナイメージを攻撃対象のホストでビルド
 作成されたイメージはどこのレジストリにも保存されない
→確認／対応しにくい
 イメージの名前／IDをランダムに生成
 クリプトマイニングを実行
2021-03-06

View Slide

公開されたイメージ内に
マルウェア実行するスクリプト
 DzMLTによるクリプトマイニング(日本語訳)
 DockerHub上に存在するイメージに含まれた
 イメージ自体にマルウェアは含まれない
 イメージのENTRYPOINTでsshdを起動しバックドアとする
 GitHubからマルウェアをダウンロードして実行
 クリプトマイニングを実行
2021-03-06

View Slide

View Slide

セキュリティよくわからない
 自分で学ぶ
 ThinkITで連載してます(ダイマ)
https://thinkit.co.jp/series/9523
 金で解決する
 セキュリティに強い人材を確保・育成する
 セキュリティコンサルタントを雇う
 商用のコンテナセキュリティツールを使う
2021-03-06

View Slide

商用コンテナセキュリティ製品
 Aqua Security
 イメージスキャン、ランタイムスキャン、監視、L3FW
 日本販社あり
 Prisma Cloud
 イメージスキャン、ランタイムスキャン、監視、L7FW
 sysdig
 イメージスキャン、ランタイムスキャン、監視
2020-10-24

View Slide

最後に
 この資料は、コンテナのセキュリティを考える為のきっかけ
 セキュリティ的な考え方はオンプレミス・IaaSと変わらない
 でも、コンテナのセキュリティには違う部分もあります
 自分で答えを見つけよう
2021-03-06

View Slide

How to secure container environment

How to secure container environment

Satoru MIYAZAKI

More Decks by Satoru MIYAZAKI

Other Decks in Technology

Featured

Transcript