Red Hat Summit Red Hat SummitSupportConsoleDéveloppeursCommencer un essaiContact

Chapitre 2. Comprendre les conteneurs de type "sandbox" d'OpenShift

La prise en charge des conteneurs en bac à sable OpenShift pour OpenShift Container Platform vous offre une prise en charge intégrée de l'exécution de Kata Containers en tant que runtime optionnel supplémentaire. Le nouveau runtime prend en charge les conteneurs dans des machines virtuelles (VM) dédiées, ce qui permet d'améliorer l'isolation de la charge de travail. Ceci est particulièrement utile pour effectuer les tâches suivantes :

Exécuter des charges de travail privilégiées ou non fiables

OpenShift sandboxed containers (OSC) permet d'exécuter en toute sécurité des charges de travail qui nécessitent des privilèges spécifiques, sans avoir à risquer de compromettre les nœuds du cluster en exécutant des conteneurs privilégiés. Les charges de travail qui requièrent des privilèges spéciaux sont les suivantes :

  • Les charges de travail qui requièrent des capacités spéciales de la part du noyau, au-delà des capacités par défaut accordées par les runtimes de conteneurs standard tels que CRI-O, par exemple pour accéder à des fonctions de réseau de bas niveau.
  • Les charges de travail qui nécessitent des privilèges root élevés, par exemple pour accéder à un appareil physique spécifique. Avec les conteneurs OpenShift sandboxed, il est possible de ne faire passer qu'un appareil spécifique dans la VM, en veillant à ce que la charge de travail ne puisse pas accéder au reste du système ou le configurer de manière erronée.
  • Charges de travail pour l'installation ou l'utilisation des binaires root de set-uid. Ces binaires accordent des privilèges spéciaux et, en tant que tels, peuvent présenter un risque de sécurité. Avec les conteneurs OpenShift sandboxed, les privilèges supplémentaires sont limités aux machines virtuelles et n'accordent aucun accès spécial aux nœuds du cluster.

Certaines charges de travail peuvent nécessiter des privilèges spécifiquement pour configurer les nœuds du cluster. Ces charges de travail doivent toujours utiliser des conteneurs privilégiés, car leur exécution sur une machine virtuelle les empêcherait de fonctionner.

Assurer l'isolation du noyau pour chaque charge de travail
Les conteneurs en bac à sable d'OpenShift prennent en charge les charges de travail qui nécessitent un réglage personnalisé du noyau (comme sysctl, des modifications du planificateur ou un réglage du cache) et la création de modules personnalisés du noyau (comme out of tree ou des arguments spéciaux).
Partager la même charge de travail entre les locataires
Les conteneurs OpenShift sandboxed vous permettent de prendre en charge plusieurs utilisateurs (locataires) de différentes organisations partageant le même cluster OpenShift. Le système vous permet également d'exécuter des charges de travail tierces provenant de plusieurs fournisseurs, telles que des fonctions de réseau de conteneurs (CNF) et des applications d'entreprise. Les CNF tiers, par exemple, peuvent ne pas vouloir que leurs paramètres personnalisés interfèrent avec le réglage des paquets ou avec les variables sysctl définies par d'autres applications. L'exécution à l'intérieur d'un noyau complètement isolé permet d'éviter les problèmes de configuration des "voisins bruyants".
Veiller à l'isolation et à la mise en bac à sable des logiciels de test
Vous pouvez utiliser les conteneurs OpenShift sandboxed pour exécuter une charge de travail conteneurisée avec des vulnérabilités connues ou pour gérer un problème dans une application existante. Cette isolation permet également aux administrateurs de donner aux développeurs un contrôle administratif sur les pods, ce qui est utile lorsque le développeur veut tester ou valider des configurations au-delà de celles qu'un administrateur accorderait normalement. Les administrateurs peuvent, par exemple, déléguer en toute sécurité le filtrage des paquets du noyau (eBPF) aux développeurs. Le filtrage des paquets du noyau nécessite les privilèges CAP_ADMIN ou CAP_BPF et n'est donc pas autorisé dans une configuration CRI-O standard, car cela donnerait accès à chaque processus sur le nœud de travail de l'hôte du conteneur. De même, les administrateurs peuvent autoriser l'accès à des outils intrusifs tels que SystemTap, ou prendre en charge le chargement de modules de noyau personnalisés au cours de leur développement.
Assurer le confinement des ressources par défaut à travers les limites des machines virtuelles
Par défaut, les ressources telles que le CPU, la mémoire, le stockage ou le réseau sont gérées de manière plus robuste et sécurisée dans les conteneurs OpenShift sandboxed. Puisque les conteneurs OpenShift sandboxed sont déployés sur des VM, des couches supplémentaires d'isolation et de sécurité donnent un contrôle d'accès plus fin à la ressource. Par exemple, un conteneur errant ne pourra pas allouer plus de mémoire que ce qui est disponible pour la VM. Inversement, un conteneur qui a besoin d'un accès dédié à une carte réseau ou à un disque peut prendre le contrôle total de ce périphérique sans avoir accès aux autres périphériques.

Vous pouvez installer les conteneurs OpenShift sandboxed sur un serveur bare-metal ou sur une instance bare-metal Amazon Web Services (AWS). Les instances bare-metal proposées par d'autres fournisseurs de cloud ne sont pas prises en charge.

Red Hat Enterprise Linux CoreOS (RHCOS) est le seul système d'exploitation pris en charge pour les conteneurs OpenShift sandboxed. OpenShift sandboxed containers 1.3 fonctionne sur Red Hat Enterprise Linux CoreOS (RHCOS) 8.6.

OpenShift sandboxed containers 1.3 est compatible avec OpenShift Container Platform 4.11.

Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance. Découvrez nos récentes mises à jour.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Theme

© 2026 Red HatRetour au début