コンテナランタイムの深層：その「特権」をどこまで剥ぎ取れるか
多くのエンジニアが「Dockerからcontainerd/CRI-Oへ移行したからセキュアになった」と安堵している。だが、現場のインシデントハンドリングの最前線にいる者から言わせれば、それは単に「攻撃の入り口が新しくなった」だけに過ぎない。
コンテナランタイムは、カーネルとユーザー空間の境界で最も泥臭い処理を行う場所だ。今回は、表面的な設定変更ではなく、ランタイムの低レイヤに潜むリスクと、それを物理的に封じ込めるアーキテクチャについて掘り下げる。
—
1. ランタイム脆弱性の「本質」を理解する
近年のランタイム脆弱性（CVE-2024-XXXX系など）の多くは、単なるバグではない。名前空間（Namespace）やコントロールグループ（cgroups）の分離が不完全なケース、あるいはUnixドメインソケットを通じたIPC通信におけるプロトコル仕様の解釈の差異が根本原因だ。
例えば、containerdのShim（コンテナのライフサイクル管理プロセス）がホストのプロセスID空間をどのようにハンドリングしているか考えたことはあるか？ 悪意のあるコンテナがホストのPID空間を覗き見られる状況下では、どんなに厳格なIAM設定も無意味だ。我々が守るべきは「コンテナの中」ではなく、「コンテナがホストに渡す特権の最小化」である。
—
2. containerdの要塞化：プラグインの断捨離
containerdはモジュール設計ゆえに、不要なプラグインが攻撃面（Attack Surface）を広げている。デフォルトのインストールでは、不要なネットワークプロトコルやデバッグ用のインタフェースが有効になっていることが多い。
以下の設定は、config.tomlで最低限実施すべき「泥臭い防衛」の一例だ。
# /etc/containerd/config.toml
[debug]
# 本番環境でデバッグ用ソケットを残すのは自ら脆弱性を公開するようなもの
level = "warn"
[plugins."io.containerd.grpc.v1.cri"]
# コンテナのネットワーク名前空間を孤立させるための設定
disable_cgroup = false
# ホストのポートへの不用意なバインドを避ける
sandbox_image = "registry.k8s.io/pause:3.9"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
# runcのランタイムオプションで、不要なsyscallを遮断する
# 攻撃者が好むmountやptraceを拒否するプロファイルを強制する
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
# セキュリティ上の根幹：コンテナがホストの機能を悪用するのを防ぐ
NoNewPrivileges = true—
3. シーコンプ（seccomp）とカーネル防衛の境界
「ランタイムの設定」は、単なる設定ファイルだけではない。カーネルが受諾するシステムコールをどこまで狭められるかが勝負だ。
特に、コンテナランタイムが実行する runc や crun の挙動を seccomp プロファイルで制御せよ。現在、多くの環境ではデフォルトのプロファイルが適用されているが、これは「広すぎる」。
攻撃者は memfd_create や ptrace を悪用し、メモリ上にバイナリを展開してファイルシステムを残さずにペイロードを実行する（ファイルレス攻撃）。これを防ぐには、コンテナの役割に応じて以下のシステムコールを徹底的に禁止するポリシーを適用すべきだ。
/* 必要なsyscall以外をすべて拒否するセキュアな設計指針 */
{
"defaultAction": "SCMP_ACT_ERRNO",
"architectures": ["SCMP_ARCH_X86_64"],
"syscalls": [
{
"names": ["read", "write", "exit", "futex"],
"action": "SCMP_ACT_ALLOW"
}
]
}—
4. 未来への備え：耐量子暗号とガードレイル
今、我々が直面しているのは、コンテナ間の通信を保護するTLSの脆弱性だ。量子コンピュータが実用化されれば、現在主流のRSA/ECDSAベースの通信は暗号解読の対象となる。
特に、ランタイムが管理する「コンテナ間の制御信号（gRPC）」に対しては、今のうちから耐量子暗号（PQC）への移行パスを意識したネットワークポリシーを設計しておく必要がある。また、生成AIをコンテナ内で動かすケースが増えているが、これにはプロンプトインジェクションを防ぐための「ガードレイル層」をコンテナ側のサイドカーとして配置し、入力値を厳格にサニタイズするアーキテクチャが必須だ。
結びに：エンジニアとしての矜持
セキュリティは「チェックボックスを埋める作業」ではない。それは、OSのメモリ構造やCPUの演算単位まで想像力を働かせ、攻撃者の脳内をトレースし続ける「終わりなきパズル」だ。
containerdの設定を一行変える際、それがホストのメモリ内でどのようなポインタ操作に影響を与えるかを想像してほしい。その深い洞察こそが、インフラを「要塞」へと進化させる唯一の道である。
次の運用フェーズでは、まずは自社のランタイムがどのような特権プロセスとしてカーネルと対話しているか、straceでパケットとシステムコールのログを追いかけることから始めてみてほしい。そこには、ドキュメントには載っていない「真実の攻撃面」が必ず見えてくるはずだ。
コメント