Sécurité de Red Hat OpenShift on IBM Cloud

Comment l'accès à mon serveur API est-il accordé?

Par défaut, Kubernetes nécessite que toutes les demandes suivent plusieurs étapes avant que l'accès au serveur d'API ne soit accordé.

Authentification

Valide l'identité d'un utilisateur ou d'un compte de service enregistré.

Autorisation

Limite les droits des utilisateurs authentifiés et des comptes de service pour s'assurer qu'ils peuvent accéder et utiliser uniquement les composants de cluster que vous souhaitez qu'ils soient.

Contrôle d'admission

Valide ou mute les demandes avant qu'elles ne soient traitées par le serveur API Red Hat OpenShift. De nombreuses fonctionnalités d' Kubernetes s nécessitent des contrôleurs d'admission pour fonctionner correctement.

Que fait Red Hat OpenShift on IBM Cloud pour sécuriser mon serveur API et mon magasin de données etcd?

L'image suivante présente les paramètres de sécurité par défaut du cluster pour l'authentification, l'autorisation, le contrôle d'admission et la connectivité sécurisée entre le maître Kubernetes et les noeuds worker.

Examinez les fonctions de sécurité suivantes pour le serveur d'API Red Hat OpenShift et etcd.

Maître Red Hat OpenShift entièrement géré et dédié

Chaque cluster dans Red Hat OpenShift on IBM Cloud est régi par un maître Red Hat OpenShift dédié géré par IBM dans un compte IBM Cloud sous propriété IBM. Le maître Red Hat OpenShift est configuré avec les composants dédiés suivants qui ne sont pas partagés avec d'autres clients IBM.

• Magasin de données etcd : stocke toutes les ressources Kubernetes d'un cluster, telles que Services, Deployments et Pods. Les éléments Kubernetes ConfigMaps et Secrets sont des données d'application stockées sous forme de paires clé-valeur pour pouvoir les utiliser dans une application s'exécutant dans un pod. Les données d'etcd sont stockées sur le disque local du maître Red Hat OpenShift et sauvegardées dans IBM Cloud Object Storage. Les données sont chiffrées lors du transit vers IBM Cloud Object Storage et au repos. Vous pouvez choisir d'activer le chiffrement de vos données etcd sur le disque local de votre maître Red Hat OpenShift en activant le chiffrement IBM Key Protect pour votre cluster. Lorsque ces données sont envoyées à un pod, elles sont chiffrées avec TLS pour garantir leur protection et leur intégrité.
• openshift-api: constitue le point d'entrée principal pour toutes les demandes de gestion de cluster du noeud worker au maître Red Hat OpenShift. Le serveur d'API valide et traite les demandes qui modifient l'état des ressources cluster, tels que les pods ou les services, et enregistre cet état dans le magasin de données etcd.
• openshift-controller : examine les pods qui viennent d'être créés et décide de l'emplacement de leur déploiement en fonction de la capacité, des besoins en matière de performances, des contraintes en matière de réglementation, des spécifications en matière d'anti-affinité et des exigences liées aux charges de travail. Si aucun noeud worker ne répond à ces exigences, le pod n'est pas déployé dans le cluster. Le contrôleur examine également l'état des ressources de cluster, telles que les ensembles de répliques. Lorsque l'état d'une ressource change, par exemple si un pod d'un ensemble de répliques tombe en panne, le gestionnaire de contrôleurs initie les actions correctives pour atteindre l'état requis.
• cloud-controller-manager : Le gestionnaire de contrôleurs de cloud gère des composants propres au fournisseur de cloud, tels que l'équilibreur de charge IBM Cloud.
• Connectivité : composant spécifique à l' Red Hat OpenShift on IBM Cloud permettant d'assurer une connectivité réseau sécurisée pour toutes les communications entre le nœud maître et les nœuds esclaves de l' Red Hat OpenShift. Le serveur Konnectivity fonctionne avec l'agent Konnectivity pour connecter en toute sécurité le maître au nœud de travail. Cette connexion prend en charge les demandes apiserver proxy vers vos pods et services, ainsi que les demandes oc exec, attach et logs vers le kubelet. La connexion entre les noeuds worker et le maître est automatiquement sécurisée avec des certificats TLS.

Surveillance continue par des ingénieurs IBM SRE (Site Reliability Engineer)

Le maître Red Hat OpenShift, y compris tous ses composants et toutes ses ressources de calcul, mise en réseau et stockage, est surveillé en permanence par des ingénieurs IBM SRE (Site Reliability Engineer). Ces ingénieurs appliquent les dernières normes en matière de sécurité, détectent et éliminent les activités malveillantes et travaillent pour assurer la fiabilité et la disponibilité de Red Hat OpenShift on IBM Cloud.

Test de performances du maître Kubernetes CIS

Pour configurer Red Hat OpenShift on IBM Cloud, les ingénieurs IBM suivent les pratiques de cybersécurité pertinentes à partir de la référence principale de Kubernetes qui est publiée par Centre de sécurité Internet (CIS). Le maître cluster et tous les noeuds worker sont déployés avec des images répondant aux critères du test de performances.

Communication sécurisée via TLS

Pour utiliser Red Hat OpenShift on IBM Cloud, vous devez vous authentifier auprès du service à l'aide de vos données d'identification. Une fois authentifié, Red Hat OpenShift on IBM Cloud génère des certificats TLS qui chiffrent la communication en provenance et à destination du serveur d'API Red Hat OpenShift et du magasin de données etcd pour garantir une communication sécurisée de bout en bout entre les noeuds worker et le maître Red Hat OpenShift. Ces certificats ne sont jamais partagés entre les clusters ou entre les composants du maître Red Hat OpenShift.

