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

Virtual Private Cloud 1.30 and later

À partir des nouveaux clusters VPC créés avec la version 1.30, IBM Cloud Kubernetes Service 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 points d'extrémité virtuels (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 1.30.

Présentation

Avec Secure by Default Networking, lorsque vous mettez à disposition un nouveau cluster IBM Cloud Kubernetes Service VPC version 1.30 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, IBM Cloud Kubernetes Service utilise divers groupes de sécurité et règles de groupe de sécurité pour protéger les composants de cluster. Ces groupes de sécurité et ces règles sont créés automatiquement et associés à vos nœuds de travail, à vos équilibreurs de charge et aux passerelles VPE liées au cluster.

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 VPE (Virtual Private Endpoint)

Lorsque le premier cluster de VPC dans IBM Cloud Kubernetes Service 1.28+ est créé dans un VPC donné ou qu'un cluster dans ce VPC a son maître mis à jour vers 1.28+, 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 de 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 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`
IBM Cloud Kubernetes Service (ca-mon, in-che, in-mum)	Accédez aux API IBM Cloud Kubernetes Service pour créer des clusters, ajouter des pools de travailleurs, etc.	`private.<region>.containers.cloud.ibm.com`
IBM Cloud Kubernetes Service (autres régions)	Accédez aux API IBM Cloud Kubernetes Service 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
IBM Cloud Kubernetes Service 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.

Accès à la passerelle VPE du maître de cluster depuis un autre VPC

La passerelle VPE du maître de cluster est utilisée par les nœuds de travail du cluster et par toute ressource située dans le même VPC pour accéder au serveur API du maître de cluster via le réseau privé. Si vous devez vous connecter au maître de cluster en mode privé depuis un autre VPC du même compte, vous pouvez créer une passerelle VPE supplémentaire dans cet autre VPC, ciblant le même maître de cluster.

Pour ce faire, utilisez le CRN cible de la passerelle VPE maître du cluster créée par IBM Cloud Kubernetes Service. Vous devez fournir vos propres adresses IP réservées pour la nouvelle passerelle, et vous devez créer et gérer le groupe de sécurité ainsi que ses règles. Les règles de sortie sur une passerelle VPE n'ont aucun effet : seules les règles d'entrée sont évaluées. IBM Cloud Kubernetes Service ne gère ni ne modifie la passerelle VPE ou le groupe de sécurité que vous créez.

Groupes de sécurité gérés

IBM Cloud Kubernetes Service 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 IBM Cloud Kubernetes Service, 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.
IBM Cloud Kubernetes Service surveille uniquement les règles TCP et UDP entrantes dans la plage de ports du nœud du groupe de sécurité kube-<clusterID>. Si IBM Cloud Kubernetes Service détecte une règle dans la plage de ports de nœud et qu'il n'existe aucun service de port de nœud correspondant, il supprime la règle. Pour autoriser le trafic entrant vers un service de port de nœud, ajoutez la règle requise au groupe de sécurité kube-<clusterID> après la création du service de port de nœud, et non avant.
Les règles supplémentaires que vous ajoutez au groupe de sécurité kube-<clusterID> en dehors de la plage de ports du nœud sont ignorées par IBM Cloud Kubernetes Service et restent en place.
Ne modifiez ni ne supprimez pas les règles par défaut du groupe de sécurité kube-<clusterID>, car cela pourrait entraîner des perturbations dans la connectivité réseau entre les nœuds de travail du cluster et le plan 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
Autorise 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 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.
1.33 and later Autorise le trafic sortant vers l'API des métadonnées de l'instance.	Sortant	ICMP/ TCP / UDP	Tous	169.254.169.254
4.18 and later Autorise le trafic sortant vers l'API des métadonnées de l'instance.	Sortant	ICMP/ TCP / UDP	Tous	169.254.169.254

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. La passerelle VPE se voit affecter une adresse IP unique 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é de la passerelle VPE maître. La première colonne inclut le protocole de la règle. La deuxième colonne contient les ports et les types. La troisième colonne inclut la destination distante de la règle. La quatrième colonne comprend une brève description de la règle.
Description	Direction	Protocole	Ports ou valeurs	Source ou destination
Autorisez le trafic entrant du groupe de sécurité de l'agent de cluster vers le port de noeud du serveur.	Entrant	TCP	Serveur URL port du nœud	`kube-<clusterID>`
Autorisez le trafic entrant du groupe de sécurité d'agent de cluster vers le port de konnectivité.	Entrant	TCP	Port de konnectivité	`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

* 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

