コンテナセキュリティ.

コンテナセキュリティは、OCI 互換コンテナ(Docker、containerd、CRI-O)のライフサイクル全体を対象とします。ビルド時には、CVE や埋め込みシークレットを検出し、Sigstore/Cosign で署名し、最小限のベースイメージを強制します。配布段階では、レジストリを認証付きアクセスと署名検証で保護します。ランタイムでは、ホストのハードニング、Namespace/cgroup による分離、seccomp、AppArmor、読み取り専用ファイルシステムなどで攻撃面を縮小し、Admission Controller や eBPF ベースのセンサーでポリシー適用と異常検知を行います。

コンテナはホストのカーネルを共有するため、カーネルやランタイムの単一の欠陥だけで分離が破られる可能性があります。CVE-2019-5736 では、悪意あるイメージが /proc/self/exe を介してホストの runc バイナリを上書きし、ノード上で root 権限のコード実行を得られました(runc 1.0-rc7 および Docker 18.09.2 で修正)。2024 年の 「Leaky Vessels」CVE-2024-21626 は、pivot_root の前にホストの作業ディレクトリを指す内部ファイルディスクリプタ(fd/7)を漏らしており、コンテナの cwd を /proc/self/fd/7 に設定すると rootfs から脱出できました(runc 1.1.12 で修正)。Pod の脱出は多くの場合ノードの侵害と同義であるため、多層防御が重要です。capabilities を削除し、非 root で実行し、特権コンテナや hostPath マウントを避け、runc をパッチし続け、gVisor や Kata Containers といったより強力なサンドボックスの採用を検討します。

flowchart LR
  A[ビルド: イメージ検査 + 署名] --> B[レジストリ: 認証 + 署名検証]
  B --> C[アドミッション: 特権/hostPath を拒否]
  C --> D[ランタイム: seccomp, AppArmor, 非root, caps削除]
  D --> E[検知: eBPF/Falco の異常アラート]
  D -. カーネル/runc の欠陥 .-> X[コンテナからホストへの脱出]
  X -. 緩和 .-> F[gVisor / Kata サンドボックス]