目次
Dockerを操作するために、Webアプリやのコンテナへ/var/run/docker.sockを渡していませんか。このソケットはログを読むための普通のファイルではなく、コンテナを作成・変更するDockerデーモンへの操作経路です。アプリを非rootで動かしていても、デーモンへ命令できる権限が残れば、想定した隔離を崩すおそれがあります。
本記事は2026年10月27日に確認したDocker公式資料に基づく恒久対策の解説です。特定の新規脆弱性や侵害事件の速報ではありません。Linux上のDocker Engineを主な対象とし、管理用接続の棚卸し、不要なソケット共有の撤去、経由の接続確認を順に示します。コードは構成例で、ここで本番環境へ適用して検証したものではありません。
スポンサーリンク
アプリの実行権限とデーモンの権限を分ける
Docker公式のEngineセキュリティ資料は、Rootless modeを選ばないデーモンがroot権限を必要とすることと、操作を信頼するユーザーに限定すべきことを説明しています。ホストのディレクトリをコンテナへ共有できる機能は便利ですが、デーモンを操作できる人へ強い権限を与える理由にもなります。
例えばWebアプリが侵害されたとき、アプリのデータ領域だけを書ける構成と、Dockerへ新しいコンテナの作成を要求できる構成では、到達できる範囲が異なります。後者では、アプリ自体のUSERや読み取り専用ルートファイルシステムだけを確認しても、ホスト側の操作経路を説明できません。
まず、どのプロセスがどのデーモンへ命令できるかを一覧にします。開発者の端末、本番の配備ジョブ、監視ツール、処理、管理画面など、利用者向けWebアプリ以外も対象です。ソケットを共有している事実だけで侵害を断定せず、その利用者を管理者相当として信頼できるかを判断します。
ソケット共有と遠隔待ち受けを棚卸しする
Composeファイルや起動スクリプトからdocker.sockのマウントを探し、実行中のコンテナのMountsと照合します。設定のoverrideやCIの共通テンプレートで追加されていないかも確認してください。環境によってソケットの場所が異なるため、/var/run/docker.sockという文字列が見つからないだけで操作経路なしとは判断できません。
同時にデーモンの起動引数とサービス設定を調べ、Unixソケット、SSH、TCPのどの経路を受け付けるかを確認します。2375や2376というポート番号だけで安全性を判断せず、待ち受けアドレス、認証方式、到達できる送信元を一組で記録します。設定ファイルと実際の待ち受け状態が一致していることが必要です。
Docker公式資料は、ホスト間ので制限しても、コンテナからへ到達できる場合があると注意しています。外部ネットワークからのスキャン結果だけでは調査が足りません。管理ネットワーク、アプリ用ネットワーク、同じホストのプロセスからの到達性を、それぞれ管理下の環境で確認します。
スポンサーリンク
不要な共有は使う処理を分けて撤去する
利用者から要求を受けるWebアプリへ、ホストのコンテナ管理を直接任せる必要があるかを見直します。単に処理結果を得たいだけなら、専用サービスへ限定した要求を渡す設計にできないかを検討します。Docker API全体の操作権限を渡すことと、一つの業務処理を依頼することを同じ権限として扱わないことが重要です。
CIでイメージをする場合も、信頼していない変更を実行するジョブと、本番へ配備するジョブの責任を分けます。外部のプルリクエストのコードを動かす処理へ本番デーモンの接続情報を渡さない設計を本サイトは勧めます。資格情報をへ移しただけでは、同じジョブから読み取れる限り境界は変わりません。
共有を撤去する前に、誰がどの操作へ依存しているかを確認します。監視がコンテナ一覧を取得できなくなる、配備が再作成に失敗するなど、業務上の影響を整理して代替経路を用意します。障害が起きたため全サービスへソケットを再配布するのではなく、必要な管理処理を担当する実行主体だけへ戻します。
SSHで遠隔管理する場合の構成例
Docker公式のデーモンソケット保護資料は、UnixソケットのほかにSSHやで接続する方式を説明しています。管理端末からSSH接続できる環境では、Docker用のTCP待ち受けを追加せずに遠隔エンジンへ接続する選択肢があります。
次は管理下のホストengine.example.comへ、専用ユーザーdeployで接続する仮想例です。ユーザーには遠隔ホストのDockerソケットへのアクセス権が必要です。SSHでログインできることとDockerを操作できることは別の条件なので、権限エラーを解消するため全ユーザーへソケット権限を広げないでください。
docker context create production-engine \
--docker host=ssh://deploy@engine.example.com
docker --context production-engine infocontextを作成した後は、読み取り操作で接続先を確認します。表示されたエンジンが意図する本番ホストかを、管理台帳の情報と照合してください。名前がproduction-engineであることだけでは接続先の正しさを証明できません。同じ名前を端末ごとに別のホストへ設定できるためです。
SSHのホスト鍵確認や利用する鍵の管理は、既存の組織の手順に従います。接続エラーをなくすためにホスト鍵の検証を無効にしたり、本番のをイメージへ焼き込んだりしないでください。鍵の利用者、保管場所、退職・端末紛失時の停止方法を明確にしてから自動処理へ使います。
スポンサーリンク
接続先の切り替えを作業の一部として確認する
公式資料はdocker context useで既定の接続先を切り替える方法と、DOCKER_HOSTで一時的に接続先を指定する方法を示しています。便利な一方、作業者の端末に遠隔接続の状態が残ると、ローカルで試すつもりの変更を本番へ向ける事故につながります。
本サイトの提案は、変更を行うコマンドでは対象contextを明示し、その直前に読み取りで接続先を確認することです。共有端末やCIでは、起動時の環境変数とツール設定も調べます。シェルの初期化ファイルから意図しないDOCKER_HOSTが設定されていないかを確認し、調査結果へ秘密鍵の内容を出力しないようにします。
docker context ls
docker --context production-engine info
# ローカルの既定contextへ戻す場合
docker context use default最後のコマンドは既定contextを切り替える例であり、他の環境変数や個別コマンドの指定まで消すものではありません。手順書には、作業対象を選ぶ操作と、操作がその対象へ届いたことを確認する操作を並べます。単に画面へ成功と出たことだけで、正しいホストを管理したと判断しないでください。
TLSは暗号化と相互認証を区別する
経由の管理が必要な場合、Docker公式はTLSとによる保護を説明しています。tlsverifyを使う構成では、デーモンは信頼するが署名した証明書を持つクライアントを受け入れ、クライアント側もサーバー証明書を確認します。TLSを有効にするだけのモードと、クライアントまで行うモードを混同しないでください。
証明書の生成コマンドをそのまま並べて終わりにはできません。接続先の名やと証明書の対応、秘密鍵の権限、更新期限、CAの保護、配布経路を含めた運用が必要です。の接続に成功したことと、許可されていないクライアントを拒否できることを別々に試験します。
公式資料は、クライアント鍵の所有者がデーモンへ強い操作を指示できるため、rootパスワードと同じように鍵を保護するよう注意しています。鍵を複数のジョブや担当者で使い回すと、利用停止の影響範囲も広がります。資格情報の単位を決める際は、漏えい時にどの処理を停止する必要があるかも考慮します。
相互TLSは接続する相手の認証であって、各API操作の細かなを自動で完成させるものではありません。必要なら公式資料が示す認可プラグインなどの仕組みを別途検討します。導入時には許可する操作と拒否する操作を定義し、名前だけで読み取り専用の管理者になったと判断しないでください。
Rootless modeで変わる範囲と残る責任
Docker公式のRootless mode資料は、デーモンとコンテナを非rootユーザーで動かし、デーモンやの問題による影響を緩和する方式を説明しています。アプリのDockerfileにUSERを指定することとは異なります。
導入にはnewuidmapとnewgidmap、従属UID・GIDの割り当てなどの前提があります。既存のデーモンと併存する場合は、どちらへ接続しているかも確認しなければなりません。rootless用のcontextを作っただけで、既存のroot権限のデーモンが停止したとは限りません。
Rootless modeでも、そのユーザーが管理するコンテナやデータの操作権限は重要です。秘密情報やアプリデータへの到達を無制限に許可してよい理由にはなりません。既存構成から移行する場合は、ストレージとネットワーク、起動方式、バックアップを含む検証計画を別途用意します。
許可側と拒否側を対で試験する
変更後の検証は管理下の環境で行い、正規の管理端末から読み取り操作が成功することを確認します。次に、資格情報を持たない試験用の実行主体から管理経路へ接続できないことを確認します。許可した端末だけで成功した結果は、無許可の相手を拒否できる証明にはなりません。
ソケット共有を撤去したアプリでは、通常の業務機能が継続し、不要になったDocker操作が実行できないことを確かめます。管理専用のジョブでは、対象ホストを明示し、必要な配備と復旧だけを実行できる運用になっているかを確認します。確認のために本番コンテナを無断で削除するような試験は不要です。
鍵を交換した場合は、新しい鍵で接続できることに加え、廃止した接続経路が残らないことを確認します。SSHとTLSでは利用停止の方法が異なるため、単にローカルの鍵ファイルを削除しただけで遠隔側の許可も消えたと扱わないでください。接続試験の結果には対象と日時を残します。
スポンサーリンク
露出が見つかった場合は接続制限と侵害調査を分ける
意図しないソケット共有や管理APIの露出を発見した場合、まず通常の管理経路を確保したうえで不要な到達経路を閉じます。続いて、その状態がいつから存在し、どの実行主体が到達できたかを調べます。公開されていた事実だけで侵害を断定せず、閉じたことだけで過去の影響が消えたとも判断しません。
本サイトは、実行中・停止中のコンテナ、イメージ、マウント、管理資格情報の変更を調査対象として整理することを勧めます。再作成やクリーンアップの前に必要な記録を保全し、不明なコンテナがないという一項目だけで調査を終えないでください。アプリのへ到達できた可能性があるなら、その資格情報の見直しも必要です。
平時の完了条件は、ソケットを共有していないことだけではありません。誰がどのデーモンを操作できるか、管理接続がどこから届くか、鍵を停止する方法、許可と拒否の確認結果を説明できる状態です。コンテナの実行制限とデーモンの管理権限を別々に点検することで、設定上の隔離と実際の操作範囲のずれを減らせます。
関連記事
Webアプリのコンテナを非rootで動かす設定と書き込み先の設計は、アプリ内部の権限と保存先の制限を扱います。本稿のデーモン接続の管理と併せて確認してください。
スポンサーリンク