Le groupe de sécurité de la passerelle VPE partagée est créé lorsque vous provisionnez le premier cluster dans un VPC. Le nom du groupe de sécurité est kube-vpegw-<vpcID> où correspond <vpcID> à l'ID de votre VPC. Ce groupe de sécurité est associé à toutes les passerelles VPE partagées du VPC et contrôle quelles ressources sont autorisées à envoyer du trafic via ces passerelles.

À chaque fois qu’un cluster supplémentaire est provisionné dans le même VPC, une seule règle de trafic entrant à distance est ajoutée à ce groupe de sécurité, autorisant le trafic provenant du groupe de sécurité des workers kube-<clusterID> du nouveau cluster. Une règle est créée pour chaque cluster dans le VPC. Si le groupe de sécurité kube-vpegw-<vpcID> existe déjà lors de la mise en place d'un cluster, il est reconnu et réutilisé — il n'est pas recréé.

Chaque création de cluster ajoute également des groupes de sécurité, et un VPC prend en charge un maximum de 100 groupes de sécurité. Cette limite est atteinte à partir d’environ 33 clusters; il est donc recommandé de ne pas dépasser 25 clusters par VPC. Pour plus d'informations, consultez la section 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 indique 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>`

Vous pouvez ajouter des règles d'entrée au groupe de sécurité kube-vpegw-<vpcID>, par exemple pour autoriser les VSI ou d'autres ressources de votre VPC à accéder aux passerelles VPE partagées. IBM Cloud Kubernetes Service ne supprime pas les règles que vous ajoutez lors des opérations normales du cluster, y compris lorsque des clusters supplémentaires sont provisionnés dans le VPC. Pour savoir comment autoriser les VSI à accéder aux passerelles VPE partagées, consultez la rubrique Pourquoi mes VSI ne peuvent-ils pas accéder à la passerelle VPE?.

L'exécution de cette commande supprime ibmcloud ks security-group reset toutes les règles du groupe de sécurité, y compris celles que vous avez ajoutées, et ne rétablit que les règles par défaut IBM Cloud Kubernetes Service.

Si votre VPC contient des VSI ou d’autres ressources qui doivent accéder à des points de terminaison de services cloud partagés (tels que icr.io ou s3.direct) avant le provisionnement d’un cluster, vous pouvez créer vous-même le groupe de sécurité kube-vpegw-<vpcID> et les passerelles VPE partagées. Lorsqu'un cluster IBM Cloud Kubernetes Service est ensuite provisionné dans le VPC, il détecte le groupe de sécurité existant et le réutilise, puis ajoute une nouvelle règle entrante pour le groupe de sécurité des nœuds de travail du nouveau cluster.

Lorsque vous créez vous-même une passerelle VPE partagée, associez-lui le groupe de sécurité kube-vpegw-<vpcID>. IBM Cloud Kubernetes Service n'associe pas automatiquement son groupe de sécurité aux passerelles qu'il n'a pas créées.

IBM Cloud Kubernetes Service identifie les passerelles VPE partagées qu'il gère grâce à leur préfixe de nom. Les passerelles créées par IBM Cloud Kubernetes Service respectent la convention de nommage iks-. Les passerelles VPE partagées et le groupe de sécurité kube-vpegw-<vpcID> ne sont pas supprimés lorsqu’un cluster est retiré du VPC. IBM Cloud Kubernetes Service ne modifie pas les adresses IP réservées des passerelles VPE partagées qu’il n’a pas créées. Si vous renommez une passerelle créée par IBM Cloud Kubernetes Service (en supprimant le iks- préfixe), IBM Cloud Kubernetes Service cesse de gérer les adresses IP réservées de cette passerelle. Voici la procédure recommandée pour prendre en charge une passerelle créée par IBM Cloud Kubernetes Service sans perturber la connectivité existante.

Dans une configuration VPC de type hub and spoke où les VPC spoke délèguent la résolution DNS à un VPC hub, IBM Cloud Kubernetes Service crée toujours des passerelles VPE partagées dans le VPC spoke lorsqu’un cluster y est provisionné. Cela garantit la connectivité si jamais le spoke venait à être déconnecté du hub. Si la délégation DNS achemine les points de terminaison spoke via le hub, les passerelles spoke ne sont pas utilisées pour la résolution DNS. Vous devez encore configurer les groupes de sécurité sur les passerelles VPE partagées du hub afin d'autoriser le trafic entrant provenant des sous-réseaux VPC des spokes. Pour plus d'informations, consultez la section Considérations relatives aux VPC de type hub and spoke avec protection du trafic sortant.

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

