Dockerに入れたら安全？「箱の中なら大丈夫」を研究で確かめる
アプリを箱へ入れて動かせるDocker。便利な箱の底は、どこにつながっているのでしょう。速さと隔離、配布イメージと実行権限を分けると、設定を見る目が変わります。
この記事の目次
「箱に入れた」は、どこまで分けたことになる？
手順を見ながらDockerでアプリを起動できた。自分のPCへ直接いろいろ入れずに済むし、消すときも楽そう。「箱の中だから、少し失敗しても平気かな」と思いたくなりますよね。ここで一度、箱の底を見てみましょう。
一般的なLinuxコンテナは、プロセスやファイルの見え方などを分けながら、ホスト側のカーネルを共有します。カーネルは、アプリから頼まれたファイル操作や通信などを取り次ぐOSの中核です。箱ごとに完全な別のOSを持っている、と想像すると、この共有部分を見落とします。[2][4]
答えは「何を見せ、何を許した箱かで、守れる範囲が変わる」です。イメージ、実行する利用者、共有するフォルダ、ネットワーク。この四つを見ると、Dockerを使ったかどうかより具体的な問いになります。
起動が軽い。その箱へ、何を渡してよい？
練習用のアプリを箱へ入れ、起動する場面に戻りましょう。アプリごとに大きなOS環境を用意する負担を減らせるのは、コンテナの魅力です。Felter氏らの2015年の性能比較は、仮想マシンとLinuxコンテナを複数の負荷で調べました。軽さを考える研究ですが、それで資料フォルダへの書き込みを許してよいかまでは決まりません。[1]
そこは、箱の外へ届く道を調べる問いです。Combe氏らやBui氏が整理した隔離・権限の問題を、このアプリへ当てはめるなら、「何を見せたか」「どの利用者として動くか」。ホストのカーネルを共有しながら区切る基本構造だからこそ、どんな区切りを設定したかが気になるわけです。[2][4]
Sultan氏らの2019年の総説も、コンテナの守りをLinuxの機能やセキュリティ機構と合わせて整理しています。いまの公式資料には、Dockerの管理役であるデーモンもコンテナも、管理者ではない利用者で動かすrootlessモードがあります。箱の中のUser欄だけを見るのとは、確かめる範囲が違うんですね。[5][8]
では、権限を絞れば中身は気にしなくてよいのでしょうか。Shu氏らが2017年に調べたのは、配布イメージへ入っているソフトウェアの脆弱性です。続いてWist氏らが2020年の公開研究で調べた2,500イメージでも、ダウンロード数や星の数と脆弱性数に相関は見つかりませんでした。「よく使われている」だけを、中身の検査の代わりにはしにくいという手掛かりです。[3][6]
練習用アプリの前へ戻ると、問いが三つに分かれます。動かす負担はどれくらいか。箱の外の何へ届くか。中へ何を入れ、どう更新するか。古い調査の割合を今日のイメージへ貼るより、自分が選んだ版・共有先・権限を確かめる。そのうち「箱の外へ届く道」を、次は共有フォルダ一本で追ってみます。
共有フォルダを一本つなぐと、箱の外へ手が届く
下の図の練習用コンテナには、最初は自分用のファイルしか見えていません。そこへホストの資料フォルダを読み書き可能で渡すと、箱の中のアプリから、その資料を書き換えられる道ができます。コンテナを消しても、共有先で行った変更は残り得る。この一点は覚えておくと役に立ちます。
「読み取り専用」にすれば、その共有先を書き換える道を狭められます。読む必要さえなければ、渡さない選択もある。実際の設定では、利用者の権限、追加した機能、ホストを操作するソケットなど、ほかの経路も一緒に確かめます。[7]
練習用のログ閲覧を例にすると、必要なのは一つのフォルダを読むことだけかもしれません。そこへホームディレクトリ全部を渡すと、ログ以外の設定や資料まで見える範囲に入ります。アプリの便利な初期設定をそのまま使う前に、「この仕事で必要なのはここまで」と指で示せる大きさへ絞ってみましょう。
また、箱の中で管理者として動くことと、ホスト側でどこまでの権限につながるかは、名前空間や起動方法でも変わります。rootという一語だけで判断せず、どの境界を越えられる構成かを見る。最初は難しく感じても、共有先を一つ説明できるところから始めれば、OSの権限を学ぶ理由が具体的になります。
ここでのコツは、「安全ですか」と大きく聞く代わりに、「このアプリは、どのファイルへ、どんな操作が必要か」と聞くこと。ログを読むだけなら、そのフォルダへの書き込みまで必要でしょうか。不要な道を一つ減らす理由を、自分で説明できるようになります。
共有カーネルの仕組みも、すべてのコンテナで同じ運用になるという話ではありません。Docker DesktopではLinuxの仮想マシンが間に入る構成もあります。だから、図はLinuxコンテナの基本を考える模型として使い、自分の環境の共有先と権限は実際の設定で確認しましょう。
箱の数より、箱から伸びる線を見る
この例では、共有する経路を作らない
図に描いた共有経路の比較です。カーネルやほかの権限も安全性に関わります。
実行する前に、共有先と利用者だけ確認する
Dockerをすでに使っていて、自分で管理する練習用コンテナがあるなら、まず下のinspectでMounts、User、Privilegedだけを表示します。CONTAINERは自分の練習用の名前へ置き換えてください。環境変数を丸ごと表示するより、確かめたい項目へ絞れます。
Mountsにはホスト側の共有先と読み書きの設定が出ます。Userが空なら、そこで分かるのは明示的な利用者指定がないこと。イメージの初期設定なども含めて読みます。Privilegedがfalseでも、それだけで安全とは決まりません。三項目は設定を読む入口であって、安全性の合格判定には使いません。
Dockerをまだ入れていない方は、図で「必要な共有先はどれか」を選ぶところまでで十分です。公式の手順を読む段階になったら、イメージの配布元、更新方法、ホストへ渡すものを確認。コマンドを動かす前に、箱の外とのつながりを説明できれば、一歩進んでいます。
docker inspect --format '{{json .Mounts}}' CONTAINER
docker inspect --format 'User={{.Config.User}} Privileged={{.HostConfig.Privileged}}' CONTAINER研究の補足と、よくある疑問
古いDocker研究の数字は、今の環境にも使える？
この記事では当時の脆弱性率や性能差を現在の全イメージへ当てはめていません。性能・設定・配布物という問いを研究から分け、現行の設定項目は公式資料で確認しています。[1][3][7]
ホストのDockerソケットを渡すと何が変わる？
コンテナ管理の操作口へ届く構成になり得ます。一般的な資料フォルダの共有と同じ感覚で追加せず、必要性と権限を公式のセキュリティ資料で確認してください。[7]
出典と確認した範囲（8資料）
出典と、読み取れる範囲
原著の公開要旨・取得できた本文部分・研究レビューと、仕様を確認する公式資料を照合しています。対象と比較条件が違う結果を一つの効果へ合算せず、手元の操作例は編集上の説明例として区別します。確認範囲は資料ごとに示しています。
対象・方法：仮想マシンとLinuxコンテナを複数の負荷で比較。
主な結果：抽象化・I/O等の条件による性能の違いを測定。
限界：2015年当時の構成。性能と隔離の安全性は別の評価。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
- [2]Combe, T., Martin, A., & Di Pietro, R. (2016). To Docker or Not to Docker: A Security Perspective ↗
対象・方法：Dockerと周辺のセキュリティ機構の研究整理。
主な結果：軽量な隔離と、安全な使い方を考える論点を整理。
限界：当時の技術のレビュー。現行のrootless等の全設定は公式資料で補足する。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：Docker Hubのイメージに含まれる脆弱性の調査。
主な結果：配布されたイメージの中にも脆弱な依存ソフトウェアがあり得ることを扱う。
限界：当時のHubのスナップショット。現在の任意のイメージの脆弱性率ではない。
確認した範囲
Sciteの書誌・抄録の取得部分を照合。原著全文の精読や統計の再計算は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：Docker内部とLinuxのSELinux・AppArmor等との関係を分析。
主な結果：コンテナ単独でなくホスト側の機構・設定と組み合わせた安全性を検討。
限界：未査読arXiv版。当時の仕様で、現行Dockerの全設定の手引きではない。
確認した範囲
原著の公開要旨を確認。本文全体の精読・実験の追試は未実施。 確認日：2026-10-29
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：Linuxコンテナの脅威、脆弱性、隔離・防御機構を整理する総説。
主な結果：Linuxのセキュリティ機能・モジュール等を含めてコンテナの守りを整理。
限界：2019年の総説。現行の全製品設定やrootlessの効果測定ではない。
確認した範囲
Sciteの書誌・本文抜粋（保護機構と調査対象の節）を確認。全文精読・追試は未実施。 確認日：2026-10-30
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
- [6]Wist, K., Helsem, M., & Gligoroski, D. (2020). Vulnerability Analysis of 2500 Docker Hub Images ↗
対象・方法：2020年のDocker Hubイメージ2,500件をスキャンした観察・分析。
主な結果：取得標本ではpull数・star数等と脆弱性数に相関を見いださなかった。
限界：当時の標本・スキャナー・既知脆弱性による評価。実際の侵入件数や2026年の全イメージの率へ換算しない。
確認した範囲
arXiv v3の公開要旨・本文の対象と結果部分、Sciteの書誌を確認。2021年刊行版も索引にあるが別研究として数えず、版差の全面照合は未実施。 確認日：2026-10-30
取得できた書誌で撤回・懸念通知は確認されていません。出版社の履歴を網羅した監査ではありません。
対象・方法：現行Dockerのセキュリティ機構・権限に関する公開ドキュメント。
主な結果：カーネル、デーモン、権限など運用上の境界を説明。
限界：論文数に含めない。設定はOS・版・rootless等で異なる。
確認した範囲
2026-10-29に公式の公開説明を確認。全設定の再現ではない。 確認日：2026-10-29
公式仕様・操作資料。学術文献の撤回索引とは別に扱います。
対象・方法：Dockerデーモンとコンテナを非root利用者で動かすモードの公式仕様。
主な結果：rootlessとuserns-remapの違い、必要条件を説明。
限界：rootlessだけで全脆弱性を防ぐ保証ではない。導入可否はOS・設定に依存する。
確認した範囲
2026-10-30に公式のHow it worksと前提条件を確認。実機での切替は未実施。 確認日：2026-10-30
公式仕様・操作資料。学術文献の撤回索引とは別に扱います。
この記事は複数文献を照合した編集記事です。既存研究を照合し、結果と条件を紹介しています。研究が同じ参加者を含む可能性があるため、文献間の人数を足していません。本文の行動提案・未来のシナリオは編集上の整理です。
この記事から、次に気になる話へ。
動いたコードが、安全とは限らない。AIの「正解」をどう見抜く？
テストは緑。画面も動く。それでも、名前の一文字や利用者の違いで壊れることがあります。確かめる条件を一つ増やすと、「動いた」の先を調べられます。
「再起動したら直った」で終わっていい？原因に近づく、小さな障害テスト
動き出してほっとしたのに、翌日また止まった。そんなとき欲しいのは、次にも使える手掛かりです。大規模な障害研究から、一つだけ条件を変える調べ方を持ち帰ります。
AIにコマンドを聞ける時代に、Linuxを学ぶ意味は？
AIの「直りました」を、どこまで信じてよいのでしょう。操作を任せる時代に何を学ぶか。研究と権限の具体例から、暗記の先にあるLinuxの使い方を考えます。