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

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 à la fois pour le réseau virtuel (VNET) et pour le cluster, ou vous pouvez opter pour un groupe de ressources distinct seulement pour le réseau virtuel. Aucun de ces groupes de ressources ne correspond directement à un cluster ARO, ce qui vous donne un contrôle total sur ceux-ci. Cela signifie que vous pouvez créer, modifier ou supprimer librement des ressources au sein de ces groupes de ressources.

Lors du processus de création du cluster, le fournisseur de ressources ARO é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 des machines virtuelles de nœud, des équilibreurs de charge et des groupes de sécurité réseau, comme illustré par le groupe de ressources managé dans le diagramme suivant. Le groupe de ressources managé est fortement sécurisé, interdisant toute modification de son contenu, y compris le groupe de sécurité réseau lié aux sous-réseaux de réseau virtuel spécifiés lors de la création du cluster. Dans certains cas, le NSG généré par le fournisseur de ressources ARO peut ne pas être conforme aux stratégies de sécurité de certaines organisations.

Cet article montre comment utiliser la fonctionnalité « Apporter votre propre » (Bring Your Own) groupe de sécurité réseau (NSG) pour attacher votre propre groupe de sécurité réseau préconfiguré qui se trouve dans le groupe de ressources de base/de réseau virtuel (figurant dans le diagramme suivant sous le nom de BYO-NSG) aux sous-réseaux du cluster ARO. Comme vous êtes propriétaire de ce NSG 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 NSG préconfigurés aux sous-réseaux maître et Worker avant de créer le cluster. L’échec de l’attachement de vos NSG préconfigurés aux deux sous-réseaux entraîne une erreur.

• Vous pouvez choisir d’utiliser les mêmes NSG préconfigurés ou des NSG préconfigurés différents pour les sous-réseaux maître et Worker.

• Quand vous utilisez votre propre NSG, le fournisseur de ressources ARO crée néanmoins toujours un NSG dans le groupe de ressources managé (le NSG par défaut), mais ce NSG n’est pas attaché aux sous-réseaux Worker ou maître.

• Vous ne pouvez pas activer la fonctionnalité des NSG préconfigurés sur un cluster ARO existant. Actuellement, cette fonctionnalité peut être activée seulement au moment de la création du cluster.

• L’option des NSG préconfigurés n’est pas configurable depuis le portail Azure.

• Si vous avez utilisé cette fonctionnalité pendant la phase de 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 NSG » et que vous voulez utiliser des journaux de flux NSG, consultez Journalisation des flux pour les groupes de sécurité réseau dans la documentation Azure Network Watcher, au lieu de la documentation du journal de flux propre à ARO (qui ne fonctionne 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 mis à jour automatiquement avec les règles quand vous créez des services de type Kubernetes LoadBalancer ou des routes OpenShift au sein du cluster ARO. Par conséquent, vous devez mettre à jour ces règles manuellement quand c’est nécessaire. Ce comportement est différent du comportement d’origine d’ARO, où dans ces situations, le NSG par défaut est mis à jour par programmation.

• Le NSG du cluster ARO par défaut (qui n’est attaché à aucun sous-réseau lors de l’utilisation de cette fonctionnalité) sera néanmoins toujours mis à jour avec les règles quand vous créez des services de type Kubernetes LoadBalancer ou des routes OpenShift au sein du cluster ARO.

• Vous pouvez détacher des NSG préconfigurés des sous-réseaux du cluster créés en utilisant cette fonctionnalité. Ceci aboutit à un cluster avec des sous-réseaux qui n’ont pas de NSG. Vous pouvez ensuite attacher un autre ensemble de NSG préconfigurés au cluster. Vous pouvez aussi attacher le NSG par défaut d’ARO aux sous-réseaux du cluster (auquel cas votre cluster devient comme n’importe quel autre cluster n’utilisant pas cette fonctionnalité).

• Vos NSG préconfigurés ne doivent pas avoir de règles INBOUND/OUTBOUND DENY des types suivants, car elles peuvent interférer avec le fonctionnement du cluster et/ou empêcher les équipes de support/SRE d’ARO de fournir du support/de l’administration. (Ici, le terme « sous-réseau » inclut toutes les adresses IP du sous-réseau et à tous les ports correspondant à ce sous-réseau) :

  • Sous-réseau maître ←→ Sous-réseau maître

  • Sous-réseau Worker ←→ Sous-réseau Worker

  • Sous-réseau maître ←→ Sous-réseau Worker

  • Des règles mal configurées déclenchent un signal utilisé par Azure Monitor pour faciliter la résolution des problèmes des NSG 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 NSG. Reportez-vous au NSG par défaut du cluster pour obtenir des détails spécifiques et à l’exemple de NSG présenté dans Déploiement. Vous pouvez créer un cluster même sans ces règles dans le NSG.

  • Pour l’accès au serveur d’API → depuis Internet (ou de vos adresses IP sources préférées) vers le port 6443 sur le sous-réseau maître.
  • Pour l’accès au routeur OpenShift (et donc à la console OpenShift et aux routes OpenShift) → depuis Internet (ou de vos adresses IP sources préférées) vers les ports 80 et 443 sur l’adresse IP publique v4 par défaut sur l’équilibreur de charge public du cluster.
  • Pour l’accès à n’importe quel service Kubernetes de type Équilibreur de charge → depuis Internet (ou vos adresses IP sources préférées) vers les ports de service sur l’adresse IP publique correspondant au service sur l’équilibreur de charge public du cluster.

Déploiement

Créer un réseau virtuel, et créer et configurer un NSG préconfiguré

1. Créez un réseau virtuel, puis créez des sous-réseaux maître et Worker dans celui-ci.

2. Créez des NSG préconfigurés avec des règles par défaut (ou aucune règle), puis attachez-les aux sous-réseaux maître et Worker.

Créer un cluster ARO et mettre à jour des NSG préconfigurés

1. 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
   

2. Mettez à jour les NSG 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 montre l’équilibreur de charge public du cluster, comme illustré dans la capture d’écran de la sortie de l’interface CLI :

   

   $ 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