Architecture MXC et modèles de confinement

MXC sépare l’intention de la charge de travail du mécanisme de plateforme qui exécute la charge de travail. Votre application hôte utilise le kit de développement logiciel (SDK) .NET, TypeScript ou Rust pour décrire les autorisations de ressource et l’exécution de la demande. MXC traduit la requête en opérations que le backend de confinement exécute sur l’hôte actuel.

Cette conception offre aux applications une surface d’intégration cohérente sans prétendre que chaque back-end fournit les mêmes fonctionnalités ou propriétés d’isolation.

Couches d’architecture

Une intégration MXC comporte quatre couches principales :

Couche Responsabilité
Application hôte ou runtime de l’agent Classifie la tâche, sélectionne les valeurs par défaut de stratégie fiables, fournit des entrées et gère la sortie et l’approbation
SDK MXC et contrat de stratégie Détecte les fonctionnalités prises en charge, convertit l’intention relative à la charge de travail en une configuration versionnée, démarre les environnements de test isolés et expose les informations sur leur cycle de vie et les diagnostics
Couche d’exécution MXC Valide la configuration, résout un back-end et traduit le contrat pris en charge en opérations de plateforme
Backend de confinement Crée l’environnement d’exécution et applique les fonctionnalités de stratégie prises en charge par la plateforme et le backend

L’application hôte reste responsable des décisions relatives à la stratégie. Un agent de codage peut suggérer un modèle ou une allocation de ressources, mais il ne doit pas choisir ou étendre sa propre autorité sans logique fiable ou approbation humaine. Le code que l’hôte exécute en dehors de MXC reste en dehors du confinement de la charge de travail.

Stratégie, configuration et paramètres d’exécution

La politique décrit ce à quoi la charge de travail peut accéder. La demande d’exécution ajoute ce qu’il faut exécuter, où l’exécuter et quel confinement utiliser. Les paramètres d’exécution fournissent des valeurs nécessaires à l’exécution, telles que le point de terminaison d’un proxy en cours d’exécution.

Les kits SDK V1 contiennent ces paramètres dans un seul ContainerRequest. Ses propriétés de système de fichiers, de réseau et d’interface utilisateur décrivent l’accès et sa commande, le répertoire de travail, l’environnement, le délai d’expiration et les propriétés de confinement décrivent l’exécution. Le Kit de développement logiciel (SDK) convertit la requête en contrat de schéma stable 1.0.0 . Vous ne spécifiez donc pas de version de schéma.

La configuration d’exécution JSON n’est pas interchangeable avec un objet SDK sérialisé. Par exemple, les propriétés timeoutMs et ui.allowInputInjection de la requête correspondent aux paramètres process.timeout et ui.injection de la configuration. Utilisez les types du Kit de développement logiciel (SDK) ou le schéma de la version de configuration que vous créez.

Cycles de vie à exécution unique et tenant compte de l’état

MXC prend en charge deux modèles de cycle de vie.

L’exécution unique crée l’environnement de test isolé, exécute une charge de travail, puis détruit cet environnement. Utilisez-le pour les outils d’agent de codage indépendants, les commandes générées, les builds, les tests et les scripts. La création d’un environnement de test isolé et restreint pour chaque action limite la quantité d’état conservée et réduit la nécessité de créer une stratégie trop générale.

L’exécution tenant compte de l’état expose cinq phases : provisionnement, démarrage, exécution, arrêt et déprovisionnement. Le provisionnement retourne un élément opaque ContainerId, que l’appelant passe inchangé aux phases ultérieures, et l’appelant peut exécuter plusieurs commandes avant le démantèlement. Utilisez ce modèle de conception uniquement lorsque la charge de travail dépend de l’état persistant, tel qu’un profil d’agent, des outils installés, une configuration ou un environnement de système d’exploitation. Dans MXC 1.0, les API de cycle de vie du SDK V1 prennent en charge IsolationSession et WSLc.

L’exécution prenant en compte l’état ne rend pas MXC le propriétaire de l’état. Le backend possède la ressource de bac à sable et l’appelant stocke son identificateur et gère son cycle de vie. L’arrêt de l’exécution et le déprovisionnement des ressources sont des opérations différentes ; l’état exact qui subsiste après un arrêt dépend du back-end.

L’exécution, le lancement de processus et l’exécution via PTY décrivent la manière dont votre hôte interagit avec un processus en cours d’exécution, et non la durée de vie de l’environnement. Un appel run retourne la sortie capturée une fois l’exécution terminée. Un appel spawn donne à votre hôte des flux d’entrée, de sortie et d’erreur standard en direct pendant l’exécution de la charge de travail. Un appel PTY connecte le workload à un pseudoterminal dont votre hôte contrôle également la taille. Vérifiez les combinaisons prises en charge par le SDK et le backend sélectionnés.

