Mythes et vérités sur la sécurité dans Red Hat OpenShift
Beaucoup de nos clients prévoient de commencer à utiliser Red Hat OpenShift, notre plate-formed’orchestration de conteneurs préférée. Ses avantages peuvent se résumer en ce qu’il permet une modernisation progressive des applications existantes et le déploiement de beaucoup d’autres qui, pour ce qu’il faut nier, avec une conception basée sur les micro-services sont imposées à de nombreuses nouvelles architectures informatiques. Il suffit de penser à ne plus jamais avoir à «préparer» une machine (installation d’un système d’exploitation, configuration du réseau, sécurité, installation de bibliothèques et de logiciels dépendants) chaque fois que nous voulons déployer un environnement justifie de donner à cette technologie un essai.
Kubernetes est aux conteneurs ce qu’OpenStack est allé aux environnements cloud. Une solution open source, qui nous permet de partager une partie de l’infrastructure disponible dans nos centres de données : serveurs, réseaux, stockage dans des pools de ressources sur lesquels déployer, automatiquement différentes charges de travail. Grâce à un portail d’auto-approvisionnement, nos développeurs seront en mesure non seulement de déployer les environnements dont ils ont besoin pour que leurs applications fonctionnent parfaitement, mais aussi de vérifier automatiquement et en permanence que ces applications fonctionnent correctement. Si le «commit» d’un développeur à la dernière minute de la journée provoque un bogue, vous pouvez revenir à la version de la veille sans que personne n’ait à intervenir.
Si nous ajoutons à cela la possibilité de faire des déploiements graduels, où un petit pourcentage d’utilisateurs bénéficient d’une nouvelle version de notre application tandis que les autres continuent d’utiliser la dernière version stable; une grande disponibilité qui fonctionne sans configuration supplémentaire, allocation de ressources (développeurs, mémoire, Processeur, espace disque, affectation d’adresse IP) par projet, ou la possibilité de mesurer en temps réel quelle partie de notre infrastructure nous utilisons, à quel niveau d’efficacité et avec quels résultats, peu de gestionnaires de système diront non à une telle merveille. Sans oublier la possibilité d’mettre automatiquement à l’échelle les applications en ajoutant ou en enlevant des conteneurs au besoin.
Heureusement ou malheureusement, aucunou tout n’est entre les mains des gestionnaires de système. Qu’en est-il de la sécurité? Qu’en pensent les CISOs? Appuyez sur pour passer en charge certains «mythes».
OpenShift est extrêmement sûr par la conception. À notre avis, sa technologie de base (conteneurs) est aussi sûre que le noyau Linux l’est en tout temps. C’est-à-dire que les processus de conteneurs sont séparés par des « espaces nominaux » linux, les ressources qu’ils utilisent par les « cgroups » et leur sécurité, et leur contexte par SELinux. C’est puissant, oui, mais nous partageons toujours un noyau entre de nombreux conteneurs dans chacun d’eux. et le noyau doit être patché, aussi pour des raisons de sécurité. L’inclusion de RHCOS (Red Hat Core OS) nous a permis de faire de grands progrès ces derniers temps en termes de sécurité du système d’exploitation sur lequel fonctionne cette distribution Kubernetes. Toutefois, étant donné que les nœuds RHCOS sont destinés à fonctionner avec peu de changement, il est important que toute amélioration liée à la sécurité de ces nœuds se fasse avec un soin extrême. ce ne sera pas que nous obtenons l’effet inverse.
Les images que nous téléchargeons sont toujours vérifiées et votre code vérifié par Red Hat. Eh bien, en fait l’accès à des images de conteneurs (téléchargés ou propres) sont gérés d’une manière similaire aux MRR. Il y a des dépôts publics ou privés à qui nous nous connectons, avec leurs clés et leurs signatures. Les vulnérabilités continuent de sortir tous les jours, nous avons donc besoin d’une sorte de solution qui surveille le contenu des images de conteneurs disponibles dans nos référentiels, en particulier les images téléchargées et installées dans notre environnement.
OpenShift prend en charge JFrog Artifactory, Black Duck Hub et Docker Trusted Registry. Red Hat CloudForms SmartState peut également être utilisé pour marquer les images vulnérables de manière à ce qu’OpenShift empêche l’application de ces images. Ils sont également utiles pour les applications qui effectuent des tests statiques de sécurité des applications (SAST) et des tests dynamiques de sécurité des applications (DAST), tels que HP Fortify et IBM AppScan.
OpenShift dispose d’un système d’authentification robuste et sécurisé. Chaque cluster OpenShift utilise en fait des comptes d’utilisateur, de groupe et de rôle.
Pour gérer l’accès de chaque utilisateur aux composants OpenShift et être en mesure de vérifier l’identité de chaque utilisateur, le cluster se connectera à différents fournisseurs d’identification (OpenID, LDAP, Active Directory, Github, etc.). Chacun d’eux aura sa propre configuration, avantages et inconvénients.
L’isolement des réseaux et des communications entre les projets OpenShift est suffisant. Il est robuste, car il est basé sur les composants réseau de Kubernetes, mais il ya des opérateurs et des plug-ins qui peuvent nous aider à isoler les différents réseaux ou donner des accès dédiés à certaines cartes réseau en utilisant des technologies comme SR-IOV. Plugins tels que Multus-CNI qui permettent cette fonction et d’autres, complétant les fonctionnalités de l’opérateur de réseau cluster (CNO), le CNI «Container Network Interfaces» et CoreDNS .
Vous êtes intéressé à en savoir plus sur OpenShift? Vous pouvez être intéressé par notre cours intensif de trois jours Red Hat OpenShift 4.X. Nous offrons également une formation officielle IBM si vous souhaitez déployer des serveurs IBM Power Systems.
