MXC のコンテインメント オプションと対応プラットフォーム

MXC を使用すると、コンテナーの運用に伴う複雑さを軽減できます。MXC でポリシーを定義し、コンテナーのライフサイクルを管理しますが、実際に制限を適用するのは、選択したコンテインメント バックエンドです。 各バックエンドは、異なるオペレーティング システム メカニズムに基づいて構築されています。 その結果、バックエンドはワークロードの分離方法と、ファイル、ネットワーク、UI、ライフサイクルの処理方法が異なります。

まずワークロードに必要なものを明確にし、対象のホストでバックエンドがそれらを提供できることを確認してください。 オペレーティング システムの名前またはバージョンだけでは、バックエンドがサポートされているかどうかは示されません。

ホスト環境とワークロード環境を理解する

要求では、コンテインメント インテントと呼ばれる環境の種類を指定するか、特定のバックエンドを直接指定できます。 processインテントは、実行しているホスト上のネイティブ プロセス分離バックエンドにマップされます。 使用されるバックエンドはオペレーティング システムによって異なるため、同じインテントを指定しても、Windows、Linux、macOS で利用できる機能が異なる場合があります。

ホスト 既定のプロセス バックエンド その他の環境
Windows ProcessContainer サポートされている場合は、独立した Windows セッション、Windows 仮想マシン (VM)、または WSLc 経由の Linux ワークロード
Linux Bubblewrap サポートされている場合は、LXC および専用の仮想化バックエンド
macOS シートベルト インストールするリリースでサポートされているその他のオプションを確認する

ワークロードは、ホストと同じオペレーティング システムで実行する必要はありません。 たとえば、WSLc は、Windows ホストで Linux ワークロードを実行します。 独自の前提条件があり、Windows プロセス サンドボックスとは異なる方法でホストとリソースを共有します。

リリースの状態と SDK の対象範囲を確認する

バックエンドのサポートはリリースごとに変更されるため、インストールするパッケージバージョンのサポート情報を確認してください。

MXC v1.0.0 では、V1 SDK は次のバックエンドでコンテナーを作成できます。

  • Windows: ProcessContainer、IsolationSession、および WSLc
  • Linux: Bubblewrap と LXC
  • macOS: Seatbelt

Windows Sandbox、MicroVM、Hyperlight は試験段階です。 これらを使用するには、実験的機能の使用を明示的に許可する必要があります。また、V1 SDK API を使用して作成することはできません。 これらの環境または別の特殊な環境のいずれかを検討している場合は、最初にバージョンの リリース ノート を確認してください。

ホストで使用できるバックエンドは、呼び出す予定の SDK 操作をまだサポートしていない可能性があります。 V1 SDK の場合:

  • ライフサイクル API は、IsolationSession と WSLc でのみ機能します。
  • ワンショット PTY の実行は、IsolationSession、Bubblewrap、LXC、Seatbelt で機能します。
  • 既存のコンテナーでの PTY の実行は、IsolationSession でのみ機能します。

詳細については、SDK のリファレンスを参照してください。

Rust を使用する場合、バックエンドのサポートは、有効にするクレート機能にも依存します。 IsolationSession または WSLc を使用するには、mxc-sdk クレートの isolation_session または wslc 機能を有効にしてください。 詳細については、 Rust SDK ガイドを参照してください。

ランタイム検出から開始する

起動する前に、各 SDK で現在のホストでサポートされている内容を確認できます。 最初にこれらのチェックを実行しますが、ホストの構成がチェックと起動の間で変更される可能性があるため、起動エラーも処理し続けます。

コンテナーを起動できるかどうかはプラットフォームのサポート情報で確認し、ホスト全体の対応状況は利用可能なバックエンドの情報で確認してください。また、Windows で特定の要求を実行する前に、プローブを使用してその要求をテストしてください。

