Enhanced Container Isolation (強化されたコンテナー分離)

コンテナー内で実行されている悪意のあるワークロードが Docker Desktop やホストを侵害するのを防ぐための追加のセキュリティ層を提供します。

Enhanced Container Isolation (強化されたコンテナー分離) は、コンテナー内で実行されている悪意のあるワークロードが Docker Desktop やホストを侵害するのを防ぐための追加のセキュリティ層を提供します。

開発者の生産性に影響を与えることなく、さまざまな高度な技術を使用してコンテナーの分離を強化します。Docker Desktop 4.13.0 以降で利用できます。

技術的な特徴

これらのテクニックには次のようなものがあります。

  • --privileged フラグを指定して起動されたコンテナも含め、Linux ユーザー名前空間を通じてすべてのコンテナを特権なしで実行します。これにより、悪意のあるコンテナー ワークロードがコンテナを脱出して Docker Desktop VM とホストに感染することが困難になります。
  • Docker Desktop VM の不変性を確保します (例: コンテナーやユーザーが内部設定を変更できないなど)。
  • コンテナーのエスケープを防ぐためにいくつかの重要なシステム コールを精査し、さらに分離するためにコンテナー内の /proc と /sys の一部を部分的に仮想化します。
  • Docker Desktop VM へのユーザー コンソール アクセスを防止します。

Enhanced Container Isolation が有効になっている場合、これらのメカニズムは自動的に適用され、開発者への機能やパフォーマンスへの影響は最小限に抑えられます。開発者は通常どおり Docker Desktop を使用し続けますが、開発者が起動するコンテナーはより強力に分離されます。

Enhanced Container Isolation により、より強力なコンテナ分離が保証され、IT 管理者が作成したセキュリティ構成 (たとえば、Registry Access Management ポリシーや Settings Management) がロックインされます。

このような方にお勧め

  • コンテナー攻撃を防止し、開発環境の脆弱性を軽減したい組織や開発者
  • 開発者のマシンに簡単かつ直感的に実装できる、より強力なコンテナー分離を確保したい組織

Enhanced Container Isolation が有効になっている場合

有効になる機能

Enhanced Container Isolation をオンにすると、次の機能が有効になります。

  • すべてのユーザー コンテナーは Linux ユーザー名前空間で自動的に実行されるため、より強力な分離が保証されます。各コンテナーは専用の Linux ユーザー名前空間で実行されます。
  • コンテナー内の root ユーザーは、Docker Desktop Linux VM 内の非特権ユーザーにマップされます。
  • コンテナーが侵害されにくくなります。たとえば、機密性の高いシステム コールが精査され、 /proc と /sys の一部がエミュレートされます。
  • ユーザーは、ホスト ディレクトリ、ボリュームなどのバインド マウントを含め、通常どおりコンテナーを使用し続けることができます。
  • 開発者がコンテナーを実行する方法に変更はなく、特別なコンテナー イメージは必要ありません。
  • 特権付きコンテナー (--privileged フラグなど) は機能しますが、Docker Desktop VM ではなく、コンテナーの Linux ユーザー名前空間内でのみ特権が与えられます。したがって、これらを使用して Docker Desktop VM を侵害することはできません。
  • Docker-in-Docker や Kubernetes-in-Docker も動作しますが、Docker Desktop Linux VM 内では特権なしで実行されます。
課される制限

さらに、次の制限が課されます。

  • コンテナーは、Docker Desktop VM と名前空間を共有できなくなります (たとえば、--network=host, --pid=host は許可されません)。
  • コンテナーは、Docker Desktop VM 内の構成ファイルを変更できなくなります (たとえば、VM ディレクトリーをコンテナーにマウントすることは許可されません)。
  • コンテナーは Docker エンジンにアクセスできなくなります (たとえば、Docker エンジンのソケットをコンテナにマウントすることが制限されます)。これにより、悪意のあるコンテナーが Docker エンジンを制御するのを防ぎます。
  • Docker Desktop VM へのコンソール アクセスは、すべてのユーザーに対して禁止されます。

これらの機能と制限により、開発者のエクスペリエンスと生産性への影響を最小限に抑えながら、実行時のコンテナーのセキュリティが強化されます。

Enhanced Container Isolation の仕組みの詳細については、「How does it work (機能の仕組み)」を参照してください。