Chaque cluster dispose d’un groupe de sécurité kube-lbaas-<clusterID> associé à tous ses équilibreurs de charge (ALB et NLB). Les NLB Private Path ne prennent pas en charge l'association de groupes de sécurité.

Les règles de ce groupe de sécurité sont générées et mises à jour de manière dynamique à mesure que des équilibreurs de charge sont ajoutés, mis à jour ou supprimés. IBM Cloud Kubernetes Service surveille toutes les règles entrantes et sortantes de ce groupe de sécurité et supprime automatiquement toute règle superflue qu'il ne reconnaît pas comme nécessaire. Si vous exécutez ibmcloud ks security-group reset, toutes les règles sont supprimées et seules les règles par défaut IBM Cloud Kubernetes Service sont restaurées.

Les règles sortantes de ce groupe de sécurité acheminent le trafic vers les ports des nœuds de travail auxquels les ports externes (tels que les ports 80 et 443) sont mappés. Ne modifiez ni ne supprimez aucune règle sortante dans le groupe de sécurité kube-lbaas-<clusterID>.

Restriction du trafic entrant vers les équilibreurs de charge publics

Un scénario courant consiste à restreindre les adresses IP sources autorisées à envoyer du trafic vers un équilibreur de charge public. Pour limiter le trafic entrant sur un port spécifique (tel que le port TCP 443):

Ajoutez des règles d'entrée au groupe de sécurité kube-lbaas-<clusterID> correspondant à ce port en spécifiant les adresses IP source ou les blocs CIDR autorisés. Vous pouvez créer plusieurs règles pour autoriser plusieurs adresses IP sources.
Une fois vos règles d'adresses IP sources autorisées créées, supprimez la règle entrante par défaut qui autorise toutes les adresses IP (0.0.0.0/0) sur ce port.

Chaque port entrant exposé par l'équilibreur de charge doit disposer d'au moins une règle : soit la règle par défaut autorisant toutes les adresses IP, soit une ou plusieurs règles personnalisées relatives aux adresses IP sources. Si vous supprimez la règle par défaut autoriser toutes les adresses IP sans avoir préalablement ajouté une règle d'autorisation d'adresse IP source pour ce port, IBM Cloud Kubernetes Service recrée automatiquement la règle autoriser toutes les adresses IP.

Groupes de sécurité LBaaS personnalisés

Si vous disposez à la fois d’équilibreurs de charge publics et privés et que vous souhaitez appliquer des règles de pare-feu différentes à chacun d’entre eux (par exemple, restreindre les adresses IP sources pour les équilibreurs de charge publics tout en autorisant tout le trafic vers les équilibreurs de charge privés), vous pouvez associer un groupe de sécurité personnalisé à des équilibreurs de charge spécifiques à l’aide de l’annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group au lieu d’utiliser le groupe de sécurité par défaut du cluster.

Lorsque vous utilisez un groupe de sécurité LBaaS personnalisé :

IBM Cloud Kubernetes Service continue de créer automatiquement toutes les règles de trafic entrant requises qui manquent.
IBM Cloud Kubernetes Service ne supprime jamais les règles que vous ajoutez au groupe de sécurité personnalisé.

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.

Vous pouvez également associer un groupe de sécurité personnalisé à un équilibreur de charge en ajoutant l'annotation service.kubernetes.io/ibm-load-balancer-cloud-provider-vpc-security-group à votre ressource d'équilibreur de charge. Cette fonctionnalité est utile si vous disposez à la fois d'équilibrateurs de charge publics et privés et que vous souhaitez limiter les utilisateurs autorisés à envoyer du trafic vers l'équilibrateur de charge public. Lorsque vous utilisez un groupe de sécurité LBaaS personnalisé, IBM Cloud Kubernetes Service crée automatiquement des règles pour le trafic entrant, mais ne supprime pas automatiquement les règles supplémentaires que vous ajoutez. Pour plus d'informations, consultez la section Groupes de sécurité LBaaS personnalisés.

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 figurent pas dans le tableau de bord de l'infrastructure VPC, vous ne pouvez pas créer de groupe de sécurité ni 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 1.30 ou ultérieur, 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 dans le système d'exploitation, mais RHCOS ne dispose 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

Chaque création de cluster ajoute des groupes de sécurité à votre VPC, qui peut en compter jusqu'à 100. Cette limite est atteinte à partir d’environ 33 clusters; il est donc recommandé de ne pas dépasser 25 clusters par VPC. Pour plus d'informations, consultez la section Quotas 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: au choix
Type de source: tout
Source: 0.0.0.0/0
169.254.169.254de destination.

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 agents de 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. En cas de problème temporaire avec la connexion worker-to-master 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.