Docker outside of Docker (DooD) と Docker in Docker (DinD) のセキュリティリスク比較

概要

• AIコーディングエージェントでの開発ではDevContainerを使うようにしているが、既存の開発のDocker環境が使いまわせない問題がある
• そこでDooDを使うという話が出てくるが、リスクを把握せず使うものではないため具体例を挙げる

DooDとDinDについて

Docker outside of Docker (DooD) と Docker in Docker (DinD) は、コンテナ内でDockerを実行する2つの主要なアプローチです。
DooDはホストのDockerデーモンを直接利用します。
DinDはコンテナ内で実行される専用のDockerエンジンに依存します。

主な問題点

DooDの危険性

1. ホストのDocker socketsをマウントするため、コンテナ内からホスト上の全コンテナを操作可能
2. 特権コンテナを起動することで、ホストファイルシステムへの完全アクセスが可能
3. docker.sockへのアクセスが実質的にホストのroot権限をコンテナに与える

検証結果

注意：不用意にホストマシンの重要なパスをマウントしない

DooDを使用した検証では、以下の手順でホストファイルシステムへの侵害が可能であることが確認される：

ホストマシンで一時ファイルを作成。

touch /tmp/dood-test-file.txt
ls -l /tmp/dood-test-file.txt

ホストマシンからDooDコンテナ起動。

docker run -it --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  ubuntu:22.04 /bin/bash

DooDコンテナからホストマシンのコンテナが見える。

docker ps

DooDコンテナ内でインストール。

apt-get update
apt-get install -y docker.io

DooDコンテナから特権コンテナを起動、ホストのtmpをマウントしている。

docker run --privileged -it --rm -v /tmp:/host_tmp ubuntu:22.04 /bin/bash

特権コンテナから /tmp/dood-test-file.txt が見える。

ls -l /host_tmp

特権コンテナから /tmp/dood-test-file.txt を削除。

rm /host_tmp/dood-test-file.txt

ホストでファイルを確認するとファイルがない。

ls -l /tmp/dood-test-file.txt

DinDの根本的課題

1. 特権コンテナへの依存が必須
2. コンテナ内のrootユーザーがホスト上のrootユーザーと同等の権限を持つ
3. ホストカーネルの脆弱性などを突いて、コンテナ外への脱出（コンテナエスケープ）が発生した場合、攻撃者がホストの完全なroot権限を取得するリスク

ホスト側で明示的にマウントしなければ問題はないとされる。

docker run -it --rm \
  --privileged \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /:/host \
  docker:dind

対策

一般的な対策

1. 可能な限りDocker socketのマウントを避ける（DooDを使わない）
2. 特権コンテナの使用を最小限に抑える
3. コンテナ実行時に最小権限の原則を適用する
4. ホストファイルシステムのマウントを必要最小限に制限する

DinDの解決策としてPodmanやSysboxの使用（Linux専用）があるのでまたの機会に調べてみようと思います。

参考リンク

• Docker-in-Docker official documentation