サポートされているホスト OS/プラットフォーム

Enhanced Container Isolation (ECI) は、すべてのプラットフォーム (Windows、Mac、Linux) 向けに Docker Desktop 4.13 で導入されました。

Windows ホストの場合、ECI は次のように Docker Desktop Hyper-V と WSL 2 バックエンドの両方で動作します。

  • Docker Desktop 4.19 以前: ECI は Hyper-V でのみ動作します。
  • Docker Desktop 4.20 以降: ECI は Hyper-V と WSL 2 (WSL バージョン 1.1.3.0 以降) の両方で動作します。

詳細および WSL 2 で Enhanced Container Isolation を使用する場合のセキュリティ上の注意事項については、「ECI Support for WSL」を参照してください。

Enhanced Container Isolation を有効にするには

開発者として

開発者として Enhanced Container Isolation を有効にするには:

  1. 所属している組織で Docker Business サブスクリプションが有効であることを確認してください。
  2. Docker Desktop で組織にログインします。これにより、Docker Desktop の [設定] メニューで ECI 機能を利用できるようになります。
  3. 既存のコンテナーをすべて停止して削除します。
  4. Docker Desktop で Settings > General に移動します。
  5. Use Enhanced Container Isolation の横にあるチェックボックスを選択します。
  6. Apply and restart を選択して設定を保存します。
管理者として

管理者として Enhanced Container Isolation を有効にするには、まずサインインを強制するように registry.json ファイルを構成する必要があります。これは、Enhanced Container Isolation 機能には Docker Business サブスクリプションが必要なため、この構成を有効にするには Docker Desktop ユーザーが組織に対して認証される必要があるためです。

次に、admin-settings.json ファイルを作成して構成し、以下を指定する必要があります。

{
 "configurationFileVersion": 2,
 "enhancedContainerIsolation": {
    "value": true,
    "locked": true
    }
}

"value": true を設定することで、管理者は ECI がデフォルトで有効になるようにします。"locked": true を設定することで、管理者は開発者が ECI を無効にできないようにします。開発者がこの機能を無効にできるようにしたい場合は、"locked": false を設定します。

これを有効にするには:

  • 新規インストールでは、開発者は Docker Desktop を起動し、組織に対して認証する必要があります。
  • 既存のインストールでは、開発者は Docker メニューから Docker Desktop を終了し、Docker Desktop を再起動する必要があります。すでにサインインしている場合、変更を有効にするために再度サインインする必要はありません。

設定の適用後の表示

Enhanced Container Isolation が有効になっている場合、ユーザーには次が表示されます。

  • Settings > General で、Use Enhanced Container Isolation がオンに切り替わります。
  • コンテナーは Linux ユーザー名前空間内で実行されます。

確認するには、次を実行します。

$ docker run --rm alpine cat /proc/self/uid_map

次の出力が表示されます。

         0     100000      65536

これは、コンテナーの root ユーザー (0) が Docker Desktop VM の非特権ユーザー (100000) にマップされていること、およびマッピングが 64K のユーザー ID の範囲に拡張されていることを示します。コンテナー プロセスがコンテナーからエスケープすると、VM レベルでの権限がなくなってしまいます。各コンテナは分離のためにホスト ユーザー ID の排他的な範囲を取得するため、ユーザー ID マッピングは新しいコンテナごとに異なります。ユーザー ID マッピングは Docker Desktop によって自動的に管理されます。詳細については、「How Enhanced Container Isolation works (拡張コンテナ分離の仕組み)」を参照してください。

対照的に、ECI を使用しない場合、Linux ユーザー名前空間はコンテナーに使用されず、次のように表示されます。

         0          0 4294967295

これは、コンテナー (0) の root ユーザーが実際には Docker Desktop VM (0) の root ユーザーであることを意味し、コンテナーの分離が軽減されます。

Enhanced Container Isolation では、Docker Desktop Linux VM に埋め込まれた Sysbox コンテナー ランタイムが使用されるため、コンテナーが Enhanced Container Isolation で実行されているかどうかを確認するには、 docker inspect を使用します。

docker inspect --format='{{.HostConfig.Runtime}}' my_container

出力は次のとおりです。

sysbox-runc

Enhanced Container Isolation を使用しない場合、docker inspect は標準の OCI ランタイムである runc を出力します。