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

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 :

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.

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.

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 :

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 :

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.