この記事は playpark Blog からの転載です。
この記事で分かること
- デフォルトのDockerコンテナに残る14のケーパビリティが何を意味するか
-
cap_drop: ALL・read_only・no-new-privilegesを選んだ理由 - AI開発ツールにおけるコンテナセキュリティの判断基準
背景: AI開発ツールの攻撃面は通常のWebアプリより広い
2026年初頭、AI開発ツール関連で3つのCVEが公開された。
| CVE | 影響 | ホスト直接実行時のリスク |
|---|---|---|
| CVE-2026-25253 | リモートコード実行 | ホスト全体へのアクセス |
| CVE-2026-24763 | 権限昇格 | root権限の奪取可能性 |
| CVE-2026-25157 | 情報漏洩 | APIキー・トークンの流出 |
通常のWebアプリケーションと違い、AI開発ツールにはSkills経由でシェルコマンドの実行能力がある。ファイルの読み書き、API呼び出し、コード実行が可能な環境で脆弱性が見つかった場合、攻撃面が桁違いに広くなる。
「Dockerに入れれば安全」と考えがちだが、デフォルトのDockerコンテナにはroot権限と14個のLinuxケーパビリティが残っている。これでは隔離としては不十分。
選択肢の検討
| アプローチ | セキュリティ | 運用コスト | 導入難易度 |
|---|---|---|---|
| ホスト直接実行 | CVE1つでホスト全体が危険 | なし | なし |
| Docker（デフォルト設定） | 名前空間隔離のみ、root + 14ケーパビリティ | 低 | 低 |
| Docker + ハードニング | ケーパビリティゼロ、読み取り専用FS | 低（初回設定のみ） | 低 |
| gVisor / Kata Containers | カーネルレベルの強力な隔離 | 高 | 高 |
なぜこの3つの設定を選んだか
1. cap_drop: ALL — 最もコスパの高いハードニング
cap_drop:
- ALL
DockerデフォルトではNET_RAW、SYS_CHROOT、MKNODなど14個のケーパビリティが有効になっている。AI開発ツールに必要なのはネットワーク接続とファイルの読み書きだけであり、これらのケーパビリティは不要。
判断基準: Node.jsベースのアプリケーションは特権ケーパビリティなしで動作する。実際に全削除した状態で3ヶ月運用し、ケーパビリティ関連のエラーはゼロだった。
2. read_only: true — 書き込み可能領域の明示化
read_only: true
volumes:
# 設定は読み取り専用
- ./config/openclaw.json:/home/node/.openclaw/openclaw.json:ro
# データだけ読み書き可能
- ./data/memory:/home/node/.openclaw/memory:rw
tmpfs:
- /tmp:size=512M
ルートファイルシステムを読み取り専用にし、書き込みが必要な領域をボリュームマウントとtmpfsでピンポイントに指定する設計。攻撃者がコンテナ内でコードを実行できても、バイナリの改ざんやマルウェアの書き込みが不可能になる。
判断基準: 「どこに書き込めるか」をデフォルト許可からホワイトリスト方式に変える発想。
3. no-new-privileges — 権限昇格の経路を断つ
security_opt:
- no-new-privileges:true
setuid/setgidビットを利用した権限昇格を完全ブロック。CVE-2026-24763のような権限昇格脆弱性は、この設定だけで攻撃経路を潰せる。
判断基準: 設定1行で防げるリスクを放置する理由がない。
補足: 非rootユーザー実行
user: "1000:1000"
Dockerのデフォルトはroot実行。明示的に非rootを指定しないとコンテナ内のプロセスがroot権限を持つ。
まとめ: どういう場面で使うべきか
AI開発ツールに限らず、シェルコマンド実行能力を持つアプリケーションをDockerで動かす場合、cap_drop: ALL + read_only + no-new-privilegesの3点セットは最低限のハードニングとして推奨できる。
導入コストはdocker-compose.ymlへの数行追加のみ。運用コストはゼロ。CVEが公開されたときに「うちのコンテナはケーパビリティゼロで読み取り専用」と即答できる状態を作っておくことが、セキュリティ対応の初動を大きく変える。
さらに深掘りしたい方へ
この記事ではDockerハードニングの3つの設定と選定理由を解説しました。
【OpenClaw Docker セキュリティ】CVE対策で学ぶコンテナハードニング実践 — cap_drop ALL から始める安全運用 ではさらに：
- ボリューム設計の全体像（マウント権限マトリクス、Skills読み取り専用マウント、tmpfs設計）
- ホスト環境からDocker環境への移行手順とセキュリティチェックリスト
- AI開発ツール特有の多層防御（サンドボックス + Skills制限 + ネットワーク制限 + 監視）
playpark について
playpark LLC - 業務自動化・AI活用・Web開発
