Options de confinement MXC et prise en charge des plateformes

MXC vous aide à gérer la complexité de l’utilisation de conteneurs : vous utilisez MXC pour décrire une stratégie et gérer le cycle de vie d’un conteneur, mais le back-end de confinement sélectionné effectue l’application réelle. Chaque back-end est basé sur un mécanisme de système d’exploitation différent. Par conséquent, les back-ends diffèrent de la façon dont ils isolent une charge de travail et de la façon dont ils gèrent les fichiers, la mise en réseau, l’interface utilisateur et le cycle de vie.

Commencez à partir de ce dont votre charge de travail a besoin, puis vérifiez qu’un back-end peut le fournir sur les hôtes que vous ciblez. Le nom ou la version du système d’exploitation ne vous indique pas si un back-end est pris en charge.

Comprendre les environnements d’hôte et de charges de travail

Dans une demande, vous pouvez demander un type d’environnement, appelé intention d’encapsulation, ou vous pouvez nommer un back-end spécifique. L’intent process est mappé au back-end natif d’isolation de processus sur l’hôte sur lequel vous l’exécutez. Étant donné que ce backend diffère selon le système d’exploitation, la même intention peut vous donner différentes fonctionnalités sur Windows, Linux et macOS.

Host Processus backend par défaut Autres environnements
Windows ProcessContainer Une session Windows distincte, une machine virtuelle Windows ou des charges de travail Linux via WSLc, lorsque pris en charge
Linux Bubblewrap LXC et backends de virtualisation spécialisés, lorsqu’ils sont pris en charge
macOS Ceinture de sécurité Vérifier la publication que vous installez pour connaître les autres options prises en charge

La charge de travail n’a pas besoin d’être exécutée sur le même système d’exploitation que l’hôte. Par exemple, WSLc exécute une charge de travail Linux sur un hôte Windows. Il a ses propres dépendances et partage des ressources avec l’hôte différemment d’un bac à sable de processus sous Windows.

Vérifier le statut de publication et la couverture du SDK

La prise en charge du backend change d’une version à l’autre, alors vérifiez les informations de prise en charge de la version du package que vous installez.

Dans MXC v1.0.0, les kits SDK V1 peuvent créer des conteneurs avec ces back-ends :

  • Windows : ProcessContainer, IsolationSession et WSLc
  • Linux : Bubblewrap et LXC
  • macOS: Seatbelt

Windows sandbox, MicroVM et Hyperlight sont expérimentaux. Ils nécessitent une autorisation expérimentale explicite et vous ne pouvez pas les créer via les API du KIT de développement logiciel (SDK) V1. Si vous envisagez l’un de ces environnements ou un autre environnement spécialisé, consultez d’abord les notes de publication de votre version.

Un back-end disponible sur l’hôte peut toujours ne pas prendre en charge la fonction du SDK que vous prévoyez d’appeler. Dans les kits SDK V1 :

  • Les API de cycle de vie fonctionnent uniquement avec IsolationSession et WSLc.
  • L’exécution PTY one shot fonctionne avec IsolationSession, Bubblewrap, LXC et Seatbelt.
  • L’exécution PTY dans un conteneur existant fonctionne uniquement avec IsolationSession.

Pour plus d’informations, consultez les références du SDK:

Si vous utilisez Rust, la prise en charge du back-end dépend également des fonctionnalités crate que vous activez. Pour utiliser IsolationSession ou WSLc, activez la fonctionnalité wslc ou mxc-sdk de la crate isolation_session. Pour plus d’informations, consultez le guide du Kit de développement logiciel (SDK) Rust.

Démarrer avec la découverte du runtime

Chaque Kit de développement logiciel (SDK) peut vous indiquer ce que prend en charge l’hôte actuel avant de lancer quoi que ce soit. Exécutez d’abord ces vérifications, mais conservez également la gestion des erreurs de lancement, car la configuration de l’hôte peut changer entre la vérification et le lancement.

Utilisez la prise en charge de la plateforme pour savoir si vous pouvez lancer des conteneurs tout court, les back-ends disponibles pour une vue plus large de l’hôte et la sonde pour tester une demande spécifique sur Windows avant de l’exécuter.