Connectivité aux noeuds worker

Bien que Kubernetes sécurise les communications entre le maître Kubernetes et les noeuds worker à l'aide du protocole https, aucune authentification n'est fournie par défaut sur le noeud worker. Pour sécuriser cette communication, Red Hat OpenShift on IBM Cloud établit automatiquement une connexion Konnectivity entre le maître Red Hat OpenShift et le nœud de travail lors de la création du cluster.

Contrôle d'accès à granularité fine

En tant qu'administrateur de compte, vous pouvez Accorder l'accès à d'autres utilisateurs pour Red Hat OpenShift on IBM Cloud à l'aide de IBM Cloud Identity and Access Management (IAM). IBM Cloud IAM fournit une authentification sécurisée avec la plateforme IBM Cloud, Red Hat OpenShift on IBM Cloudet toutes les ressources de votre compte. La configuration des rôles d'utilisateur et des droits d'accès est essentielle pour limiter le nombre de personnes pouvant accéder à vos ressources et réduire les dommages que pourrait causer un utilisateur en cas d'utilisation abusive de droits légitimes. Vous pouvez effectuer une sélection parmi les rôles d'utilisateur prédéfinis suivants qui déterminent l'ensemble des actions que l'utilisateur peut exécuter :

• Rôles d'accès à la plateforme : ces rôles déterminent les actions de gestion liées au cluster et aux noeuds worker pouvant être exécutées par un utilisateur dans Red Hat OpenShift on IBM Cloud. Les rôles d'accès à la plateforme affectent également aux utilisateurs les rôles RBAC basic-users et self-provisioners. Grâce à ces rôles RBAC, vous pouvez créer un projet d' Red Hat OpenShift dans le cluster, dans lequel vous pouvez déployer des applications et d'autres ressources d' Kubernetes. En tant que créateur du projet, vous recevez automatiquement le rôle RBAC admin pour le projet afin de pouvoir contrôler entièrement ce que vous souhaitez déployer et exécuter dans votre projet. Toutefois, ces rôles RBAC n'accordent pas d'accès à d'autres projets Red Hat OpenShift. Pour que vous puissiez afficher et accéder à d'autres projets Red Hat OpenShift, le rôle d'accès au service approprié dans IAM doit vous être affecté.
• Rôles d'accès au service : déterminez le rôle RBAC d' Kubernetes s attribué à l'utilisateur et les actions qu'un utilisateur peut exécuter sur le serveur API d' Red Hat OpenShift. Alors que le rôle RBAC basic-users et self-provisioners qui est affecté avec un rôle d'accès à la plateforme vous permet de créer et de gérer vos propres projets Red Hat OpenShift, vous ne pouvez pas afficher, accéder ou travailler avec d'autres projets Red Hat OpenShift tant que vous n'avez pas été affecté à un rôle d'accès au service. Pour plus d'informations sur les rôles RBAC correspondants attribués à un utilisateur et les autorisations associées, consultez la section Rôles d'accès au service IAM.
• Infrastructure classique : permet d'accéder à vos ressources d'infrastructure classiques. Les exemples des actions autorisées par les rôles d'infrastructure classique incluent notamment l'affichage des détails de machines de noeud worker de cluster ou l'édition de ressources de mise en réseau et de stockage.
• Infrastructure classique : permet d'accéder aux ressources de l'infrastructure VPC. Exemples d'actions autorisés par les rôles d'infrastructure VPC : création d'un VPC, ajout de sous-réseaux, modification d'adresses IP flottantes et création d'instances VPC Block Storage.

Pour plus d'informations sur le contrôle d'accès dans un cluster, voir Affectation d'accès au cluster.

Contrôleurs d'admission

Les contrôleurs d'admission sont implémentés pour des fonctions spécifiques dans Kubernetes et Red Hat OpenShift on IBM Cloud. Avec ces contrôleurs, vous pouvez configurer des règles dans votre cluster pour déterminer si une action particulière dans le cluster est autorisée ou non. Dans la politique, vous pouvez spécifier des conditions lorsqu'un utilisateur ne peut pas effectuer une action, même si cette action fait partie des droits généraux que vous avez attribués à l'utilisateur à l'aide de rôles RBAC. Par conséquent, les contrôleurs d'admission peuvent fournir une couche de sécurité supplémentaire pour votre cluster avant le traitement d'une demande d'API par le serveur d'API Red Hat OpenShift.

Lorsque vous créez un cluster, Red Hat OpenShift on IBM Cloud installe automatiquement les contrôleurs d'admission par défaut d' Kubernetes dans un ordre particulier dans le maître Red Hat OpenShift, qui ne peut pas être modifié par l'utilisateur. Consultez l'ordre des contrôleurs d'admission par défaut par version de cluster dans les informations de référence sur les composants.

Vous pouvez installer vos propres contrôleurs d'admission dans le cluster ou choisir un contrôleur d'admission optionnel, tel que Portieris. Avec Portieris, vous pouvez bloquer les déploiements de conteneur à partir d'images non signées.

Si vous avez installé manuellement des contrôleurs d'admission et que vous ne voulez plus les utiliser, veillez à les supprimer entièrement. Si vous ne les supprimez pas complètement, ils peuvent bloquer toutes les actions que vous souhaitez effectuer sur le cluster.

Que puis-je faire d'autre pour sécuriser mon serveur API?

Vous pouvez restreindre la connectivité réseau à votre maître de cluster de plusieurs façons