SDK Discovery API 確認すべきこと
.NET MxcPlatform.GetPlatformSupport() IsSupported、Reason、および SDK で起動できるバックエンドを一覧表示する AvailableMethods
.NET MxcPlatform.GetAvailableBackends() ホストの可用性、オプションの機能、および警告。 一部の実行 API では、ここに記載されているすべてのバックエンドを使用することはできません。
.NET MxcContainer.Probe() Windows では、コンテナーを作成せずに、要求に適用される ProcessContainer の分離レベルと、その要求に固有の互換性診断情報を取得
TypeScript getPlatformSupport() isSupported、 reason、 availableMethods、ホスト固有の警告と機能フィールド
TypeScript getAvailableBackends() ホストの可用性、オプションの機能、および警告。 一部の実行 API では、ここに記載されているすべてのバックエンドを使用することはできません。
TypeScript probe() Windows では、コンテナーを作成せずに、要求に適用される ProcessContainer の分離レベルと、その要求に固有の互換性診断情報を取得
Rust v1::platform_support() is_supported、reason、available_methods、および Linux では Bubblewrap のネットワーク機能
Rust v1::available_backends() ホストの可用性、オプションの機能、および警告。 一部の実行 API では、ここに記載されているすべてのバックエンドを使用することはできません。
Rust v1::probe() Windows では、コンテナーを作成せずに、要求に適用される ProcessContainer の分離レベルと、その要求に固有の互換性診断情報を取得

適用されない、または検出できないフィールドは、結果に含まれない可能性があります。 Discovery は最初の確認としては有用ですが、ポリシー全体を検証するものではありません。 確実に、実行する予定の要求を作成し、選択したバックエンドが必要なすべてのコントロールを適用できることを確認します。

一部のホストでは、バックエンドが動作する前に追加のコンポーネントまたは管理者のセットアップが必要です。 検出結果と起動エラーは、不足している内容を示しますが、アプリやコーディング エージェントにホストを変更するアクセス許可を与えるわけではありません。 ホストの管理者に、バックエンドのドキュメントに記載されたセットアップ手順に従うよう依頼してください。

Windowsについては、OS バージョンポリシーのサポートを参照してください。 Windows バージョンは MXC でサポートされていても、特定のポリシー機能を欠いている場合があるため、MXC でのサポート状況と特定のポリシー機能の有無の両方を確認してください。

ワークロードに必要な制限を確認する

2 つのバックエンドが同じポリシー構文を受け付けても、制限の適用方法が異なる場合があります。 バックエンドを決める前に、次のような領域を検討してください。

Area 確認事項
Files バックエンドは、重複する許可を含め、必要な読み取り、書き込み、拒否の許可を表現できますか? ファイルはホストと共有されますか。それとも、マウントまたはコピーされますか。
Network プライベート ネットワークやホスト ループバックに関するルールを含め、直接接続とプロキシ経由の接続のどちらについても、必要なネットワーク モデルに従って制限を適用できますか。
UI 必要なウィンドウ、クリップボード、入力の制限を適用できますか?
Lifecycle 各コマンドは個別に実行されますか。それとも、コマンド間で環境を維持できますか? 停止後に何が保持されますか?
学習モード ホストは ProcessContainer の拒否イベントのキャプチャをサポートしていますか? そうでない場合、バックエンドはどのような診断ワークフローを提供しますか?

GitHub 上の MXC ガイドは、各バックエンドでサポートされている機能、OS ビルド、要件を一覧表示しています。

要件に基づいてバックエンドを選択する

バックエンドを選択する前に、次の内容を書き留めてください。

  • アプリがサポートするホスト オペレーティング システムとプロセッサ アーキテクチャ。
  • ワークロードに必要なゲスト環境またはツール環境。
  • ワークロードに必要なファイル、ネットワーク、UI、デバイス、ホスト ツールへのアクセス。
  • 各コマンドが単独で実行されるか、以前のコマンドの状態が必要か。
  • お客様の起動時間、リソース、デプロイ、ユーザー操作に関する制限。
  • ワークロードとそのデータに必要な分離境界の強度。
  • バックエンドで、必要なすべてのポリシー制御を適用できるかどうか。

次に、正と負の両方のテストを使用して、サポートするすべてのホスト構成をテストします。 立ち上げが成功しても、MXC が構成を受け入れたことを示すだけです。 負のテスト (許可されたパスの外部に書き込もうとするなど) は、制限が実際に有効に機能しているかどうかを示します。

関連するコンテンツ

  • 最終更新: