Comprendre la sécurisation par défaut du cluster VPC Mise en réseau

Cloud privé virtuel 4.15 et plus tard

À partir des nouveaux clusters VPC créés avec la version 4.15, Red Hat OpenShift on IBM Cloud a introduit une nouvelle fonction de sécurité appelée Secure by Default Cluster VPC Networking (mise en réseau sécurisée par défaut des clusters VPC). Avec Secure by Default, il existe de nouveaux paramètres VPC, tels que des groupes de sécurité gérés, des règles de groupe de sécurité et des passerelles de noeud final privé virtuel (VPE) qui sont créés automatiquement lorsque vous créez un cluster VPC. Examinez les détails suivants concernant les composants VPC qui sont créés et gérés pour vous lorsque vous créez un cluster à partir de la version 4.15.

Présentation

Avec Secure by Default Networking, lorsque vous mettez à disposition un nouveau cluster VPC Red Hat OpenShift on IBM Cloud version 4.15 ou ultérieure, seul le trafic nécessaire au fonctionnement du cluster est autorisé et tous les autres accès sont bloqués. Pour implémenter Secure by Default Networking, Red Hat OpenShift on IBM Cloud utilise divers groupes de sécurité et règles de groupe de sécurité pour protéger les composants de cluster. Ces groupes et règles de sécurité sont automatiquement créés et attachés à vos nœuds de travail, équilibreurs de charge et passerelles VPE liées aux clusters.

Les groupes de sécurité de cloud privé virtuel filtrent le trafic au niveau de l'hyperviseur. Les règles du groupe de sécurité ne sont pas appliquées dans un ordre particulier. Toutefois, les demandes adressées à vos noeuds worker ne sont autorisées que si la demande respecte l'une des règles que vous spécifiez. Lorsque vous autorisez le trafic dans une direction en créant une règle entrante ou sortante, les réponses sont également autorisées dans la direction opposée. Les groupes de sécurité sont additifs, ce qui signifie que si vos noeuds worker sont connectés à plusieurs groupes de sécurité, toutes les règles incluses dans les groupes de sécurité sont appliquées aux noeuds worker. Les versions de cluster plus récentes peuvent comporter plus de règles dans le groupe de sécurité kube-<clusterID> que les versions de cluster plus anciennes. Des règles de groupe de sécurité sont ajoutées pour améliorer la sécurité du service et ne pas interrompre la fonctionnalité.

Passerelles pour points d'extrémité privés virtuels (VPE)

Lorsque le premier cluster de VPC dans Red Hat OpenShift on IBM Cloud 4.14+ est créé dans un VPC donné ou qu'un cluster dans ce VPC a son maître mis à jour vers 4.14+, plusieurs passerelles VPE partagées sont créées pour divers services IBM Cloud. Un seul de ces types de passerelles VPE partagées est créé par VPC. Tous les clusters du VPC partagent la même passerelle VPE pour ces services. Ces passerelles VPE partagées se voient affecter une seule adresse IP réservée de chaque zone dans laquelle se trouvent les agents de cluster.

Passerelles VPE partagées

Les passerelles VPE suivantes sont créées automatiquement lorsque vous créez un cluster VPC.