• Activez uniquement le point de terminaison du service de cloud privé: Le point de terminaison du service public n'est requis que pour les clusters classiques OpenShift. Il peut être désactivé pour tous les clusters VPC. Il peut également être désactivé pour les clusters classiques Kubernetes, à condition que les options VRF et Service Endpoint soient activées dans votre compte. Cela permet de protéger le maître de la grappe contre les attaques sur le réseau public.
• Activer les restrictions basées sur le contexte: Vous pouvez sécuriser l'accès réseau aux points d'extrémité des services privés et publics de votre cluster à l'aide de restrictions basées sur le contexte (CBR). Seules les demandes autorisées adressées au maître de la grappe et provenant de sous-réseaux figurant dans les règles CBR sont autorisées. Pour plus d'informations, voir Utilisation des restrictions basées sur le contexte.

Qui est propriétaire du nœud de travail et suis-je responsable de sa sécurité?

La propriété d'un noeud worker dépend du type de cluster que vous créez et du fournisseur d'infrastructure que vous choisissez.

• Clusters classiques: les nœuds de travail sont provisionnés dans votre compte IBM Cloud. Les noeuds worker vous sont dédiés et il vous incombe de demander des mises à jour de ces noeuds worker fréquemment pour faire en sorte que le système d'exploitation des noeuds worker et les composants IBM Cloud Kubernetes Service appliquent les mises à jour et les correctifs de sécurité les plus récents.
• Clusters VPC: les nœuds de travail sont provisionnés dans un compte IBM Cloud appartenant à IBM afin de permettre la surveillance des activités malveillantes et l'application des mises à jour de sécurité. Vous ne pouvez pas accéder à vos nœuds de travail à l'aide du tableau de bord VPC. En revanche, vous pouvez gérer vos noeuds worker à l'aide de la console, de l'interface de ligne de commande ou de l'API IBM Cloud Kubernetes Service. Les machines virtuelles qui constituent vos noeuds worker vous sont dédiées et il vous incombe de demander des mises à jour fréquemment pour faire en sorte que le système d'exploitation des noeuds worker et les composants IBM Cloud Kubernetes Service appliquent les mises à jour et les correctifs de sécurité les plus récents.

Pour plus d'informations, voir Vos responsabilités liées à l'utilisation de Red Hat OpenShift on IBM Cloud.

Utilisez ibmcloud oc worker update Commande régulièrement (par exemple, par mois) pour déployer des mises à jour et des correctifs de sécurité sur le système d'exploitation et pour mettre à jour la version Red Hat OpenShift exécutée par vos nœuds de travail. Lorsque des mises à jour sont disponibles, vous êtes averti lorsque vous affichez des informations sur le master et les nœuds worker dans la console ou l'interface de ligne de commande IBM Cloud, par exemple, avec les commandes ibmcloud oc clusters ls ou ibmcloud oc workers ls --cluster <cluster_name>. Les mises à jour de noeud worker sont fournies par IBM sous forme d'image du noeud worker complet incluant les derniers correctifs de sécurité. Pour appliquer les mises à jour, le noeud worker doit être réimagé et rechargé avec la nouvelle image. Les clés des superutilisateurs (root) font automatiquement l'objet d'une rotation lorsque le noeud est rechargé.

À quoi ressemble la configuration de mon nœud de travail?

L'image suivante présente les composants configurés pour tous les noeuds worker afin de protéger vos noeuds worker contre les attaques malveillantes.

Cette image ne contient pas les composants qui assurent la communication sécurisée de bout en bout en provenance et à destination du noeud worker. Pour plus d'informations, voir Sécurité des réseaux.

CIS-image conforme

Chaque nœud de travail est configuré avec un système d'exploitation qui met en œuvre les benchmarks publiés par le Center of Internet Security ( CIS ). L'utilisateur ou le propriétaire de la machine ne peut pas remplacer ce système d'exploitation par un autre. Pour vérifier la version actuelle du système d'exploitation, exécutez oc get nodes -o wide. IBM collabore avec des équipes de conseil en sécurité, internes et externes, pour traiter les vulnérabilités de conformité aux règles de sécurité potentielles. Les mises à jour et les correctifs de sécurité du système d'exploitation sont disponibles via Red Hat OpenShift on IBM Cloud et doivent être installés par l'utilisateur pour assurer que le noeud worker est sécurisé.

Red Hat OpenShift on IBM Cloud utilise un Linux noyau pour les nœuds de travail. Vous pouvez exécuter des conteneurs en fonction de n'importe quelle distribution Linux dans Red Hat OpenShift on IBM Cloud. Vérifiez auprès de votre fournisseur d'images de conteneurs que vos images de conteneurs peuvent fonctionner sur le noyau.

Surveillance continue par des ingénieurs SRE (Site Reliability Engineer)

L'image installée sur vos noeuds worker est surveillée en permanence par les ingénieurs SRE (IBM Site Reliability Engineers) pour détecter les vulnérabilités et les problèmes de conformité à la sécurité. Pour traiter les vulnérabilités, les ingénieurs SRE créent des correctifs et des groupes de correctifs de sécurité pour vos noeuds worker. Veillez à appliquer ces correctifs dès qu'ils sont disponibles afin de garantir un environnement sécurisé pour vos nœuds de travail et les applications que vous exécutez sur ceux-ci.

Test de performances de noeud worker Kubernetes CIS

Pour configurer Red Hat OpenShift on IBM Cloud, les ingénieurs d' IBM suivent les pratiques de cybersécurité pertinentes issues du benchmark des nœuds de travail Kubernetes publié par le Center of Internet Security(CIS). Vous pouvez vérifier la conformité des noeuds worker par rapport à des normes de test de performances CIS Kubernetes et de test de performances Red Hat OpenShift.

