Overview
コンテナセキュリティ(Container Security)とは、DockerやPodmanなどのコンテナ技術を利用したアプリケーション環境において、コンテナイメージの作成からデプロイ、ランタイムまでのライフサイクル全体を通じてセキュリティを確保するための包括的な取り組みです。コンテナは軽量かつ高速にアプリケーションを展開できる一方で、従来の仮想マシンとは異なるセキュリティ課題を抱えています。
コンテナ環境では、ホストOSのカーネルを共有するため、カーネルレベルの脆弱性がすべてのコンテナに影響を与える可能性があります。また、コンテナイメージに含まれるライブラリやパッケージの脆弱性、不適切な権限設定、機密情報のハードコーディングなど、多層的なリスクが存在します。コンテナセキュリティは、これらのリスクに対してビルド時・デプロイ時・ランタイム時のそれぞれの段階で適切な防御策を講じることを目的としています。
近年ではクラウドネイティブアーキテクチャの普及に伴い、コンテナセキュリティの重要性がますます高まっています。DevSecOpsの概念のもと、CI/CDパイプラインにセキュリティスキャンを組み込み、脆弱性のあるイメージがプロダクション環境にデプロイされることを防止する「シフトレフト」アプローチが標準的なプラクティスとして定着しつつあります。
Details
コンテナイメージのセキュリティ
コンテナイメージは、アプリケーションとその依存関係を含むパッケージです。イメージのセキュリティは、ベースイメージの選定から始まります。Alpine Linuxやdistrolessイメージなど、最小限のコンポーネントのみを含むベースイメージを使用することで、攻撃対象面を縮小できます。
イメージの脆弱性スキャンは、Trivy、Grype、Snyk Containerなどのツールを使用して実施します。これらのツールは、イメージに含まれるOSパッケージやアプリケーション依存関係の既知の脆弱性(CVE)を検出し、深刻度に基づいた対応の優先順位付けを支援します。
コンテナランタイムセキュリティ
コンテナが実行中の環境における保護は、ランタイムセキュリティと呼ばれます。コンテナ内で予期しないプロセスの実行、不審なネットワーク接続、ファイルシステムの改ざんなどの異常な振る舞いをリアルタイムで検知・防御します。
Falcoなどのランタイムセキュリティツールは、Linuxカーネルのシステムコールを監視し、事前に定義したルールに基づいて不審な活動をアラートします。また、AppArmorやSELinuxのセキュリティプロファイルを適用することで、コンテナのシステムコールやファイルアクセスを制限できます。
コンテナレジストリの保護
コンテナレジストリは、イメージの保管・配布を行う重要なインフラです。Docker Hub、Amazon ECR、Google Container Registryなどのレジストリでは、イメージの署名検証、アクセス制御、脆弱性スキャンの自動化が求められます。
Docker Content Trust(DCT)やSignature Verification機能を利用することで、信頼されたイメージのみをプルおよびデプロイすることが可能です。不正なイメージの混入や改ざんを防止するため、イメージ署名は不可欠な対策です。
コンテナネットワークセキュリティ
コンテナ間の通信は、デフォルトでは制限されていないことが多く、ネットワークポリシーを明示的に定義する必要があります。不要なコンテナ間通信を遮断し、必要最小限の通信のみを許可するマイクロセグメンテーションの実装が推奨されます。
また、サービスメッシュ(Istio、Linkerdなど)を導入することで、コンテナ間通信の暗号化(mTLS)、トラフィックの可視化、アクセス制御を統合的に管理できます。
特権コンテナと権限管理
特権コンテナ(Privileged Container)は、ホストOSのほぼすべてのリソースにアクセスできるため、セキュリティ上極めて危険です。特権モードでの実行は原則として禁止し、必要最小限のLinux Capabilitiesのみを付与するべきです。
rootユーザーでのコンテナ実行を避け、非rootユーザーでプロセスを実行する設定が推奨されます。また、読み取り専用のルートファイルシステムを設定することで、コンテナ内のファイル改ざんリスクを軽減できます。
Security Measures
- 01最小限のベースイメージを使用:Alpine LinuxやGoogle distrolessイメージなど、必要最小限のコンポーネントのみを含むベースイメージを選定してください。不要なパッケージやツール(curl、wget、シェルなど)を含めないことで、攻撃対象面を大幅に縮小できます。
- 02CI/CDパイプラインでのイメージスキャン:Trivy、Grype、Snyk Containerなどのツールをビルドパイプラインに統合し、脆弱性のあるイメージのデプロイを自動的にブロックしてください。CRITICAL・HIGHレベルの脆弱性が検出された場合はビルドを失敗させるゲートを設定しましょう。
- 03非rootユーザーでのコンテナ実行:Dockerfileで非rootユーザーを作成し、USERディレクティブで指定してください。特権コンテナの使用は原則禁止とし、必要な場合は最小限のLinux Capabilitiesのみを付与する設計としましょう。
- 04イメージ署名と信頼チェーンの構築:Docker Content TrustやCosignを使用してイメージに署名し、デプロイ時に署名検証を義務化してください。信頼されていないレジストリからのイメージプルを禁止するポリシーも併せて設定しましょう。
- 05ランタイム監視と異常検知:FalcoやSysdig Secureなどのランタイムセキュリティツールを導入し、コンテナ内の不審なプロセス実行、ファイル変更、ネットワーク接続をリアルタイムで監視・アラートしてください。
- 06機密情報の外部管理:APIキーやデータベースパスワードなどの機密情報をコンテナイメージやDockerfileにハードコーディングしないでください。Kubernetes Secrets、HashiCorp Vault、AWS Secrets Managerなどの外部シークレット管理サービスを利用しましょう。
Incidents
📋 Docker Hubへの不正イメージアップロード(2018年)
2018年、Docker Hub上で暗号通貨マイニングマルウェアが仕込まれた不正なコンテナイメージが発見されました。攻撃者は人気のある公式イメージに類似した名前(タイポスクワッティング)でマルウェア入りイメージを公開し、多くのユーザーが誤ってダウンロードしました。
この事件では、少なくとも17個の悪意のあるイメージが確認され、累計で約500万回ダウンロードされていました。イメージ内にはMoneroマイニングソフトウェアが組み込まれており、コンテナのCPUリソースを不正に使用して暗号通貨を採掘していました。Docker社はこれを受けて、イメージの検証プロセスを強化しました。
📋 Tesla Kubernetesクラスタへの不正アクセス(2018年)
2018年、セキュリティ企業RedLockがTeslaのKubernetesコンソールが認証なしでインターネットに公開されていることを発見しました。攻撃者はこのコンソールを通じてTeslaのAWSクラウド環境にアクセスし、コンテナ内で暗号通貨マイニングを実行していました。
攻撃者は検知を回避するため、マイニングプールの接続先をCloudFlareの背後に隠し、CPUの使用率を低く抑えるなど巧妙な手口を使用していました。この事件は、コンテナオーケストレーション環境の管理画面に対する適切なアクセス制御の重要性を示す代表的な事例となりました。
📋 コンテナエスケープ脆弱性「Leaky Vessels」(2024年)
2024年、Snykのセキュリティ研究者がDockerおよびruncに影響するコンテナエスケープ脆弱性群「Leaky Vessels」を発見しました。CVE-2024-21626をはじめとする4つの脆弱性が報告され、攻撃者がコンテナの隔離を突破してホストOSにアクセスできる可能性がありました。
特にruncの脆弱性は、悪意のあるDockerfileのビルドまたは悪意のあるイメージの実行により、ホストファイルシステムへの不正アクセスやコード実行を可能にするものでした。Docker社とruncコミュニティは速やかにパッチをリリースし、ユーザーに早急なアップデートを呼びかけました。