メインコンテンツまでスキップ

第18章：docker.sockを渡すと何が起きる？（だいたい最強権限）🐙🔥

いきなり結論！😇 /var/run/docker.sock をコンテナに渡す＝そのコンテナに「Dockerデーモンを操作する権利」を渡すってことです。 そして Dockerデーモンは基本 “強い権限（root級）” で動くので、結果として ホストにかなり近いことまでできがちになります⚠️🐉 （Docker公式も「docker group が root級」って警告してます。方向性は同じ話です）(Docker Documentation)

この章のゴール🎯✨​

  • docker.sock が 何者で、なぜ危険なのかを説明できる🙂
  • 「便利だから付ける」を卒業して、安全な代替を選べる🧠🔒
  • どうしても必要なときに、被害半径を閉じ込める設計ができる📦🧱

まず docker.sock って何？🧩​

docker.sock はざっくり言うと **Dockerクライアント（dockerコマンド）→ Dockerデーモンにお願いするための“通路”**です🚪

  • 通常：ホストの docker コマンドが、このソケット経由でデーモンに話しかける🗣️
  • 危険パターン：その通路を コンテナにも渡す → コンテナの中からでもデーモンにお願いできる😱

イメージ図🖼️✨

あなた（ホスト）: docker ps  ──▶  /var/run/docker.sock  ──▶  Dockerデーモン（強い権限）
                              ▲
                              │（これをコンテナに渡すと…）
コンテナ内: docker ps  ────────┘  → ホストのDockerを操作できちゃう

何がマズいの？「できちゃうこと」が強すぎる💪😇→💥​

docker.sock を触れるということは、だいたい次のことが可能になります👇

  • コンテナ一覧を見る / 起動する / 停止する 🧯
  • イメージを取る / ビルドする 🏗️
  • ボリュームやネットワークを作る 🕸️
  • そして最悪ライン： 「ホストに触れる設定のコンテナ」をデーモンに作らせる（＝ホスト級）🐉🔥

Docker公式も「デーモンに触らせるのは危ないから保護しろ（TLSなど）」というスタンスです🔐(Docker Documentation) つまり “デーモン操作権”は、鍵束丸ごと渡すくらい重いです🔑💣

よくある「やりがち」シーン集（そして罠）🪤😵​

1) 「コンテナの中から docker コマンド使いたい」🐳​

テストで別コンテナ立てたい、e2eで依存サービスを増やしたい、などで出がち。

👉 でもその一手（docker.sock マウント）で、**テスト用コンテナが“司令塔”**になります📢😱

2) 「CIっぽくしたい（ローカルでGitHub Actionsの真似）」🏃‍♂️💨​

便利だけど、ローカルの秘密やファイル共有が絡むと 漏れ経路が増える💦

3) AI拡張が提案してくる🤖🧨​

AIが「簡単ですよ！」って -v /var/run/docker.sock:/var/run/docker.sock を出してきがち😇 ここで覚える合言葉： “sock を渡す提案が出たら、赤信号🚨”（レビュー必須）🧑‍⚖️✅

重要ポイント：read-only でマウントしても安全にならない🙅‍♂️🔒​

ファイル共有なら :ro が効きますが、**ソケットは“通路”**です🚪 通路がある限り、相手（デーモン）に「これやって」が言えちゃうので、本質的に危険度は落ちません😇💥

安全な代替案ベスト4🏆🔁（おすすめ順）​

A) 「docker を使う処理」はホスト側で実行する🏠✅​

一番シンプルで事故が少ないやつ！

  • コンテナ内：ビルド成果物を作るだけ
  • ホスト：docker build / docker compose up を実行するだけ

👉 これだけで docker.sock を渡す理由が消えること、多いです🙂✨

B) “別のDocker”に閉じ込める（隔離専用のデーモン）📦🧱​

「どうしてもコンテナ内からDocker操作したい」なら、 操作対象のDockerデーモンを“別物”にするのが強いです💪

