Dockerに入力フォルダを渡す：書き込める範囲を決めてからマウントする
入力を読むだけのコンテナには、入力フォルダへの書込み権限を渡しません。bind mountは既定でホスト側へ書き込めるため、読取り専用の入力と書込み可能な成果の保存先を分けます。保存されることと、原本を変更できないことは別の判断です。
公式資料確認日：。
原本を読む場所と、成果を書く場所を分ける
bind mountはホストのファイルやディレクトリをコンテナへ見せます。書込み可能なら、コンテナ内の処理がホスト側のファイルを変更・削除することもできます。入力はreadonlyまたはro、成果は必要な別の保存先という境界を、起動前に表へ書きます。読取り専用でも内容は読めるため、不要な秘密を含むフォルダは渡しません。
見えているパスを四つの列で照合する
同じ名前のフォルダでも、接続先が違えば別のデータです。遠隔のDockerへ接続している場合、bind mountの元は手元のPCではなくDockerを実行するホスト側です。Docker Desktopは仮想マシンを介してホストのパスを共有するため、画面のパス表記だけで配置を決めません。
| ホスト側の対象 | コンテナ内の場所 | 必要な操作 | 渡す条件 |
|---|---|---|---|
| 入力の原本 | 処理が読むパス | 読むだけ | readonly／roと対象範囲を照合 |
| 生成した成果 | 成果を書き出すパス | 書込みが必要 | 原本と別の保存先へ限定 |
| 一時ファイル | 処理中の作業場所 | 必要な範囲の読書き | 原本のフォルダを作業場所にしない |
| 入れ子のmount | 親フォルダの下にある別mount | 用途ごとに決める | 親が読取り専用という理由だけで判断しない |
親フォルダのroだけで、入れ子まで保護されたと決めない
公式仕様では、入れ子のmountを再帰的に読取り専用にするにはLinux kernel 5.12以上が必要です。旧kernelでは入れ子が読書き可能になる場合があり、bind-recursive=readonlyを指定するとエラーになります。入れ子を含める必要がないなら、対象を小さく分ける案も比較します。kernelやmountの構造が不明なら、原本を使った本番処理へ進みません。
権限の確認は、使い捨ての入力コピーで行う
受入手順として、非機密の入力コピーと別の成果先を使い、原本を読む工程・成果を保存する工程を分けます。docker inspectのMountsで対象とRWの値を照合し、必要な工程が成立するかを試験用の構成で確認します。これは確認手順の提案で、Selparoが実機で試した結果ではありません。Docker Swarmなど別の運用形態へ、そのまま同じ挙動を当てはめません。
読取り専用はバックアップや完全な隔離の代わりにしない
入力を変更できない構成でも、別の書込み先、実行ユーザー、接続先への権限は残ります。失われた成果の復元はバックアップ側の仕事です。新しいSSDやVPSを買う前に、入力と成果の境界を現在の構成で整理します。容量不足が原因でない限り、機器を追加しても原本の誤更新対策にはなりません。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- Docker公式：bind mountの書込み権限・入れ子・接続先
bind mountは既定でホスト側へ書き込めます。readonly／roの範囲、実行側ホストのパス、入れ子のmountを照合します。再帰的な読取り専用にはLinux kernel 5.12以上が必要で、旧kernelの入れ子は読書き可能になる場合があります。