Overview
コンテナセキュリティとは、DockerやKubernetesなどのコンテナ技術を安全に運用するための包括的なセキュリティ対策です。コンテナはアプリケーションとその依存関係をパッケージ化して軽量かつ再現性のある実行環境を提供しますが、従来のVM型仮想化と異なりホストOSのカーネルを共有するため、固有のセキュリティリスクが存在します。
コンテナセキュリティは、ビルドフェーズ(コンテナイメージの脆弱性スキャン、ベースイメージの選定)、デプロイフェーズ(Admission Controllerによるポリシー適用、イメージ署名検証)、ランタイムフェーズ(実行中のコンテナの監視・異常検知)の3つのフェーズにわたる保護が必要です。いずれかのフェーズの対策が不十分であれば、攻撃者にコンテナエスケープやクラスタ全体の侵害を許す可能性があります。
特にKubernetes環境では、Pod Security Standards(PSS)によるセキュリティポリシーの強制、RBAC(Role-Based Access Control)による権限管理、ネットワークポリシーによるPod間通信の制御など、多層的な防御策の実装が求められます。コンテナオーケストレーションの複雑さに比例してセキュリティの設定項目も多岐にわたるため、体系的なアプローチが不可欠です。
Details
コンテナイメージのセキュリティ
コンテナイメージは、アプリケーションとその実行に必要なライブラリ・ツール・設定を含むパッケージです。Trivy、Grype、Docker Scoutなどのイメージスキャナーは、イメージに含まれるOSパッケージやアプリケーション依存関係の脆弱性を検出します。CI/CDパイプラインに統合することで、脆弱なイメージの本番環境へのデプロイを防止できます。
ベースイメージの選定も重要です。Alpine LinuxやDistrolessイメージのような最小限のベースイメージを使用することで、攻撃対象面を大幅に削減できます。不要なパッケージ、シェル、デバッグツールを含まないイメージは、攻撃者が侵入後に利用可能なツールを制限し、横展開(ラテラルムーブメント)を困難にします。
Dockerセキュリティのベストプラクティス
Dockerコンテナを安全に運用するためには、いくつかの基本原則があります。まず、コンテナをroot以外のユーザーで実行することが重要です。DockerfileでUSER命令を使用して非rootユーザーを指定し、コンテナプロセスが不要な権限を持たないようにします。
--privilegedフラグの使用は原則として避けるべきです。特権コンテナはホストのすべてのデバイスへのアクセスとほぼすべてのLinux Capabilityを持つため、コンテナエスケープのリスクが大幅に高まります。必要な場合は--cap-addで個別のCapabilityのみを付与し、--cap-drop=allですべてのCapabilityをドロップした上で最小限を追加する方法が推奨されます。
Kubernetesセキュリティとpod Security Standards
Pod Security Standards(PSS)は、Kubernetes 1.25で正式に導入されたPodのセキュリティポリシーフレームワークです。Privileged(無制限)、Baseline(最小限の制限)、Restricted(厳格な制限)の3つのレベルが定義されており、Namespace単位でポリシーを適用できます。
Restrictedレベルでは、rootでの実行禁止、特権コンテナの禁止、ホストネットワーク・PID・IPCの使用禁止、読み取り専用ルートファイルシステム、Seccompプロファイルの強制などが求められます。Pod Security Admissionコントローラーは、Enforce(拒否)、Warn(警告)、Audit(監査ログ記録)の3つのモードでポリシーを適用し、段階的な導入を支援します。
Admission Controllerとポリシーエンジン
Admission Controllerは、Kubernetes APIサーバーへのリクエストを傍受し、リソースの作成・変更・削除の前にバリデーションやミューテーション(自動修正)を行う仕組みです。OPA GatekeeperやKyvernoなどのポリシーエンジンをAdmission Controllerとして導入することで、組織固有のセキュリティポリシーをコードとして定義・適用できます。
例えば、「特定のコンテナレジストリからのイメージのみ許可する」「リソース制限の設定がないPodをブロックする」「最新のイメージスキャン結果がないイメージのデプロイを拒否する」といったポリシーを宣言的に定義し、自動的に適用できます。これにより、開発者の設定ミスによるセキュリティリスクを組織レベルで防止できます。
ランタイムセキュリティと異常検知
コンテナのランタイムセキュリティは、実行中のコンテナの振る舞いを監視し、異常な活動を検知・ブロックするための仕組みです。FalcoはCNCF(Cloud Native Computing Foundation)のプロジェクトで、システムコールを監視し、定義されたルールに基づいてコンテナ内の不審な活動(予期しないプロセス実行、機密ファイルへのアクセス、ネットワーク接続など)をリアルタイムで検知します。
また、SeccompプロファイルやAppArmor、SELinuxなどのLinuxセキュリティモジュールを活用して、コンテナが使用可能なシステムコールやリソースアクセスを制限することも重要です。ネットワークポリシーを使用してPod間通信を最小限に制限し、マイクロセグメンテーションを実現することで、侵害されたコンテナからの横展開を防止できます。
Security Measures
- 01最小限のベースイメージと定期的なイメージスキャン:Alpine LinuxやDistrolessなどの最小限のベースイメージを使用し、不要なパッケージやツールを含めないでください。Trivy、Grype等のスキャナーをCI/CDパイプラインに統合し、ビルド時とレジストリ保管時の両方で定期的に脆弱性をスキャンしましょう。
- 02非rootユーザーでの実行と最小権限の原則:コンテナは必ずrootではなく一般ユーザーとして実行してください。--privilegedフラグの使用を禁止し、必要なLinux Capabilityのみを個別に付与しましょう。読み取り専用ルートファイルシステム(readOnlyRootFilesystem: true)の設定も推奨されます。
- 03Pod Security Standards(Restricted)の適用:Kubernetes環境ではPod Security StandardsのRestrictedレベルを適用し、セキュリティポリシーをNamespace単位で強制してください。まずAuditモードで影響範囲を確認し、段階的にEnforceモードへ移行しましょう。
- 04Admission Controllerによるデプロイゲーティング:OPA GatekeeperやKyvernoなどのポリシーエンジンを導入し、承認されたレジストリからのイメージのみ許可、署名検証済みイメージのみデプロイ許可、リソース制限の必須化などのポリシーを自動適用してください。
- 05ネットワークポリシーによるマイクロセグメンテーション:Kubernetesのネットワークポリシーを使用して、Pod間通信をデフォルトで拒否(Deny All)に設定し、必要な通信のみを明示的に許可してください。Calico、Ciliumなどのネットワークプラグインを活用してL7レベルのポリシーも検討しましょう。
- 06ランタイムセキュリティ監視と異常検知:Falcoなどのランタイムセキュリティツールを導入し、コンテナ内の不審なプロセス実行、ファイルアクセス、ネットワーク接続をリアルタイムで監視してください。SeccompプロファイルとAppArmorを適用し、許可されたシステムコールとリソースアクセスを制限しましょう。
Incidents
📋 Tesla Kubernetes クラスタへのクリプトジャッキング攻撃(2018年)
2018年、Tesla社のKubernetesクラスタが攻撃者に侵害され、クリプトマイニング(暗号通貨の不正マイニング)に利用されていたことが発覚しました。原因は、Kubernetes DashboardがパスワードなしでインターネットにB公開されていたことでした。
攻撃者はダッシュボードを通じてクラスタにアクセスし、Pod内に保存されていたAWS認証情報を取得しました。その後、TeslaのAWSインフラ上でクリプトマイニングを実行しました。この事件は、Kubernetesの管理インターフェースの認証設定とRBACの重要性を示す教訓的な事例です。
📋 Docker Hub公開イメージへのマルウェア混入(2020年〜)
Docker Hubに公開されているコンテナイメージの中に、クリプトマイナーやバックドアが仕込まれた悪意あるイメージが多数発見されています。セキュリティ研究者の調査によると、数百万回ダウンロードされた人気イメージの中にも、悪意のあるコードを含むものが確認されています。
攻撃者は正規のツール名に似た名前のイメージ(タイポスクワッティング)を公開したり、正規イメージのフォークに悪意のあるレイヤーを追加したりする手法を用いています。対策として、Docker公式イメージやVerified Publisherのイメージを優先的に使用し、プライベートレジストリでイメージの検証・承認プロセスを導入することが重要です。
📋 Azureコンテナエスケープ脆弱性「Azurescape」(2021年)
2021年、Microsoft Azureのマルチテナントコンテナサービス(Azure Container Instances)において、コンテナエスケープの脆弱性「Azurescape」が発見されました。この脆弱性を悪用すると、攻撃者は自身のコンテナから脱出し、他のテナントのコンテナを操作できる可能性がありました。
脆弱性はruncの古いバージョンに起因しており、攻撃者が特権昇格によりコンテナのホストノードに到達し、そこからKubernetesクラスタ全体を制御できる可能性がありました。Microsoftは報告を受けて速やかにパッチを適用しましたが、この事件はマルチテナントコンテナ環境における分離の限界とランタイムセキュリティの重要性を浮き彫りにしました。