Apportez votre propre groupe de sécurité réseau (NSG) à un cluster Azure Red Hat OpenShift (ARO)

2025-04-30

En règle générale, lors de la configuration d’un cluster ARO, vous devez désigner un groupe de ressources pour le déploiement de l’objet de cluster ARO (appelé groupe de ressources de base dans le diagramme suivant). Dans de tels scénarios, vous pouvez utiliser le même groupe de ressources pour le réseau virtuel (VNET) et le cluster, ou vous pouvez opter pour un groupe de ressources distinct uniquement pour le réseau virtuel. Aucun de ces groupes de ressources ne correspond directement à un seul cluster ARO, vous accordant un contrôle total sur ces groupes de ressources. Cela signifie que vous pouvez créer, modifier ou supprimer librement des ressources au sein de ces groupes de ressources.

Pendant le processus de création du cluster, le fournisseur de ressources ARO (RP) établit un groupe de ressources dédié spécifique aux besoins du cluster. Ce groupe héberge différentes ressources spécifiques au cluster, telles que les machines virtuelles de nœud, les équilibreurs de charge et les groupes de sécurité réseau (NSG), comme illustré par le groupe de ressources managé dans le diagramme suivant. Le groupe de ressources gérées est étroitement sécurisé, interdisant toute modification de son contenu, y compris le groupe de sécurité réseau lié aux sous-réseaux du VNET spécifiés lors de la création du cluster. Dans certains cas, le groupe de sécurité réseau généré par le RP ARO peut ne pas adhérer aux politiques de sécurité de certaines organisations.

Cet article montre comment utiliser la fonctionnalité « bring your own » Network Security Group (NSG) pour attacher votre propre groupe de sécurité réseau préconfiguré résidant dans le groupe de ressources de base/réseau virtuel (RG) (illustré dans le diagramme suivant en tant que BYO-NSG) aux sous-réseaux du cluster ARO. Étant donné que vous possédez ce groupe de sécurité réseau préconfiguré, vous pouvez ajouter/supprimer des règles pendant la durée de vie du cluster ARO.

Fonctionnalités générales et limitations

Vous devez attacher vos groupes de sécurité réseau préconfigurés aux sous-réseaux maître et Worker avant de créer le cluster. L’échec de l’attachement de vos groupes de sécurité réseau préconfigurés aux deux sous-réseaux entraîne une erreur.
Vous pouvez choisir d'utiliser les mêmes groupes de sécurité réseau préconfigurés ou différents pour les sous-réseaux principal et travailleur.
Lorsque vous utilisez votre propre groupe de sécurité réseau, le fournisseur de ressources ARO crée toujours un groupe de sécurité réseau dans le groupe de ressources managés (groupe de sécurité réseau par défaut), mais ce groupe de sécurité réseau n’est pas attaché aux sous-réseaux worker ou maître.
Vous ne pouvez pas activer la fonctionnalité de groupe de sécurité réseau préconfigurée sur un cluster ARO existant. Actuellement, cette fonctionnalité ne peut être activée qu’au moment de la création du cluster.
L’option NSG préconfigurée n’est pas configurable à partir du portail Azure.
Si vous avez utilisé cette fonctionnalité en préversion, vos clusters préconfigurés existants sont désormais entièrement pris en charge.

Remarque

Si vous utilisez la fonctionnalité « apportez votre propre » groupe de sécurité réseau et souhaitez exploiter les journaux de flux de celui-ci, veuillez consulter la section Journalisation des flux pour les groupes de sécurité réseau dans la documentation Azure Network Watcher, plutôt que la documentation spécifique aux journaux de flux pour ARO (qui ne fonctionnera pas avec la fonctionnalité apportez votre propre groupe de sécurité réseau).

Utilisation de règles

Avertissement

Les groupes de sécurité réseau préconfigurés ne sont pas automatiquement mis à jour avec des règles lorsque vous créez des services de type Kubernetes LoadBalancer ou des itinéraires OpenShift au sein du cluster ARO. Par conséquent, vous devez mettre à jour ces règles manuellement, selon les besoins. Ce comportement est différent du comportement ARO d’origine dans lequel le groupe de sécurité réseau par défaut est mis à jour par programmation dans de telles situations.

