【テクニカル・上級編】ルートレスコンテナ(Rootless Mode)の運用と権限分離 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

コンテナの「脱獄」を許すな：Rootlessアーキテクチャがもたらす真の防御境界

「Dockerデーモンをrootで動かさない」というのは、もはやセキュリティのABCだ。しかし、多くの現場では、コンテナ内のrootがホストのrootへエスカレートするリスクを、単なる「設定上の不注意」として片付けている。

攻撃者の視点に立てば、コンテナ内のroot権限奪取はゴールではない。それは単なる「足がかり（Foothold）」に過ぎない。ホストのカーネル・サブシステムに直接触れられる状態を作ることこそが、彼らの真の目的だ。今回は、この防衛の要である「Rootlessモード」を、単なる運用回避策ではなく、攻撃者のラテラルムーブメントを封殺するアーキテクチャとして再定義したい。

—

1. なぜ「Rootless」が不可欠なのか：低レイヤからの視点

コンテナの脆弱性の多くは、namespacesとcgroupsを分離するカーネル境界の不備に起因する。特に、特権コンテナがホストの/devや/proc、あるいはsysfsにアクセスできる設定になっていれば、CVE-2022-0492（cgroup v1の脆弱性）のような深刻なエスカレーションは容易に引き起こされる。

Rootlessモードの真価は、user_namespaces(7)を利用し、コンテナ内のrootユーザーをホスト上の「権限を持たない高UIDユーザー」にマッピングすることにある。これにより、たとえコンテナ内でカーネルの脆弱性を突こうとしても、ホスト側からは「何の権限も持たないただのユーザープロセスが、自分自身をいじめている」ようにしか見えない。攻撃者は、ホストのカーネルを操作する特権を一切手にできないのだ。

—

2. 実装：Podmanによる真の分離

DockerもRootlessモードをサポートしているが、アーキテクチャの根幹からRootlessを前提に設計されたPodmanを採用することをお勧めする。Podmanはデーモンレスであり、プロセスモデルが単純なため、攻撃対象領域（Attack Surface）が圧倒的に小さい。

Rootless実行時の構成サンプル

まず、各ユーザーが自身でコンテナを管理できるようにするための設定が必要だ。/etc/subuidと/etc/subgidを正しく定義し、カーネルのunprivileged_userns_cloneが有効であることを確認せよ。

# /etc/subuid にユーザーごとのマッピングを定義
# ユーザー名:開始UID:範囲
# この設定により、コンテナ内のUID 0が、ホスト上のUID 100000〜にマッピングされる
echo "appuser:100000:65536" | sudo tee -a /etc/subuid
echo "appuser:100000:65536" | sudo tee -a /etc/subgid

# カーネルパラメータでユーザー名前空間を許可
sudo sysctl -w kernel.unprivileged_userns_clone=1

Podman実行時、ネットワークスタックも分離する必要がある。slirp4netnsを使用することで、ホストのネットワーク名前空間を汚染せずにユーザー空間で通信を完結させる。

# Rootlessでコンテナを起動するコマンド例
podman run -d \
  --name secure-app \
  --network slirp4netns \
  --userns=keep-id \
  --cap-drop=ALL \
  --security-opt=no-new-privileges \
  my-app-image:latest

# --cap-drop=ALL: すべてのLinux Capabilityを剥奪
# --security-opt=no-new-privileges: execve()時の権限昇格を禁止

—

3. 防御の深層：生成AIと境界保護の未来

我々が直面している新たな脅威は、コンテナ内でのコード実行にとどまらない。コンテナ内で動作するLLMアプリケーションに対する「プロンプトインジェクション」は、インフラの境界を越えてデータベースや外部APIを操作する。

Rootless化された環境であっても、アプリケーション層のガードレイルがなければ不十分だ。コンテナの要塞化に加え、以下の防御層を設計に組み込むべきである。

eBPFによるシステムコール監視: Rootless環境であっても、コンテナが予期せぬシステムコール（例: ptraceやkexec_load）を発行しようとした場合、eBPFプログラムで即座にブロックする。
通信のZero Trust化: コンテナ間の通信にはmTLS（相互TLS）を強制し、通信プロトコルレベルでの正当性を検証する。
ガードレイルの分離: LLMへの入力プロンプトを検証するバリデーターは、メインのコンテナとは別の「検証専用サイドカー」として実行し、Rootlessの権限境界をさらに物理的に分離する。

—

最後に：セキュリティは「諦め」の積み重ねである

優秀なエンジニアほど、「OSの機能を全部使いたい」「root権限がないと動かない」という誘惑に負けそうになる。しかし、真に堅牢なシステムを構築する者は、「コンテナ内でroot権限を必要としないコードを書く」という厳しい制約を、開発チームに課すことのできる者だ。

Rootlessモードへの移行は、単なる設定変更ではなく、インフラとアプリケーションの設計思想を「最小権限」という原点に引き戻すプロセスである。

攻撃者は常に、境界の僅かな隙間を狙っている。その隙間を、カーネルレベルの権限分離で物理的に埋める。これこそが、現代のクラウドセキュリティにおける唯一の正解だ。

今すぐ、本番環境の ps aux を確認してほしい。もし dockerd や podman がrootで動いているならば、それは既に「家の中に泥棒を招き入れている」のと同じだ。手遅れになる前に、権限を剥ぎ取れ。