Utiliser le Pare-feu Azure pour protéger des clusters d’Azure Kubernetes Service (AKS)
Cet article vous montre comment protéger les clusters Azure Kubernetes Service (AKS) à l’aide du Pare-feu Azure pour sécuriser le trafic sortant et entrant.
Arrière-plan
Azure Kubernetes service (AKS) offre un cluster Kubernetes managé sur Azure. Pour plus d’information, consultez Azure Kubernetes Service.
Bien qu'AKS soit une solution entièrement gérée, elle n'offre pas de solution intégrée pour sécuriser le trafic d'entrée et de sortie entre le cluster et les réseaux externes. Le Pare-feu Azure offre une solution à cela.
Les clusters AKS sont déployés sur un réseau virtuel. Ce réseau peut être géré (créé par AKS) ou personnalisé (préconfiguré au préalable par l’utilisateur). Dans les deux cas, le cluster comporte des dépendances sortantes vis-à-vis de services situés en dehors de ce réseau virtuel (le service ne présente aucune dépendance entrante). Pour la gestion et à des fins opérationnelles, les nœuds d’un cluster AKS doivent accéder à certains ports et noms de domaine complet (FQDN), décrivant ces dépendances sortantes. Cela est nécessaire pour différentes fonctions, notamment, mais sans s’y limiter, les nœuds qui communiquent avec le serveur d’API Kubernetes. Ils téléchargent et installent les principaux composants de cluster Kubernetes et les mises à jour de sécurité des nœuds, ou extraient des images conteneur système de base à partir de Microsoft Container Registry (MCR), et ainsi de suite. Ces dépendances sortantes sont presque entièrement définies avec des noms FQDN, qui n’ont pas d’adresses statiques derrière eux. En raison de cette absence d’adresses statiques, il n’est pas possible d’utiliser des groupes de sécurité réseau pour verrouiller le trafic sortant d’un cluster AKS. Pour cette raison, par défaut, les clusters AKS ont un accès illimité sortant à Internet. Ce niveau d’accès réseau permet aux nœuds et services que vous exécutez d’accéder aux ressources externes en fonction des besoins.
Toutefois, dans un environnement de production, les communications avec un cluster Kubernetes doivent être protégées pour empêcher l’exfiltration des données, ainsi que d’autres vulnérabilités. Tout le trafic réseau entrant et sortant doit être surveillé et contrôlé en fonction d’un ensemble de règles de sécurité. Si vous souhaitez effectuer cette opération, vous devez limiter le trafic de sortie, mais un nombre limité de ports et d’adresses doivent rester accessibles pour maintenir des tâches de maintenance de cluster saines et satisfaire ces dépendances sortantes mentionnées précédemment.
La solution la plus simple consiste à utiliser un appareil de type pare-feu qui peut contrôler le trafic sortant en fonction des noms de domaine. Un pare-feu établit généralement un cloisonnement entre un réseau approuvé et un réseau non approuvé, tel qu’Internet. Le Pare-feu Azure, par exemple, peut restreindre le trafic HTTP et HTTPS sortant en fonction du nom de domaine complet de la destination, ce qui vous donne un contrôle de trafic de sortie affiné, tout en vous permettant d’accéder aux noms de domaine complets englobant les dépendances sortantes d’un cluster AKS (ce que les groupes de sécurité réseau ne peuvent pas faire). De même, vous pouvez contrôler le trafic d’entrée et améliorer la sécurité en activant le filtrage basé sur le renseignement sur les menaces sur un Pare-feu Azure déployé sur un réseau de périmètre partagé. Ce filtrage peut fournir des alertes et refuser le trafic vers et depuis des adresses IP et des domaines malveillants connus.
Consultez la vidéo suivante d’Abhinav Sriram pour obtenir une vue d’ensemble rapide de la façon dont cela fonctionne dans la pratique sur un exemple d’environnement :
Vous pouvez télécharger un fichier zip à partir du Centre de téléchargement Microsoft qui contient un fichier de script bash et un fichier yaml pour configurer automatiquement l’exemple d’environnement utilisé dans la vidéo. Il configure le Pare-feu Azure pour protéger le trafic d’entrée et de sortie. Les guides suivants décrivent plus en détail chaque étape du script afin de pouvoir configurer une configuration personnalisée.
Le diagramme suivant montre l’exemple d’environnement de la vidéo que le script et le guide configurent :
Il y a une différence entre le script et le guide suivant. Le script utilise des identités managées, mais le guide utilise un principal de service. Cela vous montre deux façons différentes de créer une identité pour gérer et créer des ressources de cluster.
Limitation du trafic de sortie à l’aide du Pare-feu Azure
Définir la configuration via des variables d’environnement
Définissez un ensemble de variables d’environnement à utiliser dans les créations de ressources.
PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"
Créer un réseau virtuel comprenant plusieurs sous-réseaux
Créez un réseau virtuel avec deux sous-réseaux distincts, un pour le cluster et un pour le pare-feu. Si vous le souhaitez, vous pouvez également en créer un pour l’entrée du service interne.
Créez un groupe de ressources pour héberger toutes les ressources.
# Create Resource Group
az group create --name $RG --location $LOC
Créez un réseau virtuel comportant deux sous-réseaux pour héberger le cluster AKS et le Pare-feu Azure. Chacun a son propre sous-réseau. Commençons par le réseau AKS.
# Dedicated virtual network with AKS subnet
az network vnet create \
--resource-group $RG \
--name $VNET_NAME \
--location $LOC \
--address-prefixes 10.42.0.0/16 \
--subnet-name $AKSSUBNET_NAME \
--subnet-prefix 10.42.1.0/24
# Dedicated subnet for Azure Firewall (Firewall name cannot be changed)
az network vnet subnet create \
--resource-group $RG \
--vnet-name $VNET_NAME \
--name $FWSUBNET_NAME \
--address-prefix 10.42.2.0/24
Créer et configurer un Pare-feu Azure avec une route définie par l’utilisateur
Les règles de trafic entrant et sortant du pare-feu Azure doivent être configurées. L’objectif principal du pare-feu est de permettre aux organisations de configurer des règles de trafic entrant et sortant précises à l’intérieur et à l’extérieur du cluster AKS.
Important
Si votre cluster ou votre application crée un grand nombre de connexions sortantes dirigées vers les mêmes destinations ou une petite partie d’entre elles, il peut vous falloir davantage d’adresses IP front-end de pare-feu pour éviter d’atteindre le maximum de ports par adresse IP front-end. Pour plus d’informations sur la création d’un Pare-feu Azure avec plusieurs adresses IP, cliquez ici.
Créez une ressource IP publique SKU standard qui sera utilisée comme adresse frontale du pare-feu Azure.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Inscrivez l’extension CLI en préversion pour créer un pare-feu Azure.
# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
L’adresse IP créée précédemment peut maintenant être affectée au front-end du pare-feu.
Notes
La configuration de l’adresse IP publique sur le Pare-feu Azure peut prendre quelques minutes. Pour pouvoir utiliser le nom FQDN sur les règles de réseau, il faut que le proxy DNS soit activé, car le pare-feu écoute alors le port 53 et transfère les requêtes DNS au serveur DNS spécifié ci-dessus. Il peut ainsi traduire automatiquement ce nom FQDN.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME
Une fois que la commande précédente a réussi, enregistrez l’adresse IP du front-end du pare-feu pour la configurer ultérieurement.
# Capture Firewall IP Address for Later Use
FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)
Notes
Si vous utilisez un accès sécurisé au serveur d’API AKS avec des plages d’adresses IP autorisées, vous devez ajouter l’adresse IP publique du pare-feu dans la plage d’adresses IP autorisées.
Créer une route définie par l’utilisateur avec un tronçon vers le pare-feu Azure
Azure achemine automatiquement le trafic entre les sous-réseaux, les réseaux virtuels et les réseaux locaux Azure. Si vous souhaitez modifier un routage par défaut d’Azure, vous pouvez le faire en créant une table de routage.
Créez une table de routage à associer à un sous-réseau donné. La table de routage définit le tronçon suivant comme étant le Pare-feu Azure créé précédemment. Chaque sous-réseau peut avoir zéro ou une table de routage associée.
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP
az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet
Pour savoir comment vous pouvez remplacer les routes système par défaut d’Azure ou ajouter des routes supplémentaires à la table de routage d’un sous-réseau, consultez la documentation des tables de routage de réseau virtuel.
Ajout de règles de pare-feu
Notes
Pour les applications situées en dehors des espaces de noms kube-system ou gatekeeper-system qui doivent communiquer avec le serveur d’API, une règle de réseau supplémentaire est nécessaire pour autoriser la communication TCP sur le port 443 pour l’adresse IP du serveur d’API, en plus de l’ajout d’une règle d’application pour la fqdn-tag AzureKubernetesService.
Pour configurer votre pare-feu, vous pouvez utiliser les trois règles réseau suivantes. Vous devrez probablement adapter ces règles en fonction de votre déploiement. La première règle autorise l’accès au port 9000 via TCP. La deuxième règle autorise l’accès aux ports 1194 et 123 via UDP. Ces deux règles autorisent uniquement le trafic destiné au CIDR de la région Azure que nous utilisons, dans le cas présent USA Est.
Enfin, nous allons ajouter une troisième règle de réseau ouvrant le port 123 à un nom de domaine complet du serveur Internet (par exemple : ntp.ubuntu.com ) via UDP. L’ajout d’un nom de domaine complet comme règle de réseau est l’une des fonctionnalités spécifiques du Pare-feu Azure. Vous devrez l’adapter quand vous utiliserez vos propres options.
Après avoir défini les règles de réseau, nous allons ajouter également une règle d’application à l’aide de AzureKubernetesService qui couvre tous les noms FQDN nécessaires accessibles via le port TCP 443 et le port 80. Vous devrez probablement aussi configurer d’autres règles de réseau et d’application en fonction de votre déploiement. Pour plus d'informations, voir Règles de réseau sortant et de FQDN pour les clusters Azure Kubernetes Service (AKS).
Ajouter des règles de réseau FW
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --action allow --priority 100
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000
az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123
Ajouter des règles d’application FW
az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100
Pour plus d’informations sur le service Pare-feu Azure, consultez la documentation de Pare-feu Azure.
Associer la table de routage à AKS
Pour associer le cluster au pare-feu, le sous-réseau dédié pour le sous-réseau du cluster doit référencer la table de routage créée précédemment. L’association peut être effectuée en émettant une commande vers le réseau virtuel contenant à la fois le cluster et le pare-feu pour mettre à jour la table de routage du sous-réseau du cluster.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME
Déployer AKS avec le type de sortie UDR sur le réseau existant
Un cluster AKS peut maintenant être déployé dans le réseau virtuel existant. Vous utilisez également le type sortant userDefinedRouting. Cette fonctionnalité garantit que tout le trafic sortant sera forcé à transiter par le pare-feu et qu’il n’existera aucun autre chemin de sortie (par défaut, le type sortant Load Balancer pourrait être utilisé).
Le sous-réseau cible où effectuer le déploiement est défini avec la variable d’environnement $SUBNETID. Nous n’avons pas défini la variable $SUBNETID dans les étapes précédentes. Pour définir la valeur de l’ID de sous-réseau, vous pouvez utiliser la commande suivante :
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
Vous définissez le type de sortie pour utiliser l'UDR qui existe déjà sur le sous-réseau. Cette configuration permet à AKS d’ignorer l’installation et le provisionnement IP pour l’équilibreur de charge.
Important
Pour plus d’informations sur la route définie par l’utilisateur de type sortant, notamment les limitations, consultez Route définie par l’utilisateur de type sortant de sortie.
Conseil
Des fonctionnalités supplémentaires peuvent être ajoutées au déploiement du cluster, comme Cluster privé, ou en modifiant la référence SKU du système d’exploitation.
La fonctionnalité AKS de plages d’adresses IP autorisées du serveur d’API peut être ajoutée pour limiter l’accès du serveur d’API au point de terminaison public du pare-feu. Elle est indiquée comme facultative dans le diagramme. Quand vous activez la fonctionnalité de plage d’adresses IP autorisées pour limiter l’accès au serveur d’API, vos outils de développement doivent utiliser une jumpbox à partir du réseau virtuel du pare-feu, ou vous devez ajouter tous les points de terminaison de développeur à la plage d’adresses IP autorisées.
az aks create -g $RG -n $AKSNAME -l $LOC \
--node-count 3 \
--network-plugin azure \
--outbound-type userDefinedRouting \
--vnet-subnet-id $SUBNETID \
--api-server-authorized-ip-ranges $FWPUBLIC_IP
Remarque
Pour créer et utiliser votre propre réseau virtuel et votre propre table de routage avec un plug-in réseau kubenet, vous devez utiliser une identité managée affectée par l’utilisateur. Pour l’identité managée affectée par le système, nous ne pouvons pas obtenir l’ID d’identité avant de créer un cluster, ce qui entraîne un retard pour que l’attribution de rôle prenne effet.
Pour créer et utiliser votre propre réseau virtuel et votre propre table de routage avec un plug-in réseau azure, les identités managées affectées par le système et affectées par l’utilisateur sont prises en charge.
Activer l’accès des développeurs au serveur d’API
Si vous avez utilisé les plages d’adresses IP autorisées pour le cluster à l’étape précédente, vous devez ajouter les adresses IP de vos outils de développement à la liste de clusters AKS des plages d’adresses IP approuvées pour pouvoir accéder au serveur d’API à partir de cet emplacement. Une autre option est de configurer une jumpbox avec les outils nécessaires à l’intérieur d’un sous-réseau distinct dans le réseau virtuel du pare-feu.
Ajoutez une autre adresse IP aux plages approuvées avec la commande suivante
# Retrieve your IP address
CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Exécutez la commande az aks get-credentials pour configurer kubectl afin de vous connecter à votre cluster Kubernetes nouvellement créé.
az aks get-credentials -g $RG -n $AKSNAME
Limitation du trafic d’entrée à l’aide du Pare-feu Azure
Vous pouvez maintenant commencer à exposer des services et à déployer des applications sur ce cluster. Dans cet exemple, nous exposons un service public, mais vous pouvez également choisir d’exposer un service interne au moyen d’un équilibreur de charge interne.
Déployez l’application de vote Azure en copiant le code YAML suivant dans un fichier nommé example.yaml.
# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-storage
spec:
replicas: 1
selector:
matchLabels:
app: voting-storage
template:
metadata:
labels:
app: voting-storage
spec:
containers:
- name: voting-storage
image: mcr.microsoft.com/azuredocs/voting/storage:2.0
args: ["--ignore-db-dir=lost+found"]
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: voting-storage-secret
type: Opaque
data:
MYSQL_USER: ZGJ1c2Vy
MYSQL_PASSWORD: UGFzc3dvcmQxMg==
MYSQL_DATABASE: YXp1cmV2b3Rl
MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-storage
labels:
app: voting-storage
spec:
ports:
- port: 3306
name: mysql
selector:
app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app
spec:
replicas: 1
selector:
matchLabels:
app: voting-app
template:
metadata:
labels:
app: voting-app
spec:
containers:
- name: voting-app
image: mcr.microsoft.com/azuredocs/voting/app:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
- name: ANALYTICS_HOST
value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-app
labels:
app: voting-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: voting-app
---
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-analytics
spec:
replicas: 1
selector:
matchLabels:
app: voting-analytics
version: "2.0"
template:
metadata:
labels:
app: voting-analytics
version: "2.0"
spec:
containers:
- name: voting-analytics
image: mcr.microsoft.com/azuredocs/voting/analytics:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-analytics
labels:
app: voting-analytics
spec:
ports:
- port: 8080
name: http
selector:
app: voting-analytics
Déployez le service en exécutant :
kubectl apply -f example.yaml
Ajouter une règle DNAT au pare-feu Azure
Important
Lorsque vous utilisez le Pare-feu Azure pour limiter le trafic de sortie et créer un itinéraire défini par l’utilisateur (UDR) afin de forcer tout le trafic de sortie, veillez à créer une règle DNAT appropriée dans le Pare-feu pour autoriser le trafic d’entrée. L’utilisation du Pare-feu Azure avec une UDR perturbe la configuration d’entrée en raison d’un routage asymétrique (ce problème se produit si le sous-réseau AKS a un itinéraire par défaut qui conduit à l’adresse IP privée du pare-feu, alors que vous utilisez un service d’équilibreur de charge public, d’entrée ou Kubernetes de type : LoadBalancer). Dans ce cas, le trafic d’équilibreur de charge entrant est reçu par le biais de son adresse IP publique, mais le chemin de retour passe par l’adresse IP privée du pare-feu. Le pare-feu étant avec état, il supprime le paquet de retour, car le pare-feu n’a pas connaissance d’une session établie. Pour découvrir comment intégrer un Pare-feu Azure avec votre équilibreur de charge d’entrée ou de service, voir Intégrer un pare-feu Azure avec Azure Standard Load Balancer.
Pour configurer la connectivité entrante, une règle DNAT doit être écrite sur le pare-feu Azure. Pour tester la connectivité au cluster, une règle est définie de sorte que l’adresse IP publique front-end du pare-feu soit acheminée vers l’adresse IP interne exposée par le service interne.
L’adresse de destination peut être personnalisée, car il s’agit du port d’accès sur le pare-feu. L’adresse traduite doit être l’adresse IP de l’équilibreur de charge interne. Le port traduit doit être le port exposé pour votre service Kubernetes.
Vous devez spécifier l'adresse IP interne attribuée à l'équilibreur de charge créé par le service Kubernetes. Récupérez l’adresse en exécutant :
kubectl get services
L’adresse IP nécessaire est listée dans la colonne EXTERNAL-IP, comme ci-dessous.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m
voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m
voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m
Récupérez l’adresse IP du service en exécutant :
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Ajoutez la règle NAT en exécutant :
az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP
Valider la connectivité
Accédez à l’adresse IP du front-end du pare-feu Azure dans un navigateur pour valider la connectivité.
L’application de vote AKS s’affiche. Dans cet exemple, l’IP publique du pare-feu était 52.253.228.132.
Nettoyer les ressources
Pour nettoyer les ressources Azure, supprimez le groupe de ressources AKS.
az group delete -g $RG
Étapes suivantes
- Pour en savoir plus sur Azure Container Service, consultez Concepts de base de Kubernetes pour AKS (Azure Kubernetes Service).