Le groupe de sécurité réseau de cluster ARO par défaut (non attaché à un sous-réseau lors de l’utilisation de cette fonctionnalité) est toujours mis à jour avec des règles lorsque vous créez des services de type Kubernetes LoadBalancer ou des itinéraires OpenShift au sein du cluster ARO.
Vous pouvez détacher les groupes de sécurité réseau préconfigurés des sous-réseaux du cluster créés à l’aide de cette fonctionnalité. Il génère un cluster avec des sous-réseaux qui n’ont aucun NSG. Vous pouvez ensuite attacher un autre ensemble de groupes de sécurité réseau préconfigurés au cluster. Vous pouvez également attacher le groupe de sécurité réseau par défaut ARO aux sous-réseaux du cluster (à quel moment votre cluster devient comme n’importe quel autre cluster qui n’utilise pas cette fonctionnalité).
Vos groupes de sécurité réseau préconfigurés ne doivent pas avoir de règles de refus d'entrée/sortie des types suivants, car elles peuvent interférer avec le fonctionnement du cluster et/ou empêcher les équipes de support ARO/SRE de fournir une assistance ou une gestion. (Ici, le sous-réseau indique toutes les adresses IP du sous-réseau et tous les ports correspondant à ce sous-réseau) :
- Sous-réseau principal ←→ Sous-réseau principal
- Sous-réseau Worker ←→ Sous-réseau Worker
- Sous-réseau principal ←→ Sous-réseau Worker
- Les règles mal configurées entraînent un signal utilisé par Azure Monitor pour résoudre les problèmes de groupes de sécurité réseau préconfigurés.
Pour autoriser le trafic entrant vers votre cluster public ARO, définissez les règles INBOUND ALLOW (ou équivalentes) suivantes dans votre groupe de sécurité réseau. Reportez-vous au groupe de sécurité réseau par défaut du cluster pour obtenir des détails spécifiques et à l’exemple de groupe de sécurité réseau indiqué dans Déploiement. Vous pouvez créer un cluster même sans ces règles dans le groupe de sécurité réseau.
- Pour l’accès au serveur d’API → à partir d’Internet (ou de vos adresses IP sources préférées) au port 6443 sur le sous-réseau maître.
- Pour accéder au routeur OpenShift (et donc à la console OpenShift et aux itinéraires OpenShift) → à partir d’Internet (ou de vos adresses IP sources préférées) vers les ports 80 et 443 sur l’adresse IP publique par défaut v4 sur l’équilibreur de charge public du cluster.
- Pour accéder à un service Kubernetes de type équilibreur de charge → à partir d’Internet (ou de vos adresses IP sources préférées) vers les ports du service sur l’adresse IP publique correspondant au service via l’équilibreur de charge public du cluster.

Déploiement

Créer un réseau virtuel et créer et configurer un groupe de sécurité réseau prédéfini

Créez un réseau virtuel, puis créez des sous-réseaux maître et worker dans celui-ci.
Créez des groupes de sécurité réseau préconfigurés avec des règles par défaut (ou sans règle) et attachez-les aux sous-réseaux principaux et exécutants.

Créer un cluster ARO et mettre à jour des groupes de sécurité réseau préconfigurés

Créez le cluster.

az aro create \
--resource-group BASE_RESOURCE_GROUP_NAME \
--name CLUSTER_NAME \
--vnet VNET_NAME \
--master-subnet MASTER_SUBNET_NAME \
--worker-subnet WORKER_SUBNET_NAME \
--client-id CLUSTER_SERVICE_PRINCIPAL_ID \
--client-secret CLUSTER_SERVICE_PRINCIPAL_SECRET \
--enable-preconfigured-nsg

Mettez à jour les groupes de sécurité réseau préconfigurés avec des règles en fonction de vos besoins tout en tenant compte des points mentionnés dans Fonctionnalités et limitations.

L’exemple suivant présente l’équilibreur de charge public du cluster, comme illustré dans la sortie CLI/capture d’écran :
```
$ oc get svc | grep tools
tools LoadBalancer 172.30.182.7 20.141.176.3 80:30520/TCP 143m
$ $ oc get svc -n openshift-ingress | grep Load
router-default LoadBalancer 172.30.105.218 20.159.139.208 80:31157/TCP,443:31177/TCP 
5d20
```