バインドマウントはホームサーバー上のコンテナのセキュリティにどのような影響を与えるのか？

バインドマウントはコンテナ内のプロセスにホームサーバー上の実際のパスへの直接アクセスを与えることでコンテナのセキュリティを変えます。そのアクセスは使い捨てのコンテナファイルシステム境界の一部を迂回し、ホストのファイル、所有権ルール、ラベル、マウントオプションをコンテナのセキュリティモデルの一部にします。

マウントが自動的に危険というわけではありません。リスクはどのホストパスが公開されているか、コンテナが書き込み可能か、プロセスがどのユーザーで実行されているか、Dockerソケット、設定ディレクトリ、バックアップフォルダなどの機密パスが含まれているかによります。

バインドマウントはどの境界を越えるのですか？

コンテナは通常、自身のレイヤードファイルシステムと選択された管理ボリュームを見ます。バインドマウントは実際のホストパスを公開するため、そのパスを通じて作成または変更されたファイルはホストファイルシステムの変更となります。

コンテナは依然として名前空間とホストカーネルを使用しますが、マウントされたディレクトリはもはやイメージの書き込み可能レイヤーの背後に隔離されていません。アプリケーションはホストのサービス、バックアップツール、他のコンテナが使用するのと同じファイルとやり取りできます。

これによりセキュリティの問題は「イメージの中に何があるか」だけでなく「このプロセスがどのホストオブジェクトにアクセスできるか」に変わります。小さなメディアディレクトリとサーバールートファイルシステムでは、コンテナイメージが同じでも露出度は大きく異なります。

なぜ書き込みアクセスは被害範囲を拡大するのですか？

バインドマウントは通常、特に設定されていない限り書き込み可能です。書き込み可能なマウントはコンテナプロセスが利用可能な権限を使ってホストのファイルを変更できることを意味します。

侵害されたメディアサーバーは、マウントされたライブラリを暗号化したり、設定を変更したり、スクリプトを置き換えたり、コンテナの削除後も残るファイルを削除したりする可能性があります。被害はデータがコンテナ層の外に存在するため持続します。

スナップショットやバックアップは依然として役立ちますが、健全な以前の状態を含んでいる必要があります。スナップショットは既に破損していたデータを保存することがありますので、マウント設計はバージョン履歴が必要になる前に被害を制限すべきです。

読み取り専用マウントはどのようにリスクを軽減するのですか？

読み取り専用のバインドマウントはホストの可視性を保ちつつ、そのマウントを通じた通常の書き込みをブロックします。設定、メディア入力、証明書、参照データには、読み取り専用マウントはファイルシステムの変更を制限しつつ、アプリケーションが必要とするファイルを隠しません。

読み取り専用は被害範囲を大幅に減らしますが、完全な隔離ではありません。マウントされたパスが広すぎると、コンテナは依然として秘密情報、個人ファイル、メタデータ、認証情報を読み取る可能性があります。

アプリケーションはデータベース、アップロード、キャッシュ、ログのために明示的な書き込み可能な場所も必要です。書き込み可能な狭いディレクトリだけをマウントする方が、アプリケーション全体のツリーやユーザーホームディレクトリを露出させるより安全です。

なぜUID、GID、ラベルが依然重要なのか？

バインドマウントはホストファイルシステムの所有権とアクセスルールを保持します。コンテナプロセスは抽象的なボリューム権限を得るわけではなく、ボリュームマウントは正しいラベルとアクセスルールがないとホスト情報を漏らすことがあります。

コンテナのルートがホストのルートに直接マッピングされている場合、書き込み可能なパスは特に危険です。アプリケーションを非root UIDで実行するとアクセスが狭まりますが、UIDとGIDの不一致はユーザーが過度に広いchmod設定で「解決」してしまう権限エラーを生むこともあります。

SELinuxや他の強制アクセス制御システムは、Unixのモードビットに加えて第二の判断を加えます。正しいラベルは数値所有権がアクセスを許可しているように見えてもコンテナを制限できますが、ラベリングを無効にするとその保護が失われます。

なぜ一部のホストパスはより危険なのか？

リスクはファイル数だけでなく権限によって決まります。Dockerソケットのマウントはデーモン制御を露出させ、侵害されたコンテナが特権コンテナを作成したり追加のホストパスをマウントしたりすることを可能にします。

サーバールート、`/etc`、SSHキー、パッケージ設定、アプリケーションの秘密情報をマウントすると、1つのコンテナ侵害がホスト全体へのアクセスに拡大する可能性があります。実行可能なスクリプトを含むマウントは、別のホストプロセスがそれらのファイルを実行すると永続化経路になることもあります。

通常のデータパスでも依然として機密性が高い場合があります。家族の写真、パスワードマネージャーのエクスポート、税務記録、バックアップは、攻撃者がコンテナから脱出する助けにはならないかもしれませんが、不正な読み取りや削除は重大なセキュリティ違反です。

ホームサーバーの設計でバインドマウントはどう扱うべきか？

アプリケーションを満たす最小のホストディレクトリから始めてください。マウント名前空間はファイルシステムのビューを分離し、各バインドマウントはそのビューに対する意図的な例外として扱うべきです。

入力には読み取り専用アクセスを優先し、コンテナは専用の非rootユーザーとして実行し、機密情報は広範なデータマウントの外に保持し、アプリケーションが本当に必要としない限りソケットやシステムディレクトリは避けてください。

シンボリックリンク、権限、ラベルが適用された後の実際のパスを確認してください。安全な設計は、1つのコンテナの削除や侵害がその狭いデータ境界のみに影響し、独立したバックアップが別の復旧境界を保持することを目指します。

よくある質問

バインドマウントはDockerボリュームよりも安全性が低いですか？

自動的にはなりません。バインドマウントは選択されたホストパスを直接公開しますが、管理されたボリュームはより抽象化されています。セキュリティはパスの範囲、書き込みアクセス、プロセスの識別、ラベルに依存します。

読み取り専用にすると機密マウントは安全になりますか？

そのマウントを通じた通常の変更は防ぎますが、コンテナはパスが公開するすべてを読み取ることができます。機密情報やプライベートファイルは必要な場合を除きマウントすべきではありません。

非rootコンテナはバインドマウントされたファイルを損傷できますか？

はい、UIDやグループがホストパスに書き込み権限を持つ場合です。非rootは権限を減らしますが、実際の所有権やアクセスルールを上書きするわけではありません。

なぜDockerソケットのマウントは危険なのですか？

ソケットはDockerデーモンを制御します。アクセスが許可されると、コンテナは特権付きワークロードの起動、機密情報の検査、追加のホストディレクトリのマウントが可能になります。

最終的なまとめ

バインドマウントは、コンテナのファイルシステム境界を意図的に貫通する穴です。そのセキュリティは、ホストパスによって公開される機能に依存します：読み取り専用データ、書き込み可能なアプリケーション状態、機密情報、または管理権限。狭いパス、読み取り専用のデフォルト設定、非rootユーザー、正しいラベル付け、独立したバックアップにより、1つのコンテナがホームサーバー全体の障害になるのを防ぎます。