例（考え方）：

  • ホストのDockerじゃなく、隔離用VM / 隔離用デーモンを操作する
  • そうすると、壊れても “隔離箱の中だけ” で済む🧯

「リモートアクセスするならTLSで守れ」方針もこの流れです🔐(Docker Documentation)

C) “許可リスト式”のソケットプロキシを挟む🚧✅​

docker.sock を直結せず、間にプロキシを置いて 「読むだけOK」「このAPIだけOK」みたいに できる範囲を削るやり方です✂️

代表例として、APIパスごとに許可/拒否を環境変数で切り替える実装があります🧰(GitHub) （※サードパーティなので、採用時は“信頼できるか”も含めて判断しよう🙂🔍）

D) Rootless など「デーモン側の権限」を落とす🧑‍🚀🔒​

根本解決ではないけど、最悪の被害を減らす方向。 Docker自体も Rootless という道を用意してます。(Docker Documentation)

どうしても docker.sock が必要なときの「隔離専用コンテナ」設計🧱📦​

やるなら、最低でもこの発想でいきます👇（事故りにくさ優先😇）

1) 役割を分ける（“sock担当”を分離）👥​

  • 通常アプリコンテナ：sock無し（絶対）🙅‍♂️
  • 操作専用コンテナ：sock有り（最小機能・最小コード）✅

👉 “操作専用”は、小さく・短命に・監視しやすくするのがコツ🎯

2) 操作専用コンテナは「読むだけ」から始める👀​

  • いきなり作成/削除系を許すと、事故が派手になります💥
  • まずは ps や inspect など 参照用途だけで設計する🙂

3) “共有（bind mount）” とセットにしない🧨​

sock + bind mount は、危険が乗算しがち😇💣 （第16章/17章の話がここで効いてくる！📎✨）

ミニ演習（安全な範囲で）🧪🙂​

演習1：docker.sock を渡すと「ホストのDockerが見える」を体験👀​

目的：**“権限が移る感覚”**を掴む！

  1. docker CLI が入った小さなコンテナを起動
  2. docker.sock を渡して、コンテナ内で docker ps
  3. ホスト側のコンテナ一覧が見えたら成功🎉

ポイント💡

  • これだけで「中のコンテナ」ではなく **“外（ホスト）のDocker”**を触ってる感覚になるはず😇

（※ここでは危険な操作の具体例はやりません🙅‍♂️🔥 “見えるだけでも強い”が分かればOK！）

演習2：リポジトリから危険カードを検知する🔍🚨​

目的：AI提案やコピペで混入しがちな設定を早期発見！

rg -n "docker\.sock|/var/run/docker\.sock|docker_engine" .
  • 見つかったら、まずは **「本当に必要？」**を自問🧠
  • 必要なら **「操作専用コンテナに隔離できる？」**を検討📦🧱

よくある詰まりポイント集😵‍💫🩹​

Q1. 「権限エラーで docker.sock に繋がらない」​

A. それは “勝手に触れない” 方向に倒れてるので、ある意味良い兆候😇 無理に権限を広げる前に、まず sock方式をやめられないかを検討しよう🔁

Q2. 「テストでどうしてもコンテナ増やしたい」​

A. まずは代替案A（ホスト実行）→無理ならB（別Docker）→最後にC（プロキシ）って順に考えると事故りにくいよ🙂🏆

章末まとめ：docker.sock が出たらこのチェック✅😇​

  • それ、ホスト側で実行に寄せられない？🏠
  • “sock付き”を アプリ本体から分離できてる？👥
  • “sock付き”は 最小機能・短命・小さなコード？🪶
  • bind mount とセットにしてない？（危険度UP）🧨
  • 可能なら 別Docker / プロキシ / Rootless を検討した？🧱🔒

次の章（第19章）は、ボリュームの UID/GID（誰が書ける？） で「静かにデータが壊れる」系を潰していきます🗃️🛡️ この第18章が分かると、“操作権”と“データ権”を分離する発想が一気に強くなるよ💪😄✨