Responsabilités de l’hôte

Définissez un délai d’exécution et gérez séparément l’échec de la charge de travail, l’échec de lancement et l’annulation. L’annulation d’une attente du SDK n’équivaut pas nécessairement à l’arrêt de la charge de travail. Respectez le contrat d’arrêt et de libération des ressources du SDK, et attendez la fin de l’opération requise pour permettre la finalisation de l’exécution et, éventuellement, la capture des refus.

Pour l’exécution prenant en charge l’état, organisez le nettoyage même en cas d’échec d’une phase ultérieure. Un arrêt ayant échoué ne doit pas empêcher une tentative de déprovisionnement des ressources détenues par votre application.

La suppression du sandbox n’annule généralement pas les écritures dans des répertoires hôtes accordés ou les actions effectuées par le biais de services réseau autorisés. Choisissez délibérément les emplacements de sortie et choisissez les résultats à conserver avant que les tâches suivantes les utilisent.

Choisir un type de confinement

Commencez par les objectifs et contraintes de votre charge de travail, par exemple :

Besoin d’une charge de travail Type de départ Pourquoi
Commandes nécessitant des outils et chemins hôte sélectionnés avec un coût de démarrage faible Isolation des processus S’exécute au plus près de l’environnement hôte avec des autorisations limitées à la tâche
Charge de travail nécessitant un profil de Windows distinct ou une session interactive Isolement de session Sépare l’utilisateur et l’état de session de la charge de travail de l’environnement de l’utilisateur interactif, sans appliquer de filtrage des fichiers, du réseau ou de l’interface utilisateur par MXC
Charge de travail nécessitant un noyau distinct ou un environnement d’exploitation invité distinct Environnement virtualisé Utilise une frontière de machine virtuelle ou de micro-machine virtuelle, selon les fonctionnalités du backend sélectionné

Sur Windows, l’isolation des processus est un type courant, car il correspond à de nombreuses charges de travail nécessitant des ressources hôtes sélectionnées avec un coût de démarrage faible.

L’isolation de session sépare les utilisateurs et les sessions, mais elle ne limite pas ce à quoi la charge de travail peut accéder. Sur Windows, IsolationSession rejette les stratégies de système de fichiers et d’interface utilisateur. Sa requête doit également définir l’egress, l’ingress et la boucle locale de l’hôte sur allow, sans règles réseau ni proxy. Si la charge de travail a besoin de ces restrictions, choisissez un back-end qui peut les appliquer. Pour plus d’informations, consultez Sélection et paramètres du backend.

Une intention abstraite, telle que process, permet à MXC de résoudre un back-end spécifique à la plateforme. Sélectionnez un back-end concret lorsque vous avez besoin d’un environnement d’exploitation ou d’un cycle de vie particulier. Notez que ni une intention abstraite ni un mécanisme d’isolation plus robuste ne garantissent la prise en charge de tous les contrôles relatifs aux fichiers, au réseau ou à l’interface utilisateur.

Consultez les options de confinement MXC et la prise en charge de la plateforme pour obtenir des conseils de sélection et des liens vers une documentation détaillée du backend.

Mode d’apprentissage dans l’architecture

Le mode d’apprentissage permet la création de stratégies et le diagnostic pour les charges de travail ProcessContainer de Windows. Consultez Créer et affiner des stratégies MXC avec le mode d’apprentissage.

Conseils de conception pour les agents de codage

Lorsque vous utilisez un agent de codage pour vous aider à choisir un type de confinement, demandez-lui d’évaluer :

  1. Quels systèmes d’exploitation et architectures de processeur l’application doit-elle prendre en charge ?
  2. De quels fichiers, chemins réseau, fonctionnalités de l’interface utilisateur, appareils et outils hôtes la charge de travail a-t-elle besoin ?
  3. Chaque commande est-elle indépendante, ou l’identité et l’état doivent-ils persister d’une commande à l’autre ?
  4. Quelles sont les contraintes de démarrage, d’utilisation des ressources, de déploiement et d’interaction ?
  5. La charge de travail nécessite-t-elle Windows, Linux, un environnement de bureau complet ou un autre environnement d’exploitation ?
  6. Quelle frontière d’isolation convient aux hypothèses de confiance et aux données de la charge de travail ?
  7. Quelles fonctionnalités de stratégie demandées chaque backend disponible peut-il appliquer ?

L’agent doit comparer les types de confinement viables, indiquer ses hypothèses et compromis, et identifier les exigences non prises en charge. Vous pouvez ensuite sélectionner un type de confinement approprié et élaborer la stratégie.

Contenu connexe

  • Dernière mise à jour :