Passerelles VPE partagées
Le tableau montre les passerelles VPE créées pour les clusters VPC. La première colonne contient le nom de la passerelle. La deuxième colonne contient une brève description. La troisième colonne comprend les noms DNS.
Passerelle VPE	Description	noms DNS
IBM Cloud Container Registry	Tirez des images de conteneurs de IBM Cloud Container Registry vers des applications exécutées dans votre cluster.	`icr.io`, `*.icr.io`
Passerelle IBM Cloud Object Storage s3	Accédez aux API de IBM Cloud Object Storage.	`s3.direct.<region>.cloud-object-storage.appdomain.cloud`, `*.s3.direct.<region>.cloud-object-storage.appdomain.cloud`
Passerelle de configuration IBM Cloud Object Storage	Sauvegarde des images de conteneurs sur IBM Cloud Object Storage	`config.direct.cloud-object-storage.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (ca-mon, in-che, in-mum)	Accédez aux API Red Hat OpenShift on IBM Cloud pour créer des clusters, ajouter des pools de travailleurs, etc.	`private.<region>.containers.cloud.ibm.com`
Red Hat OpenShift on IBM Cloud (autres régions)	Accédez aux API Red Hat OpenShift on IBM Cloud pour créer des clusters, ajouter des pools de travailleurs, etc.	`api.<region>.containers.cloud.ibm.com`
IBM Cloud VPC	Accéder aux API VPC pour provisionner et gérer les ressources qui font partie de l'infrastructure VPC en tant que service ( IaaS ).	`<region>.private.iaas.cloud.ibm.com`

Passerelles VPE non partagées

Tous les clusters VPC pris en charge disposent d'une passerelle VPE pour le maître du cluster, qui est créée dans votre compte lors de la création du cluster.

Passerelles VPE non partagées
Le tableau montre les passerelles VPE créées pour les clusters VPC. La première colonne contient le nom de la passerelle. La deuxième colonne contient une brève description.
Passerelle VPE	Description
Red Hat OpenShift on IBM Cloud maître de la grappe	Cette passerelle VPE est utilisée par les agents de cluster et peut être utilisée par d'autres éléments dans le VPC pour se connecter au serveur d'API maître du cluster. Cette passerelle VPE se voit attribuer une seule IP réservée de chaque zone dans laquelle se trouvent les travailleurs de la grappe, et cette IP est créée dans l'un des sous-réseaux VPC de cette zone où se trouvent les travailleurs de la grappe. †

† Par exemple, si le cluster a des travailleurs dans une seule région de zone (us-east-1) et un seul sous-réseau VPC, une seule IP est créée dans ce sous-réseau et attribuée à la passerelle VPE. Si un cluster comporte des noeuds worker dans les trois zones telles que us-east-1, us-east-2 et us-east-3 et que ces noeuds worker sont répartis entre 4 sous-réseaux VPC dans chaque zone, 12 sous-réseaux VPC sont créés, trois adresses IP sont créées, une dans chaque zone, dans l'un des quatre sous-réseaux VPC de cette zone. Notez que le sous-réseau est choisi de manière aléatoire.

Groupes de sécurité gérés

Red Hat OpenShift on IBM Cloud crée et met à jour automatiquement les groupes de sécurité et les règles suivants pour les clusters de VPC.

Groupes de sécurité gérés
Le tableau présente les groupes de sécurité gérés créés pour les clusters VPC. La première colonne comprend le nom du groupe de sécurité. La deuxième colonne comprend la convention d'appellation.
Groupe de sécurité	Convention de dénomination
Groupe de sécurité des travailleurs	`kube-<clusterID>`
Groupe de sécurité de la passerelle VPE maître	`kube-vpegw-<clusterID>`
Groupe de sécurité de la passerelle VPE partagée	`kube-vpegw-<vpcID>`
Groupe de sécurité des services d'équilibrage de charge	`kube-lbaas-<clusterID>`

Groupe de sécurité de l'agent

Lorsque vous créez un cluster VPC Red Hat OpenShift on IBM Cloud, un groupe de sécurité est créé pour tous les travailleurs, ou nœuds, du cluster en question.

Le nom du groupe de sécurité est kube-<clusterID>, où <clusterID> est l'ID du cluster.
Si de nouveaux noeuds sont ajoutés au cluster ultérieurement, ils sont ajoutés automatiquement au groupe de sécurité du cluster.
Les règles sont ajoutées ou supprimées dynamiquement en fonction des besoins des répartiteurs de charge.
Les règles ajoutées dans la plage de ports du nœud sont automatiquement supprimées si elles ne sont pas nécessaires. Si les clients souhaitent autoriser le trafic entrant vers un service de port de nœud, vous devez ajouter la règle d'autorisation du trafic après avoir créé le service de port de nœud.
Ne modifiez pas les règles du groupe de sécurité kube-<clusterID> car cela pourrait entraîner des interruptions de la connectivité du réseau entre les noeuds worker du cluster et le cluster de contrôle.

Règles du groupe de sécurité kube-clusterID
Le tableau présente les règles appliquées au groupe de sécurité cluster
Description	Direction	Protocole	Ports ou valeurs	Source ou destination
Autorise le trafic entrant vers le sous-réseau de pod.	Entrant	ICMP/ TCP / UDP	Tous	172.17.0.0/18 (plage de sous-réseaux par défaut) ou une plage de sous-réseaux personnalisée que vous spécifiez lorsque vous créez votre cluster.
Autorise l'accès entrant à soi-même, ce qui permet la communication entre les noeuds worker.	Entrant	ICMP/ TCP / UDP	Tous	`kube-<clusterID>`
Autorise l'accès ICMP (ping) entrant.	Entrant	ICMP	type=8	0.0.0.0/0
Permet le trafic entrant à partir des nœuds ouverts par vos équilibreurs de charge (ALBs/NLBs). Lorsque des équilibreurs de charge sont ajoutés ou supprimés, des règles sont ajoutées ou supprimées de manière dynamique.	Entrant	TCP	Ports de noeud de l'équilibreur de charge.	`kube-lbaas-<clusterID>`
Autorise le trafic sortant vers le sous-réseau de pod.	Sortant	ICMP/ TCP / UDP	Tous	172.17.0.0/18 (plage de sous-réseaux par défaut) ou une plage de sous-réseaux personnalisée que vous spécifiez lorsque vous créez votre cluster.
Autorise le trafic sortant vers le plan de contrôle maître, ce qui permet aux agents d'être mis à disposition.	Sortant	ICMP/ TCP / UDP	Tous	161.26.0.0/16
Autorise l'accès sortant à soi-même, ce qui permet la communication entre les noeuds worker.	Sortant	ICMP/ TCP / UDP	Tous	`kube-<clusterID>`
Autorise le trafic sortant vers le groupe de sécurité de la passerelle VPE maître.	Sortant	ICMP/ TCP / UDP	Tous	`kube-vpegw-<clusterID>`
Autorise le trafic sortant vers le groupe de sécurité de la passerelle VPE partagée.	Sortant	ICMP/ TCP / UDP	Tous	`kube-vpegw-<vpcID>`
Autorise le trafic vers le noeud final public via le port oauth pour toutes les zones de la région MZR où se trouve le cluster.`*`	Sortant	TCP	Port Oauth	Adresses IP de noeud final public pour toutes les zones de la région multizone.
Autorise le trafic TCP à travers l'ALB d'entrée	Sortant	TCP	Ports:Min=443,Max=443	Adresse IP publique ALB `n`
Autorise le trafic TCP et UDP via un résolveur DNS personnalisé pour la zone `n`.`**`	Sortant	TCP/UDP	Min=53,Max=53	Adresse IP du programme de résolution DNS dans la zone `n`.
Autorise le trafic vers l'ensemble de la plage de services CSE.	Sortant	ICMP/ TCP / UDP	Tous	166.8.0.0/14
Autorise le trafic vers le noeud final privé IAM pour toutes les zones. Les adresses IP peuvent varier en fonction de la région. Une règle est ajoutée par zone dans laquelle se trouve le cluster.	Sortant	ICMP/ TCP / UDP	Tous	Adresse IP de noeud final privé IAM pour toutes les zones.
Autorise le trafic sortant vers l'API des métadonnées d'instance.	Sortant	ICMP/ TCP / UDP	Tous	169.254.169.254
4.18 et versions ultérieures Autorise le trafic sortant vers l'API de métadonnées d'instance.	Sortant	ICMP/ TCP / UDP	Tous	169.254.169.254

* Ces règles ne sont ajoutées qu'aux clusters dont les terminaux de service public sont activés pour permettre l'accès à la console web OpenShift et au terminal public via le port OAuth. Une règle est ajoutée pour chaque zone de la région multizone (MZR) où se trouve le cluster. Si votre cluster se trouve dans une région multizone avec 3 zones, trois règles sont créées.

Les VPC ** Hub et Spoke utilisent des programmes de résolution DNS personnalisés sur le VPC. Le trafic doit passer par les adresses IP de chaque programme de résolution DNS. Il y a deux règles par zone ( TCP et UDP ) via le port 53.

Groupe de sécurité de passerelle VPE maître

Lorsque vous créez un cluster VPC, une passerelle VPE (Virtual Private Endpoint) est créée dans le même VPC que le cluster. Le nom de la sécurité est kube-vpegw-<clusterID> où <clusterID> est l'ID du cluster. L'objectif de cette passerelle VPE est de servir de passerelle vers le maître du cluster qui est géré par IBM Cloud. Une adresse IP unique est affectée à la passerelle VPE dans chaque zone du VPC dans lequel le cluster a des noeuds worker.

Pour autoriser l'accès au maître d'un cluster uniquement à partir de ses noeuds worker, un groupe de sécurité est créé pour chaque passerelle VPE maître de cluster. Une règle distante est ensuite créée pour permettre la connectivité Ingress entre le groupe de sécurité de l'agent de cluster et les ports requis sur la passerelle VPE maître du cluster. Pour que les connexions privées, y compris les connexions provenant d'un VPC VPN, se connectent à la passerelle VPE du point de terminaison du service privé de la grappe, le trafic TCP est autorisé à partir des CIDR de sous-réseau pour chaque pool de travailleurs actif de votre grappe.

Règles d'entrée dans le groupe de sécurité de la passerelle VPE maître
Le tableau présente les règles de réception appliquées au groupe de sécurité du travailleur en grappe. La première colonne inclut l'objectif de la règle. La deuxième colonne contient la direction de la règle. La troisième colonne inclut le protocole. La quatrième colonne contient les ports ou les valeurs. La cinquième colonne indique la destination à distance de la règle.
Description	Direction	Protocole	Ports ou valeurs	Source ou destination
Autorise le trafic entrant du groupe de sécurité d'agent de cluster vers le port de noeud du serveur.	Entrant	TCP	Serveur URL port du nœud	`kube-<clusterID>`
Autorise le trafic entrant du groupe de sécurité d'agent de cluster vers le port openVPN ou Konnectivité.	Entrant	TCP	Port de konnectivité	`kube-<clusterID>`
Autorise le trafic entrant du groupe de sécurité des agents de cluster vers le port Oauth.	Entrant	TCP	Port Oauth	`kube-<clusterID>`
CoreOS-enabled uniquement. Autorise le trafic entrant du groupe de sécurité des agents de cluster vers le port du serveur d'allumage	Entrant	TCP	Port du serveur Ignition	`kube-<clusterID>`
Autorise le trafic entrant à partir du sous-réseau de chaque pool de travailleurs actif dans votre cluster.`*`	Entrant	TCP	Serveur URL port du nœud	CIDR de sous-réseau
Autorise le trafic entrant à partir du sous-réseau de chaque pool de travailleurs actif dans votre cluster.`*`	Entrant	TCP	OAuth port	CIDR de sous-réseau

* Une règle est ajoutée pour le sous-réseau de chaque groupe de travailleurs actif. Si vous avez des travailleurs dans trois zones, trois règles seront ajoutées (une pour chaque sous-réseau dans cette zone).

Groupe de sécurité de passerelle VPE partagée

Les passerelles VPE partagées sont créées lorsque le premier cluster d'un VPC est approvisionné. Le groupe de sécurité de la passerelle VPE partagée est créé lorsque vous créez un cluster (s'il n'existe pas déjà dans les clusters précédents). Le nom du groupe de sécurité est kube-vpegw-<vpcID> où <vpcID> est l'ID de votre VPC. Une règle distante est ensuite créée pour permettre la connectivité Ingress à partir du groupe de sécurité d'agent de cluster pour le cluster donné. Le groupe de sécurité de passerelle VPE partagée contient les passerelles VPE qui sont partagées par tous les clusters de ce VPC. Des passerelles VPE partagées pourront être ajoutées dans les versions ultérieures pour permettre des connexions à d'autres services IBM Cloud.

Si ce groupe de sécurité de passerelle VPE partagée existe déjà lorsqu'un cluster est mis à disposition, il est reconnu par le processus de mise à disposition et n'est pas recréé. Toutefois, une règle distante est toujours ajoutée entre le groupe de sécurité de passerelle VPE partagé existant et le nouveau groupe de sécurité d'agent. Cela permet d'autoriser la connectivité à partir de tous les clusters du VPC donné. Une règle est créée pour chaque cluster dans le VPC.

Un maximum de 15 règles peuvent cibler d'autres groupes de sécurité en tant que source ou destination. Par défaut, Red Hat OpenShift on IBM Cloud applique une règle qui cible le groupe de sécurité kube-<clusterID> pour chaque cluster dans le VPC. En raison de ce quota, seuls 15 clusters peuvent être créés dans un VPC donné. Pour plus d'informations, voir Quotas VPC.

Règles entrantes dans le groupe de sécurité de la passerelle VPE partagée
Le tableau présente les règles de réception appliquées au groupe de sécurité de la passerelle VPE partagée. La première colonne comprend l'objectif de la règle. La deuxième colonne contient la direction de la règle. La troisième colonne inclut le protocole. La quatrième colonne indique la destination à distance de la règle.
Description	Direction	Protocole	Source ou destination
Autorise le trafic entrant à partir du cluster spécifié.	Entrant	TCP	`kube-<clusterID>`

Groupe de sécurité des services d'équilibreur de charge

Groupe de sécurité par défaut associé à tous les équilibreurs de charge (équilibreurs de charge d'application et équilibreurs de charge de réseau).

Chaque cluster obtient son propre groupe de sécurité unique qui est partagé par tous les équilibreurs de charge du cluster.
Le nom du groupe de sécurité est kube-lbaas-<clusterID> où <clusterID> est l'ID de votre cluster.
Les règles de ce groupe de sécurité sont ajoutées ou supprimées dynamiquement lorsque des équilibreurs de charge sont ajoutés, supprimés ou mis à jour. Notez que les SDNLB ne prennent pas en charge l'association de groupes de sécurité.
Vous pouvez ajouter des règles à ce groupe de sécurité. Toutefois, certaines règles peuvent être supprimées si elles sont incompatibles avec les autres règles ou si elles nuisent à la fonctionnalité.

Règles du groupe de sécurité de l'équilibreur de charge
Le tableau montre les règles appliquées au groupe de sécurité de l'équilibreur de charge. La première colonne inclut l'objectif de la règle. La deuxième colonne contient la direction de la règle. La troisième colonne inclut le protocole. La quatrième colonne contient les ports ou les valeurs. La cinquième colonne indique la destination à distance de la règle.
Description	Direction	Protocole	Port ou valeur	Source ou destination
Autorise l'accès sortant au port de noeud ouvert par l'équilibreur de charge. En fonction de l'équilibreur de charge, vous pouvez avoir plusieurs règles.	Sortant	TCP	Port (s) Node ouvert (s) par l'équilibreur de charge.	`kube-<clusterID>`
L'équilibreur de charge écoute sur le port 80 en autorisant l'accès entrant à partir de ce port.	Entrant	TCP	Port LB public. Exemple `80`	0.0.0.0/0
L'équilibreur de charge écoute sur le port 443 en autorisant l'accès entrant à partir de ce port.	Entrant	TCP	Port LB public. Exemple `443`	0.0.0.0/0

Fourni par l'utilisateur Security Groups

Lorsque vous créez un cluster VPC, vous pouvez fournir jusqu'à quatre groupes de sécurité supplémentaires dont vous êtes propriétaire.

Pour plus d'informations, voir Création et gestion des groupes de sécurité VPC.

Limitations

Groupes de sécurité de noeud worker

É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 nœuds de travail. Vous ne pouvez modifier que le groupe de sécurité kube-<clusterID> existant.

Journalisation et surveillance

Lors de la configuration de la journalisation et de la surveillance sur un cluster 4.15 ou version ultérieure, vous devez utiliser le noeud final de service privé lors de l'installation de l'agent de journalisation dans votre cluster. Les données de journal ne sont pas sauvegardées si le noeud final public est utilisé.

Surveillance des clusters avec des noeuds worker RHCOS

L'agent de surveillance s'appuie sur les en-têtes de noyau du système d'exploitation, mais RHCOS ne possède pas d'en-têtes de noyau. Dans ce scénario, l'agent revient à sysdig.com pour utiliser l'agent précompilé. Dans les clusters sans accès au réseau public, ce processus échoue. eBPF est désormais activé par défaut pour les nouveaux déploiements de Sysdig. Toutefois, si vous rencontrez des problèmes sur un cluster existant, vérifiez si eBPF est activé et activez-le si nécessaire. Vous pouvez également autoriser le trafic sortant ou consulter la documentation de Sysdig pour l'installation de l'agent dans des environnements à air comprimé.

Quotas de cluster VPC

Chiffrement en transit pour VPC File Storage.

Pour utiliser l'EIT avec les clusters Secure by Default, vous devez ajouter la règle de sortie suivante au groupe de sécurité kube-<clusterID>.

Protocole: Tous
Type de source: Tout
Source: 0.0.0.0/0
Destination 169.254.169.254.

Communication de sauvegarde sur le réseau public

Les agents de cluster VPC utilisent le réseau privé pour communiquer avec le maître cluster. Auparavant, pour les clusters de VPC pour lesquels le noeud final de service public était activé, si le réseau privé était bloqué ou indisponible, les agents de cluster pouvaient utiliser le réseau public pour communiquer avec le maître cluster. Dans les clusters Secure by Default, le retour au réseau public n'est pas une option car le trafic sortant public des noeuds worker du cluster est bloqué. Vous souhaiterez peut-être désactiver la protection du trafic sortant pour autoriser cette option de sauvegarde du réseau public, mais il existe une meilleure alternative. A la place, en cas de problème temporaire avec la connexion entre l'agent et le maître sur le réseau privé, vous pouvez alors ajouter une règle de groupe de sécurité temporaire au groupe de sécurité kube-clusterID pour autoriser le trafic sortant vers le port apiserver du maître cluster. Par la suite, une fois le problème résolu, vous pouvez supprimer la règle temporaire.

Chiffrement OpenShift Data Foundation et Portworx

Si vous prévoyez d'utiliser OpenShift Data Foundation ou Portworx dans un cluster sans accès au réseau public et que vous souhaitez utiliser Hyper Protect Crypto Services ou Key Protect pour le chiffrement, vous devez créer une passerelle de noeud final privé virtuel (VPE) qui autorise l'accès à votre instance KMS. Veillez à lier au moins une adresse IP de chaque sous-réseau de votre VPC au VPE.