Isolement du calcul

Les nœuds worker sont dédiés à un cluster et n'hébergent pas les charges de travail des autres clusters. Lorsque vous créez un cluster classique, vous pouvez choisir de provisionner vos nœuds de travail en tant que machines physiques (bare metal) ou en tant que machines virtuelles fonctionnant sur du matériel physique partagé ou dédié. Les nœuds de travail d'un cluster VPC peuvent être provisionnés uniquement en tant que machines virtuelles sur une infrastructure partagée.

Option pour déploiement bare metal sur des clusters classiques

Si vous créez un cluster classique standard, vous pouvez choisir de mettre à disposition vos noeuds worker sur des serveurs physiques bare metal (au lieu d'instances de serveur virtuel). Avec des machines bare metal, vous bénéficiez d'un contrôle supplémentaire sur l'hôte de calcul, par exemple la mémoire ou l'UC. Cette configuration élimine l'hyperviseur de machine virtuelle qui alloue des ressources physiques aux machines virtuelles qui s'exécutent sur l'hôte. Au lieu de cela, toutes les ressources d'une machine bare metal sont exclusivement réservées au travailleur, de sorte que vous n'avez pas à vous inquiéter des « voisins bruyantes » partageant des ressources ou ralentissant les performances. Les serveurs bare metal vous sont dédiés, avec toutes leurs ressources disponibles pour l'utilisation du cluster.

Disques chiffrés

Par défaut, tous les noeuds worker sont mis à disposition avec deux partitions de données SSD locales chiffrées avec AES 256 bits. La première partition contient l'image du noyau utilisée pour initialiser le noeud worker et n'est pas chiffrée. La deuxième partition renferme le système de fichiers du conteneur. Elle est déverrouillée à l'aide de clés de chiffrement LUKS. Chaque noeud worker dans chaque cluster dispose de sa propre clé de chiffrement LUKS unique, gérée par Red Hat OpenShift on IBM Cloud. Lorsque vous créez un cluster ou ajoutez un noeud worker à un cluster existant, les clés sont extraites de manière sécurisée, puis ignorées une fois le disque chiffré déverrouillé. Le chiffrement peut avoir une incidence sur les performances des entrées-sorties (E-S) de disque. Dans le cas de charges de travail exigeant de hautes performances des E-S de disque, testez un cluster avec et sans chiffrement activé pour déterminer s'il convient de désactiver le chiffrement.

SELinux

Chaque nœud de travail est configuré avec des politiques de sécurité et d'accès qui sont appliquées par des profils SELinux(Security-Enhanced Linux) chargés dans le nœud de travail lors du démarrage. Les profils SELinux ne peuvent pas être modifiés par l'utilisateur ou le propriétaire de la machine.

SSH désactivé

Par défaut, l'accès SSH est désactivé sur le noeud worker pour protéger votre cluster des attaques malveillantes. Lorsque l'accès SSH est désactivé, l'accès au cluster est forcé via le serveur d'API Red Hat OpenShift. Le serveur d'API Red Hat OpenShift requiert que toutes les demandes soient vérifiées par rapport aux règles définies dans le module d'authentification, d'autorisation et de contrôle d'admission avant l'exécution de la demande dans le cluster.

Si vous disposez d'un cluster standard et que vous souhaitez installer davantage de fonctionnalités sur votre nœud de travail, vous pouvez choisir entre les modules complémentaires fournis par Red Hat OpenShift on IBM Cloud ou utiliser les ensembles de démons Kubernetes pour tout ce que vous souhaitez exécuter sur chaque nœud de travail. Pour toute action ponctuelle que vous devez exécuter, utilisez les tâches d' Kubernetes.

Segmentation de réseau et confidentialité pour les clusters classiques

Pour protéger votre réseau et limiter l'étendue des dommages pouvant être causés par un utilisateur lorsque l'accès est octroyé, vous devez veiller à ce que vos charges de travail soient aussi isolées que possible et à limiter le nombre d'applications et de noeuds worker exposés publiquement.

Quel trafic réseau est autorisé par défaut pour mon cluster Classic?

Tous les conteneurs sont protégés par des paramètres de règles réseau Calico prédéfinis qui sont configurés sur chaque noeud worker lors de la création du cluster. Par défaut, tout le trafic réseau sortant est autorisé pour tous les noeuds worker. Le trafic réseau entrant est bloqué avec les exceptions suivantes :

• NodePort: la plage KubernetesNodePort est ouverte par défaut afin que vous puissiez exposer des applications avec des services NodePort. Pour bloquer le trafic réseau entrant sur les services NodePort dans votre cluster, voir Contrôle du trafic entrant vers les services d'équilibreur de charge de réseau ou NodePort.
• Ports de surveillance IBM : par défaut, IBM ouvre quelques ports sur votre cluster de sorte que le trafic réseau puisse être surveillé par IBM et pour permettre à IBM d'installer automatiquement des mises à jour de sécurité pour le maître Red Hat OpenShift.

L'accès depuis le maître de l' Red Hat OpenShift e au kubelet du nœud de travail est sécurisé par un tunnel Konnectivity. Pour plus d'informations, voir l'architecture Red Hat OpenShift on IBM Cloud.

Qu'est-ce que la segmentation réseau et comment puis-je la configurer pour un cluster Classic?

La segmentation du réseau décrit l'approche utilisée pour diviser un réseau en plusieurs sous-réseaux. Vous pouvez regrouper des applications et les données associées auxquelles accéder au sein d'un groupe particulier dans votre organisation. Les applications qui s'exécutent dans un sous-réseau ne peuvent pas voir ou accéder à des applications dans un autre sous-réseau. La segmentation du réseau limite également l'accès fourni à un utilisateur interne ou à un logiciel tiers et peut restreindre l'éventail d'activités malveillantes.

Red Hat OpenShift on IBM Cloud fournit des VLAN IBM Cloud qui assurent des performances réseau et un isolement du réseau de qualité pour les noeuds worker. Un VLAN configure un groupe de noeuds worker et de pods comme s'ils étaient reliés physiquement au même câble. Les VLAN sont dédiés à votre compte IBM Cloud et ne sont pas partagés avec les clients IBM. Dans des clusters classiques, si vous disposez de plusieurs VLAN pour votre cluster, de plusieurs sous-réseaux sur le même VLAN ou d'un cluster classique multizone, vous devez activer une fonction VRF (Virtual Router Function) pour votre compte d'infrastructure IBM Cloud de sorte que vos noeuds worker puissent communiquer entre eux sur le réseau privé. Pour activer la fonction VRF, voir Activation de VRF. Pour vérifier si la fonction VRF est déjà activée, utilisez la commande ibmcloud account show. Si vous ne pouvez pas ou ne souhaitez pas activer VRF, activez Réseau local virtuel. Pour effectuer cette action, vous devez disposer de l'autorisation Infrastructure réseau > Gérer le réseau VLAN Spanning, ou vous pouvez demander au propriétaire du compte de l'activer. Pour vérifier si le VLAN spanning est déjà activé, utilisez la ibmcloud oc vlan spanning get --region <region>commande.

Lorsque vous activez la fonction VRF ou Spanning VLAN pour votre compte, la segmentation du réseau est retirée de vos clusters.

Consultez le tableau suivant pour voir les options permettant d'obtenir une segmentation du réseau lorsque vous activez la fonction VRF ou Spanning VLAN pour votre compte.

Que puis-je faire d'autre pour réduire la surface d'attaque externe des clusters Classic?

Plus vous exposez d'applications et de noeuds worker au public, plus les étapes pour vous protéger contre les attaques malveillantes provenant de l'extérieur sont nombreuses. Consultez le tableau suivant pour identifier les options permettant de préserver la confidentialité de vos applications et de vos noeuds worker.

Que faire si je souhaite connecter mon cluster à un centre de données sur site?

Pour connecter vos nœuds de travail et vos applications à un centre de données sur site, vous pouvez configurer un Virtual Router Appliance ou un Fortigate Security Appliance.

Segmentation de réseau et confidentialité pour les clusters de VPC

Pour protéger votre réseau et limiter l'étendue des dommages pouvant être causés par un utilisateur lorsque l'accès est octroyé, vous devez veiller à ce que vos charges de travail soient aussi isolées que possible et à limiter le nombre d'applications et de noeuds worker exposés publiquement.

Quel trafic réseau est autorisé par défaut pour mon cluster VPC?

Par défaut, les nœuds de travail sont connectés à Sous-réseaux VPC sur le réseau privé uniquement et n'ont pas d'interface réseau publique. L'accès public à vos nœuds worker est bloqué. La sortie publique de vos nœuds worker n'est autorisée que si les travailleurs sont connectés à un sous-réseau VPC doté d'une passerelle publique.

L'accès aux composants Red Hat OpenShift par défaut, tels que la console Web ou OperatorHub sans être connecté au réseau privé de votre VPC, nécessite qu'une passerelle publique soit connectée aux sous-réseaux VPC sur lesquels les noeuds worker sont déployés. L'ensemble du trafic sortant est autorisé pour les noeuds worker sur un sous-réseau via une passerelle publique connectée, mais tout le trafic entrant est toujours bloqué.

Si vous déployez des applications dans votre cluster qui doivent recevoir des demandes de trafic d'Internet, vous pouvez créer un équilibreur de charge VPC pour exposer vos applications. Pour autoriser le trafic réseau entrant vers vos applications, vous devez configurer votre équilibreur de charge VPC pour le trafic réseau entrant que vous souhaitez recevoir.

Les groupes de sécurité sont appliqués par défaut à votre instance VPC et à vos ALB et NLB VPC. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.

Qu'est-ce que la segmentation réseau et comment puis-je la configurer pour un cluster VPC?

La segmentation du réseau décrit l'approche utilisée pour diviser un réseau en plusieurs sous-réseaux. Vous pouvez regrouper des applications et les données associées auxquelles accéder au sein d'un groupe particulier dans votre organisation. Les applications qui s'exécutent dans un sous-réseau ne peuvent pas voir ou accéder à des applications dans un autre sous-réseau. La segmentation du réseau limite également l'accès fourni à un utilisateur interne ou à un logiciel tiers et peut restreindre l'éventail d'activités malveillantes.

Red Hat OpenShift on IBM Cloud fournit des sous-réseaux IBM Cloud VPC qui assurent des performances réseau et un isolement du réseau de qualité pour les noeuds worker. Un sous-réseau VPC se compose d'une plage d'adresses IP privées spécifiées (bloc de routage CIDR) et configure un groupe de noeuds worker et de pods comme s'ils étaient connectés au même câble physique. Les sous-réseaux VPC sont dédiés à votre compte IBM Cloud et ne sont pas partagés avec les clients IBM.

Les sous-réseaux VPC fournissent un canal pour établir la connectivité entre les noeuds worker au sein du cluster. Tout système connecté à l'un des sous-réseaux privés du même VPC peut communiquer avec les noeuds worker. Par exemple, tous les sous-réseaux d'un VPC peuvent communiquer via un routage de couche 3 privé avec un routeur VPC intégré. Si vos clusters n'ont pas besoin de communiquer, vous pouvez réaliser la meilleure segmentation de réseau en créant les clusters dans des VPC distincts. Si vous possédez plusieurs clusters qui doivent communiquer entre eux, vous pouvez créer les clusters dans le même VPC. Bien que les sous-réseaux d'un VPC puissent être partagés par plusieurs clusters dans ce VPC, vous pouvez obtenir une meilleure segmentation du réseau en utilisant différents sous-réseaux pour les clusters au sein d'un VPC.

Pour réaliser davantage de segmentation de réseau privé entre les sous-réseaux VPC de votre compte, vous pouvez configurer des règles réseau personnalisées avec des listes de contrôle d'accès VPC. Lorsque vous créez un VPC, une liste de contrôle d'accès par défaut est créée au format allow-all-network-acl-<VPC_ID> pour le VPC. Les sous-réseaux que vous créez dans le VPC sont connectés à cette liste de contrôle d'accès par défaut. La liste de contrôle d'accès comprend une règle entrante et une règle sortante qui autorisent l'ensemble du trafic entre vos noeuds worker sur un sous-réseau et n'importe quel système sur les sous-réseaux dans le même VPC. Si vous souhaitez spécifier le trafic réseau privé qui est autorisé vers les noeuds worker présents sur vos sous-réseaux VPC, vous pouvez créer une liste de contrôle d'accès personnalisée pour chaque sous-réseau dans le VPC. Par exemple, vous pouvez créer un ensemble de règles ACL pour bloquer la plupart du trafic réseau entrant et sortant d'un cluster tout en autorisant la communication qui est nécessaire au bon fonctionnement du cluster.

Que puis-je faire d'autre pour réduire la surface d'attaque externe des clusters VPC?

Plus vous exposez d'applications et de noeuds worker au public, plus les étapes pour vous protéger contre les attaques malveillantes provenant de l'extérieur sont nombreuses. Consultez le tableau suivant pour identifier les options permettant de préserver la confidentialité de vos applications et de vos noeuds worker.

Selon le réseau auquel vous souhaitez connecter vos noeuds worker, vous pouvez choisir une solution VPN.

Exposition d'applications de manière sécurisée avec des routes

Si vous souhaitez autoriser le trafic réseau entrant provenant d'Internet, vous pouvez exposer vos applications à l'aide de routes.

Chaque cluster d' Red Hat OpenShift s est automatiquement configuré avec un routeur Red Hat OpenShift auquel est attribué un nom de domaine unique et sécurisé par un certificat TLS. Lorsque vous exposez votre application à l'aide d'une route, une URL est affectée à votre application depuis le routeur Red Hat OpenShift.

Lorsque vous créez une route pour votre application, vous pouvez décider de créer une route sécurisée (HTTPS) ou non sécurisée (HTTP). Pour les routes sécurisées, vous pouvez décider où implémenter la terminaison TLS, par exemple au niveau du routeur ou du pod. Pour plus d'informations, voir Exposition d'applications avec des routes.

Exposition d'applications de manière sécurisée avec des services LoadBalancer et Ingress

Vous pouvez utiliser les services de réseau d'équilibreur de charge de réseau (NLB) et d'équilibreur de charge d'application (ALB) Ingress pour connecter vos applications à l'Internet public ou à des réseaux privés externes. Consultez les paramètres facultatifs suivants pour les équilibreurs de charge de réseau et les équilibreurs de charge d'application que vous pouvez utiliser pour satisfaire les exigences en matière de sécurité des applications de back end ou chiffrer le trafic qui circule dans votre cluster.

Puis-je utiliser des groupes de sécurité pour gérer le trafic réseau de mon cluster?

Clusters classiques : les groupes de sécurité IBM Cloud sont appliqués à l'interface réseau d'un serveur virtuel unique pour filtrer le trafic au niveau de l'hyperviseur. Si vous souhaitez gérer le trafic de chaque noeud worker, vous pouvez utiliser des groupes de sécurité. Lorsque vous créez un groupe de sécurité, vous devez autoriser le protocole VRRP, lequel est utilisé par Red Hat OpenShift on IBM Cloud utilise pour gérer les adresses IP des équilibreurs de charge de réseau. Pour gérer de manière uniforme le trafic de votre cluster sur tous vos nœuds de travail, utilisez les stratégies Calico et Kubernetes.

Clusters VPC: les groupes de sécurité VPC sont appliqués à l'interface réseau d'un serveur virtuel unique pour filtrer le trafic au niveau de l'hyperviseur. Vous pouvez ajouter des règles entrantes et sortantes au groupe de sécurité par défaut de votre cluster pour gérer le trafic entrant et sortant sur un cluster de VPC. Pour plus d'informations, voir Comprendre la mise en réseau sécurisée par défaut des clusters VPC et Créer et gérer des groupes de sécurité VPC.

Étant donné que les nœuds de travail de votre cluster VPC existent dans un compte de service et ne sont pas répertoriés dans le tableau de bord de l'infrastructure VPC, vous ne pouvez pas créer un groupe de sécurité et l'appliquer à vos instances de noeud de travail. Vous pouvez uniquement modifier des groupes de sécurité existants créés pour vous.

Comment puis-je effectuer la terminaison TLS avec les services d' LoadBalancer s et d'entrée?

Le service Ingress offre des terminaisons TLS à deux points précis dans le flux de trafic :

• Décrypter le paquet à son arrivée : par défaut, l'ALB Ingress équilibre la charge du trafic réseau HTTP vers les applications de votre cluster. Pour équilibrer la charge des connexions HTTPS entrantes, vous pouvez configurer l'équilibreur de charge d'application pour déchiffrer le trafic réseau et transférer la demande déchiffrée aux applications exposées dans votre cluster. Si vous utilisez le sous-domaine Ingress fourni par IBM, vous pouvez utiliser le certificat TLS fourni par IBM. Si vous utilisez un domaine personnalisé, vous pouvez utiliser votre propre certificat TLS pour gérer la terminaison TLS.
• Chiffrer à nouveau le package avant de le transférer vers les applications en amont : l'équilibreur de charge d’application déchiffre les demandes HTTPS avant de transférer le trafic dans vos applications. Si vous disposez d'applications nécessitant HTTPS et que vous devez chiffrer le trafic avant son transfert vers ces applications en amont, vous pouvez utiliser l'annotation ssl-services. Si vos applications en amont peuvent traiter TLS, vous pouvez éventuellement fournir un certificat qui est inclus dans un secret TLS pour l'authentification unidirectionnelle ou mutuelle.

Dois-je configurer un cluster à locataire unique ou à locataires multiples?

Dans un cluster à service exclusif, vous créez un cluster pour tous les groupes de personnes qui doivent exécuter des charges de travail dans un cluster. En général, cette équipe est chargée de gérer le cluster en veillant à le configurer et à le sécuriser correctement. Les clusters à service partagé utilisent plusieurs projets pour isoler les titulaires et leurs charges de travail.

Le choix de l'option Cluster à service exclusif ou cluster à service partagé dépend du nombre d'équipes qui doivent exécuter des charges de travail dans un cluster, de leurs exigences en matière de service, de la taille du service et du niveau d'isolement que vous souhaitez atteindre pour vos charges de travail.

L'option Cluster à service exclusif peut vous convenir si vous disposez de nombreuses équipes avec des services complexes, chaque équipe devant contrôler le cycle de vie du cluster. Ce contrôle comprend la liberté de décider du moment opportun pour mettre à jour un cluster ou de choisir les ressources pouvant être déployées sur le cluster. Vous pouvez également configurer un cluster à service exclusif pour autoriser des pods privilégiés sans faire courir le risque à d'autres locataires d'être compromis. N'oubliez pas que la gestion d'un cluster nécessite une connaissance approfondie de Kubernetes, d'Red Hat OpenShift et de l'infrastructure afin de garantir la capacité du cluster et la sécurité de vos déploiements.

Les clusters à service partagé utilisent des projets Red Hat OpenShift pour isoler des locataires et sont habituellement gérés par une équipe distincte qui n'appartient pas à l'un des locataires. Un cluster à service partagé peut être approprié si plusieurs de vos équipes doivent exécuter de petites charges de travail dans un cluster et lorsque la création d'un cluster à service exclusif hautement disponible sur plusieurs zones ne vous permet pas de réaliser les économies souhaitées. Alors que les clusters à service partagé nécessitent en principe moins de personnes pour gérer et administrer le cluster, il se peut qu'ils ne fournissent pas le niveau d'isolement dont vous avez besoin et qu'ils induisent plus de complexité dans les domaines suivants :

• Accès : lorsque vous mettez en place plusieurs projets, vous devez configurer des règles RBAC adéquates pour chaque projet afin d'assurer l'isolement des ressources. Les règles RBAC sont complexes et nécessitent une connaissance approfondie de Kubernetes.
• Pods privilégiés : si un locataire dans un cluster à service partagé doit exécuter des pods privilégiés, ces pods peuvent accéder à d'autres projets dans le cluster ou endommager l'hôte de calcul partagé. Contrôler les pods privilégiés est une tâche complexe qui exige des efforts et des compétences techniques approfondies. Utilisez des contraintes de contexte de sécurité (SCC) pour contrôler les ressources que vos locataires peuvent déployer dans le cluster.
• Règles réseau : étant donné que vos noeuds worker sont connectés au même réseau privé, vous devez faire en sorte de mettre en place des règles réseau strictes afin d'empêcher les pods d'accéder aux pods situés dans d'autres espaces de noms.
• Limitation des ressources informatiques : afin de garantir que chaque équipe dispose des ressources nécessaires pour déployer des services et exécuter des applications dans le cluster, vous devez définir des quotas de ressources pour chaque espace de noms. Les quotas de ressources déterminent les contraintes de déploiement, telles que le nombre de ressources d' Kubernetes s que vous pouvez déployer et la quantité de CPU et de mémoire pouvant être consommée par ces ressources. Après avoir défini un quota, les utilisateurs doivent inclure des limites et des demandes de ressources dans leurs déploiements.
• Ressources de cluster partagées : si vous exécutez plusieurs titulaires dans un cluster, certaines ressources du cluster, comme par exemple le routeur Red Hat OpenShift, l'équilibreur de charge d'application (ALB) Ingress ou les adresses IP portables disponibles, sont partagées entre les différents titulaires. Des services plus petits peuvent avoir des difficultés à utiliser des ressources partagées s'ils se retrouvent en concurrence avec des services plus importants dans le cluster.
• Mises à jour : vous pouvez exécuter une seule version d'API Red Hat OpenShift à la fois. Toutes les applications qui s'exécutent dans un cluster doivent se conformer à la version d'API Red Hat OpenShift en cours indépendamment de l'équipe propriétaire de l'application. Lorsque vous souhaitez effectuer la mise à jour d'un cluster, vous devez veiller à ce que toutes les équipes soient prêtes à basculer vers une nouvelle version d'API Red Hat OpenShift et à ce que les applications soient mises à jour en conséquence. Cela signifie également que les équipes individuelles ont moins de contrôle sur la version d'API Red Hat OpenShift qu'elles souhaitent exécuter.
• Modifications de la configuration du cluster : si vous envisagez de modifier la configuration du cluster ou de replanifier des charges de travail sur de nouveaux noeuds worker, vous devez transférer les modifications aux différents titulaires. Ce transfert nécessite davantage de synchronisation et de tests par rapport à un cluster à service exclusif.
• Processus de communication : lorsque vous gérez plusieurs titulaires, pensez à configurer un processus de communication de sorte que les titulaires sachent à qui s'adresser en cas de problème avec le cluster ou quand ils ont besoin de ressources supplémentaires pour leurs services. Ce processus de communication suppose également d'informer vos titulaires de toutes les modifications effectuées dans la configuration du cluster, ainsi que des mises à jour planifiées.

Bien que le coût des clusters à service exclusif et des clusters à service partagé soit à peu près le même, les clusters à service exclusif fournissent un niveau d'isolement plus élevé que les projets inclus dans un cluster à service partagé. Pour obtenir un meilleur isolement de charge de travail, utilisez les clusters à service exclusif.

Les règles réseau Kubernetes protègent les pods du trafic réseau interne. Par exemple, si la plupart ou tous les gousses n'ont pas besoin d'accéder à des nacelles ou des services spécifiques, et que vous voulez vous assurer que les gousses par défaut ne peuvent pas accéder à ces gousses ou services, vous pouvez créer une stratégie de réseau Kubernetes pour bloquer le trafic de sortie vers ces gousses ou ces services. Les règles réseau Kubernetes peuvent également vous permettre d'appliquer l'isolement des charges de travail entre les espaces de noms en contrôlant la façon dont les pods et les services présents dans différents espaces de noms peuvent communiquer.

Comment puis-je contrôler les autorisations des pods?

Pour contrôler les droits de pod au sein ou entre des projets, Red Hat OpenShift on IBM Cloud utilise des contraintes de contexte de sécurité (SCC). Par défaut, chaque cluster est configuré avec des contraintes de contexte de sécurité Red Hat OpenShift et un ensemble de contraintes de contexte de sécurité fournies par IBM que vous pouvez affecter à des comptes de service, des pods, des déploiements ou des projets afin de limiter les droits au sein du cluster. Si vous n'affectez pas explicitement un SCC, vos gousses utilisent restricted SCC. Les SCC Red Hat OpenShift sont plus stricts que les stratégies de sécurité de pod par défaut dans les clusters Kubernetes de la communauté. Il peut être nécessaire de modifier une application qui s'exécute dans un cluster de communauté Kubernetes pour que cette application puisse s'exécuter dans Red Hat OpenShift. Pour plus d'informations, voir Configuration des contraintes de contexte de sécurité.

Que puis-je faire d'autre pour protéger mon conteneur?

Limitez le nombre de conteneurs privilégiés. Les conteneurs s'exécutent sous forme de processus Linux distinct sur l'hôte de calcul qui est isolé des autres processus. Bien que les utilisateurs disposent des droits d'accès de l'utilisateur root dans le conteneur, les droits de cet utilisateur sont limités en dehors du conteneur afin de protéger d'autres processus Linux, le système de fichiers hôte et les unités hôte. Certaines applications nécessitent l'accès au système de fichiers hôte ou des droits avancés pour fonctionner correctement. Vous pouvez exécuter des conteneurs en mode privilégié pour autoriser au conteneur le même accès que les processus qui s'exécutent sur l'hôte de calcul.

Tenez compte du fait que les conteneurs privilégiés peuvent causer des dommages considérables au cluster et à l'hôte de calcul sous-jacent, s'ils deviennent compromis. Essayez de limiter le nombre de conteneurs qui s'exécutent en mode privilégié et pensez à modifier la configuration de votre application pour qu'elle puisse s'exécuter sans droits avancés.

Pour bloquer l'exécution des conteneurs privilégiés dans votre cluster, envisagez la configuration de contraintes de contexte de sécurité personnalisées.

Appliquer les paramètres de sécurité du système d'exploitation aux pods

Vous pouvez personnaliser les contraintes de contexte de sécurité par défaut afin de contrôler l'ID utilisateur et l'ID groupe pouvant s'exécuter dans le conteneur, ou l'ID utilisateur et l'ID groupe propriétaires du chemin de montage du volume. La définition d'un ID utilisateur spécifique facilite le principe de modèle à moindre privilège. Si le contexte de sécurité ne spécifie pas d'utilisateur, Kubernetes utilise automatiquement l'utilisateur spécifié dans l'image du conteneur. Pour plus d'informations, voir Configuration des contraintes de contexte de sécurité.

Définir les limites d'UC et de mémoire des conteneurs

Tous les conteneurs nécessitent une quantité spécifique d'UC et de mémoire pour démarrer correctement et poursuivre leur exécution. Vous pouvez définir des plages limites pour vos conteneurs ou pods afin de limiter la quantité de CPU et de mémoire qu'ils peuvent consommer. Si aucune limite d'UC et de mémoire n'est définie et que le conteneur est occupé, le container utilise la totalité des ressources disponibles. Cette forte consommation de ressources peut affecter d'autres conteneurs sur le nœud worker qui n'ont pas suffisamment de ressources pour démarrer ou s'exécuter correctement et exposer votre nœud worker aux attaques de refus de service.