Rechercher

2.2. Comprendre la sécurité des hôtes et des machines virtuelles

download PDF

Les conteneurs et les machines virtuelles permettent de séparer les applications exécutées sur un hôte du système d'exploitation lui-même. Comprendre RHCOS, qui est le système d'exploitation utilisé par OpenShift Container Platform, vous aidera à voir comment les systèmes hôtes protègent les conteneurs et les hôtes les uns des autres.

2.2.1. Sécuriser les conteneurs sur Red Hat Enterprise Linux CoreOS (RHCOS)

Les conteneurs simplifient le déploiement de nombreuses applications sur le même hôte, en utilisant le même noyau et le même moteur d'exécution pour chaque conteneur. Les applications peuvent appartenir à de nombreux utilisateurs et, parce qu'elles sont séparées, elles peuvent fonctionner simultanément avec des versions différentes, voire incompatibles, de ces applications sans aucun problème.

Dans Linux, les conteneurs ne sont qu'un type spécial de processus, de sorte que la sécurisation des conteneurs est similaire à bien des égards à la sécurisation de n'importe quel autre processus en cours d'exécution. Un environnement pour l'exécution de conteneurs commence par un système d'exploitation capable de sécuriser le noyau de l'hôte vis-à-vis des conteneurs et des autres processus s'exécutant sur l'hôte, ainsi que de sécuriser les conteneurs les uns vis-à-vis des autres.

Étant donné qu'OpenShift Container Platform 4.12 fonctionne sur des hôtes RHCOS, avec la possibilité d'utiliser Red Hat Enterprise Linux (RHEL) comme nœuds de travail, les concepts suivants s'appliquent par défaut à tout cluster OpenShift Container Platform déployé. Ces fonctionnalités de sécurité RHEL sont au cœur de ce qui rend l'exécution de conteneurs dans OpenShift Container Platform plus sûre :

  • Linux namespaces les conteneurs permettent de créer une abstraction d'une ressource système globale particulière afin qu'elle apparaisse comme une instance distincte pour les processus au sein d'un espace de noms. Par conséquent, plusieurs conteneurs peuvent utiliser simultanément la même ressource informatique sans créer de conflit. Les espaces de noms des conteneurs qui sont séparés de l'hôte par défaut comprennent la table de montage, la table de processus, l'interface réseau, l'utilisateur, le groupe de contrôle, l'UTS et les espaces de noms IPC. Les conteneurs qui ont besoin d'un accès direct aux espaces de noms de l'hôte doivent disposer d'autorisations élevées pour demander cet accès. Voir Overview of Containers in Red Hat Systems dans la documentation sur les conteneurs de RHEL 8 pour plus de détails sur les types d'espaces de noms.
  • SELinux fournit une couche de sécurité supplémentaire pour isoler les conteneurs les uns des autres et de l'hôte. SELinux permet aux administrateurs d'appliquer des contrôles d'accès obligatoires (MAC) pour chaque utilisateur, application, processus et fichier.
Avertissement

Disabling SELinux on RHCOS is not supported.

  • CGroups (groupes de contrôle) limitent, comptabilisent et isolent l'utilisation des ressources (CPU, mémoire, E/S disque, réseau, etc.) d'un ensemble de processus. Les groupes de contrôle sont utilisés pour s'assurer que les conteneurs situés sur le même hôte ne sont pas affectés les uns par les autres.
  • Secure computing mode (seccomp) peuvent être associés à un conteneur pour restreindre les appels système disponibles. Voir la page 94 du OpenShift Security Guide pour plus de détails sur seccomp.
  • Le déploiement de conteneurs à l'aide de RHCOS réduit la surface d'attaque en minimisant l'environnement hôte et en l'adaptant aux conteneurs. Le moteur de conteneurs CRI-O réduit encore cette surface d'attaque en implémentant uniquement les fonctionnalités requises par Kubernetes et OpenShift Container Platform pour exécuter et gérer les conteneurs, contrairement à d'autres moteurs de conteneurs qui implémentent des fonctionnalités autonomes orientées vers le poste de travail.

RHCOS est une version de Red Hat Enterprise Linux (RHEL) spécialement configurée pour fonctionner en tant que plan de contrôle (maître) et nœuds de travail sur les clusters OpenShift Container Platform. RHCOS est donc réglé pour exécuter efficacement les charges de travail de conteneurs, ainsi que les services Kubernetes et OpenShift Container Platform.

