特権ホームサービスにおけるDockerとLXCのセキュリティ境界

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Docker vs LXC Security Boundaries for Privileged Home Services - Zima Store Online

特権が必要なホームサービスを、マウント範囲の狭い単一の宣言型アプリケーションとして運用できるなら、Dockerがより安全なデフォルトです。本当に小規模なLinuxシステムが必要ならLXCのほうがすっきりしますが、どちらも独立したカーネル境界を作るわけではありません。

決定的なのは、どちらのラベルがより分離されているように聞こえるかではありません。どちらもホストカーネルによる隔離に依存しています。実際に付与される権限、公開されるデバイスとファイル、パッチ適用や復元の単位、そして脱出が起きた場合の影響を比較してください。共有カーネルへの露出自体が許容できないなら、DockerとLXCの比較をやめ、VMまたは別のホストを使用してください。

機能を比較する前に共有カーネル境界を受け入れる

Dockerは通常、アプリケーションとその依存関係をパッケージ化します。一方、LXCはinit、アカウント、パッケージ、システムサービスを備えた、より完全なLinuxユーザー空間を提供します。この運用上の違いによって、LXCに独立したゲストカーネルが与えられるわけではありません。

Linuxコンテナの隔離に関する研究では、名前空間やポリシーの仕組みが継ぎはぎのように組み合わされており、その意味を監査するのが難しい場合があると説明されています。この共有カーネルによる隔離の限界は両方の候補に当てはまり、カーネル分離が必須の場合には、どちらも答えにはなりません。

両方を候補として残すのは、信頼できるワークロード、または影響範囲を限定できるワークロードに限ってください。インターネットに公開するコード、出所不明のイメージ、または影響の大きい自動化は、侵害されてもホストカーネルへ直接到達できないように、VMへ移してください。

必要な権限に応じてデフォルトを変える

サービスに必要なのが少数の明示的なケーパビリティ、読み取り専用の設定、1〜2個の永続パスである場合、Dockerは依然として魅力的です。Compose定義によって、レビュー時にこれらの例外を可視化できます。

従来型のLinuxシステム、複数のデーモン、パッケージマネージャー、または安定したシステムレベルのネットワークを必要とするサービスにはLXCが適しています。非特権LXCでは有用なUIDマッピングが維持されますが、特権モード、ネスト、広範なバインドマウントによって、その利点は損なわれます。

特権チェックボックスを確認するのではなく、例外の数を数えてください。いずれかの設計で、ホストネットワーク、コンテナ管理ソケット、書き込み可能なシステムマウント、すべてのデバイス、または制限のないプロファイルが必要になるなら、アクセス経路を再設計するか、共有カーネル層から離れてください。

デバイスとストレージへのアクセスが影響範囲を決める

USBコーディネーター、GPUレンダリングノード、UPSインターフェース、またはメディアディレクトリは、サービスに許される範囲で最小限に公開すべきです。安定したデバイスパス、読み取り専用マウント、明示的なUID/GID所有権は、利便性のための設定であると同時に、隔離のための制御でもあります。

最近のProxmox導入事例では、非特権LXCによって、Dockerを基盤とするサービスを個別の復元単位に分離しながら、ホストカーネルとストレージスタックを共有できることが示されています。この影響範囲を小さくするLXCパターンが有効なのは、ネストやストレージドライバーの例外が文書化されている場合に限られます。

1つのアプリに1つの小さなデータ境界が必要なら、Dockerを優先してください。複数のシステムサービスをまとめて扱うなら、LXCを優先してください。1つの侵害によって、バックアップ、ハイパーバイザーの制御、または関係のない家族のデータへの書き込みアクセスまで得られるなら、どちらの構成も採用しないでください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

パッチ適用と復元を行う単位を比較する

Dockerのロールバックは通常、以前のComposeリビジョンとイメージ、およびアプリケーション整合性のあるデータを復元することを意味します。LXCのロールバックではユーザー空間全体を復元できるため便利ですが、古いパッケージ、認証情報、隠れた手動変更まで復活させる可能性があります。

各候補を使い捨てのホスト上で再構築してください。Dockerでは定義、シークレット、ボリュームを復元し、LXCではコンテナを再作成または復元して、パッケージ、ネットワーク、デバイス、マウントの状態を確認します。アイドル時のメモリ使用量が少ないことよりも、成功した復元テストのほうが強い証拠になります。

VM、LXC、Dockerのサービス境界に関する、より広範なZimaSpaceの判断については、独立したカーネルが引き続き候補に残る場合の次のステップを確認してください。