SDK API de découverte Que vérifier
.NET MxcPlatform.GetPlatformSupport() IsSupported, Reason, et AvailableMethods, qui répertorient les back-ends que le SDK peut lancer
.NET MxcPlatform.GetAvailableBackends() Disponibilité de l’hôte, fonctionnalités facultatives et avertissements. Certaines API d’exécution ne peuvent pas utiliser chaque back-end répertorié ici.
.NET MxcContainer.Probe() Sous Windows, la demande recevrait le niveau d’isolation ProcessContainer ainsi que des diagnostics de compatibilité spécifiques à la demande, sans créer de conteneur
TypeScript getPlatformSupport() isSupported, reason, availableMethods et tous les champs d’avertissement et de capacités spécifiques à l’hôte
TypeScript getAvailableBackends() Disponibilité de l’hôte, fonctionnalités facultatives et avertissements. Certaines API d’exécution ne peuvent pas utiliser chaque back-end répertorié ici.
TypeScript probe() Sous Windows, la demande recevrait le niveau d’isolation ProcessContainer ainsi que des diagnostics de compatibilité spécifiques à la demande, sans créer de conteneur
Rust v1::platform_support() is_supported, reason, available_methods, et, sur Linux, capacité réseau Bubblewrap
Rust v1::available_backends() Disponibilité de l’hôte, fonctionnalités facultatives et avertissements. Certaines API d’exécution ne peuvent pas utiliser chaque back-end répertorié ici.
Rust v1::probe() Sous Windows, la demande recevrait le niveau d’isolation ProcessContainer ainsi que des diagnostics de compatibilité spécifiques à la demande, sans créer de conteneur

Les champs qui ne s’appliquent pas ou qui ne peuvent pas être détectés peuvent être manquants dans les résultats. La découverte est une première vérification utile, mais elle ne valide pas toute votre politique. Pour être sûr, créez la requête que vous envisagez de lancer et vérifiez que le back-end sélectionné peut appliquer chaque contrôle requis.

Certains hôtes ont besoin de composants supplémentaires ou d’une configuration d’administrateur avant qu’un back-end fonctionne. Les résultats de découverte et les erreurs de lancement peuvent vous indiquer ce qui manque, mais cela ne donne pas à votre application ou à un agent de codage l’autorisation de modifier l’hôte. Demandez à l’administrateur de l’hôte de suivre les étapes de configuration documentées du back-end.

Pour Windows, consultez la prise en charge de la stratégie de version du système d’exploitation. Une version Windows peut être prise en charge par MXC et ne dispose toujours pas d’une fonctionnalité de stratégie particulière. Vérifiez donc ces deux éléments.

Vérifiez les restrictions requises pour votre charge de travail

Deux back-ends peuvent accepter la même syntaxe de stratégie et l’appliquer différemment. Avant de choisir un backend, tenez compte des aspects suivants :

Area Questions à poser
Fichiers Le back-end peut-il exprimer les autorisations de lecture, d’écriture et de refus dont vous avez besoin, y compris celles qui se chevauchent ? Partage-t-il des fichiers avec l’hôte, les monte-t-il ou les copie-t-il ?
Network Peut-il appliquer votre modèle réseau, qu’il soit direct ou via un proxy, y compris des règles de réseau privé et de bouclage d’hôte ?
Interface utilisateur Peut-il appliquer la fenêtre, le Presse-papiers et les restrictions d’entrée dont vous avez besoin ?
Lifecycle Exécute-t-il chaque commande indépendamment ou peut-il conserver l’environnement entre les commandes ? Qu’est-ce qui est conservé après un arrêt ?
Mode d’apprentissage L’hôte prend-il en charge la capture des refus ProcessContainer ? Si ce n’est pas le cas, quel workflow de diagnostic le back-end fournit-il ?

Les guides MXC sur GitHub répertorient les fonctionnalités prises en charge, les builds de système d’exploitation et les exigences pour chaque backend.

Choisir un back-end selon vos besoins

Avant de choisir un back-end, notez :

  • Les systèmes d’exploitation hôtes et les architectures de processeur que votre application prend en charge.
  • Environnement invité ou d’outil requis par la charge de travail.
  • La charge de travail nécessite un accès au fichier, au réseau, à l’interface utilisateur, au périphérique et à l’outil hôte.
  • Indique si chaque commande s’exécute seul ou a besoin d’un état à partir de commandes antérieures.
  • Vos limites en matière de temps de démarrage, de ressources, de déploiement et d’interaction utilisateur.
  • Niveau d’isolation requis pour la charge de travail et ses données.
  • Si le back-end peut appliquer chaque contrôle de stratégie dont vous avez besoin.

Testez ensuite chaque configuration de l’hôte que vous prenez en charge, avec des tests positifs et négatifs. Un lancement réussi indique uniquement que MXC a accepté la configuration. Les tests négatifs, tels qu’une tentative d’écriture en dehors des chemins accordés, indiquent si les restrictions sont réellement respectées.

Contenu connexe

  • Dernière mise à jour :