Pour mieux protéger les systèmes RHCOS dans les clusters OpenShift Container Platform, la plupart des conteneurs, à l'exception de ceux qui gèrent ou surveillent le système hôte lui-même, doivent s'exécuter en tant qu'utilisateur non root. L'abaissement du niveau de privilège ou la création de conteneurs avec le moins de privilèges possible est la meilleure pratique recommandée pour protéger vos propres clusters OpenShift Container Platform.

2.2.2. Comparaison entre la virtualisation et les conteneurs

La virtualisation traditionnelle offre un autre moyen de séparer les environnements d'application sur le même hôte physique. Cependant, les machines virtuelles fonctionnent différemment des conteneurs. La virtualisation repose sur un hyperviseur qui fait tourner des machines virtuelles invitées (VM), chacune d'entre elles ayant son propre système d'exploitation (OS), représenté par un noyau en cours d'exécution, ainsi que l'application en cours d'exécution et ses dépendances.

Avec les VM, l'hyperviseur isole les invités les uns des autres et du noyau hôte. Moins de personnes et de processus ont accès à l'hyperviseur, ce qui réduit la surface d'attaque sur le serveur physique. Cela dit, la sécurité doit toujours être surveillée : une VM invitée pourrait être en mesure d'utiliser les bogues de l'hyperviseur pour accéder à une autre VM ou au noyau hôte. Et lorsque le système d'exploitation doit être corrigé, il doit l'être sur toutes les machines virtuelles invitées qui l'utilisent.

Les conteneurs peuvent être exécutés à l'intérieur de machines virtuelles invitées, et il peut y avoir des cas d'utilisation où cela est souhaitable. Par exemple, vous pouvez déployer une application traditionnelle dans un conteneur, peut-être pour transférer une application dans le nuage.

La séparation des conteneurs sur un seul hôte offre toutefois une solution de déploiement plus légère, plus flexible et plus facile à mettre à l'échelle. Ce modèle de déploiement est particulièrement adapté aux applications "cloud-native". Les conteneurs sont généralement beaucoup plus petits que les VM et consomment moins de mémoire et de CPU.

Voir Linux Containers Compared to KVM Virtualization dans la documentation sur les conteneurs de RHEL 7 pour en savoir plus sur les différences entre les conteneurs et les machines virtuelles.

2.2.3. Sécuriser OpenShift Container Platform

Lorsque vous déployez OpenShift Container Platform, vous avez le choix entre une infrastructure fournie par l'installateur (il existe plusieurs plateformes disponibles) et votre propre infrastructure fournie par l'utilisateur. Certaines configurations de bas niveau liées à la sécurité, telles que l'activation de la conformité FIPS ou l'ajout de modules de noyau requis au premier démarrage, peuvent bénéficier d'une infrastructure fournie par l'utilisateur. De même, l'infrastructure fournie par l'utilisateur est appropriée pour les déploiements déconnectés d'OpenShift Container Platform.

Gardez à l'esprit que, lorsqu'il s'agit d'apporter des améliorations de sécurité et d'autres changements de configuration à OpenShift Container Platform, les objectifs doivent inclure :

  • Garder les nœuds sous-jacents aussi génériques que possible. Vous voulez pouvoir facilement jeter et faire tourner des nœuds similaires rapidement et de manière prescriptive.
  • Gérer autant que possible les modifications apportées aux nœuds par l'intermédiaire d'OpenShift Container Platform, plutôt que d'apporter des modifications directes et ponctuelles aux nœuds.

Pour atteindre ces objectifs, la plupart des modifications de nœuds doivent être effectuées lors de l'installation par Ignition ou ultérieurement à l'aide de MachineConfigs qui sont appliquées à des ensembles de nœuds par l'opérateur de configuration de la machine. Voici quelques exemples de modifications de configuration liées à la sécurité que vous pouvez effectuer de cette manière :

  • Ajouter des arguments au noyau
  • Ajouter des modules au noyau
  • Prise en charge de la cryptographie FIPS
  • Configuration du cryptage des disques
  • Configuration du service chronologique

En plus de l'opérateur de configuration des machines, il existe plusieurs autres opérateurs disponibles pour configurer l'infrastructure d'OpenShift Container Platform qui sont gérés par l'opérateur de version de cluster (CVO). Le CVO est capable d'automatiser de nombreux aspects des mises à jour des clusters d'OpenShift Container Platform.

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.

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 leBlog 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.

© 2024 Red Hat, Inc.