Contrôler le trafic de sortie à l’aide du Pare-feu Azure dans Azure Kubernetes Service (AKS)

Article
05/04/2023

Cet article fournit une procédure pas à pas montrant comment utiliser le réseau sortant et les règles de nom de domaine complet pour les clusters AKS afin de contrôler le trafic de sortie à l’aide du Pare-feu Azure dans AKS. Pour simplifier cette configuration, Pare-feu Azure fournit un nom de domaine complet Azure Kubernetes Service (AzureKubernetesService) qui limite le trafic sortant à partir du cluster AKS. Cet article fournit également un exemple de configuration du trafic entrant public via le pare-feu.

Notes

La balise FQDN contient tous les noms de domaine complets répertoriés dans Règles de réseau sortant et de nom de domaine complet pour les clusters AKS et est automatiquement mise à jour.

Pour les scénarios de production, nous vous recommandons d’avoir un minimum de 20 adresses IP de front-end sur le Pare-feu Azure afin d’éviter les problèmes d’épuisement des ports SNAT.

Les informations suivantes fournissent un exemple d’architecture du déploiement :

Topologie verrouillée

L’entrée publique est forcée à passer à travers les filtres du pare-feu
- Les nœuds d’agent AKS sont isolés dans un sous-réseau dédié
- Le Pare-feu Azure est déployé dans son propre sous-réseau
- Une règle DNAT traduit l’adresse IP publique du pare-feu en adresse IP de front-end de l’équilibreur de charge
Les demandes sortantes vont des nœuds d’agent vers l’adresse IP interne du Pare-feu Azure suivant un itinéraire défini par l’utilisateur
- Les demandes des nœuds d’agent AKS suivent un itinéraire défini par l’utilisateur qui a été mis en place sur le sous-réseau où le cluster AKS a été déployé
- Le pare-feu Azure sort du réseau virtuel depuis un front-end d’adresses IP publiques
- L’accès à l’Internet public ou à d’autres services Azure circule vers et depuis l’adresse IP du front-end du pare-feu
- L’accès au plan de contrôle AKS peut être protégé par des plages d’adresses IP autorisées par le serveur d’API, y compris l’adresse IP de frontend publique du pare-feu
Trafic interne
- Vous pouvez utiliser un équilibreur de charge interne pour le trafic interne, que vous pouvez isoler sur son propre sous-réseau, au lieu ou en complément d’un équilibreur de charge public

Définir la configuration à l’aide de 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

Approvisionnez 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 en créer un pour l’entrée du service interne.

Topologie de réseau vide

Créez un groupe de ressources avec la commande az group create.
```
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 au moyen des commandes az network vnet create et az network vnet subnet create.

# 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 can't 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

Vous devez configurer les règles de trafic entrant et sortant du Pare-feu Azure. 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 de front-end de pare-feu pour éviter d’atteindre le maximum de ports par adresse IP de front-end.

Pour plus d’informations sur la création d’un Pare-feu Azure avec plusieurs adresses IP, consultez Créer un Pare-feu Azure avec plusieurs adresses IP publiques à l’aide de Bicep.

Pare-feu et route définie par l’utilisateur

Créez une ressource IP publique de référence SKU standard à l’aide de la commande az network public-ip create. Cette ressource est utilisée comme adresse de front-end 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 du Pare-feu Azure pour créer un Pare-feu Azure à l’aide de la commande az extension add.
```
az extension add --name azure-firewall
```
Créez un Pare-feu Azure et activez le proxy DNS à l’aide de la commande az network firewall create et définissez --enable-dns-proxy sur true.
```
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
```

La configuration de l’adresse IP publique sur le Pare-feu Azure peut prendre quelques minutes. Une fois qu’elle est prête, l’adresse IP créée précédemment peut être affectée au front-end de pare-feu.

Notes

Pour tirer parti du nom de domaine complet sur les règles réseau, le proxy DNS doit être activé. Lorsque le proxy DNS est activé, le pare-feu écoute le port 53 et transfère les requêtes DNS au serveur DNS spécifié ci-dessus. Le pare-feu peut ensuite traduire automatiquement le nom de domaine complet.

Créez une configuration IP de Pare-feu Azure à l’aide de la commande az network firewall ip-config create.

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.

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 créer une table de routage.

Créez une table de routage vide à associer à un sous-réseau donné au moyen de la commande az network route-table create. La table de routage définit le tronçon suivant comme étant le pare-feu Azure créé plus haut. Chaque sous-réseau peut avoir zéro ou une table de routage associée.
```
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
```

Créez des itinéraires dans la table de routage pour les sous-réseaux à l’aide de la commande az network route-table route create.

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 plus d’informations sur la façon de remplacer les itinéraires système par défaut d’Azure ou d’ajouter des itinéraires à la table de routage d’un sous-réseau, consultez la documentation de la table de routage de réseau virtuel.

Ajouter des 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 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.

Cette section couvre trois règles réseau et une règle d’application que vous pouvez utiliser pour la configuration sur votre pare-feu. Vous devrez peut-être adapter ces règles en fonction de votre déploiement.

La première règle réseau autorise l’accès au port 9000 via TCP.
La deuxième règle réseau autorise l’accès aux ports 1194 et 123 via UDP. Si vous effectuez un déploiement sur Azure China 21Vianet, consultez les règles réseau requises d’Azure China 21Vianet. Ces deux règles autorisent uniquement le trafic destiné au CIDR de la région Azure que nous utilisons, dans ce cas USA Est.
La troisième règle de réseau ouvre le port 123 au nom de domaine complet 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.
La règle d’application couvre l’ensemble des noms de domaine complets requis accessibles via les ports TCP 443 et 80.

Créez les règles réseau à l’aide de la commande az network firewall network-rule create.

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

Créez la règle d’application à l’aide de la commande az network firewall application-rule create.

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 en savoir plus sur le Pare-feu Azure, consultez la documentation du 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 ci-dessus. Utilisez la commande az network vnet subnet update pour associer la table de routage à AKS.

az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME

Déployer un cluster AKS avec un type UDR sortant sur le réseau existant

Vous pouvez maintenant déployer un cluster AKS dans le réseau virtuel existant. Vous allez utiliser le type sortant userDefinedRouting, qui garantit que tout trafic sortant est forcé à travers le pare-feu et qu’aucun autre chemin de sortie n’existera. Vous pouvez également utiliser le type sortant loadBalancer.

aks-deploy

Le sous-réseau cible où effectuer le déploiement est défini avec la variable d’environnement $SUBNETID. Définissez la valeur de l’ID de sous-réseau à l’aide de la commande suivante :

SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)

Vous allez définir le type sortant de façon à utiliser la route définie par l’utilisateur 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.

Conseil

Vous pouvez ajouter des fonctionnalités au déploiement de cluster, telles que des clusters privés.

Vous pouvez ajouter la fonctionnalité AKS des plages d’adresses IP autorisées du serveur d’API pour limiter l’accès du serveur d’API au point de terminaison public du pare-feu uniquement. 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.

Créer un cluster AKS avec des identités affectées par le système

Notes

AKS crée une identité kubelet affectée par le système dans le groupe de ressources Node si vous ne spécifiez pas votre propre identité managée kubelet.

Pour le routage défini par l’utilisateur, l’identité attribuée par le système prend uniquement en charge le plug-in réseau CNI.

Créez un cluster AKS en utilisant une identité managée attribuée par le système avec le plug-in réseau CNI au moyen de la commande az aks create.

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

Créer des identités attribuées par l’utilisateur

Si vous n’avez pas d’identités attribuées par l’utilisateur, suivez les étapes décrites dans cette section. Si vous disposez déjà d’identités attribuées par l’utilisateur, passez à Créer un cluster AKS avec des identités attribuées par l’utilisateur.

Créez une identité managée de plan de contrôle à l’aide de la commande az identity create.

az identity create --name myIdentity --resource-group myResourceGroup

La sortie doit ressembler à l’exemple suivant :

 {                                  
   "clientId": "<client-id>",
    "clientSecretUrl": "<clientSecretUrl>",
    "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity", 
   "location": "westus2",
  "name": "myIdentity",
   "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
   "tags": {},
   "tenantId": "<tenant-id>",
    "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
 }

Créez une identité managée kubelet à l’aide de la commande az identity create.

az identity create --name myKubeletIdentity --resource-group myResourceGroup

La sortie doit ressembler à l’exemple suivant :

{
  "clientId": "<client-id>",
 "clientSecretUrl": "<clientSecretUrl>",
 "id": "/subscriptions/<subscriptionid>/resourcegroups/myResourceGroup/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity", 
  "location": "westus2",
  "name": "myKubeletIdentity",
 "principalId": "<principal-id>",
  "resourceGroup": "myResourceGroup",                       
  "tags": {},
 "tenantId": "<tenant-id>",
 "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Notes

Si vous créez votre propre réseau virtuel et votre propre table de routage, où les ressources sont en dehors du groupe de ressources de nœud Worker, l’interface CLI ajoute automatiquement l’attribution de rôle. Si vous utilisez un modèle ARM ou un autre client, vous devez utiliser l’ID du principal de l’identité managée du cluster pour effectuer une attribution de rôle.

Créer un cluster AKS avec des identités affectées par l’utilisateur

Créez un cluster AKS avec vos identités existantes dans le sous-réseau à l’aide de la commande az aks create et en fournissant votre identité managée kubelet d’ID de ressource d’identité de plan de contrôle.

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 \
  --network-plugin kubenet \
  --outbound-type userDefinedRouting \
  --vnet-subnet-id $SUBNETID \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP
  --enable-managed-identity \
  --assign-identity <identity-resource-id> \
  --assign-kubelet-identity <kubelet-identity-resource-id>

Activer l’accès des développeurs au serveur d’API

Si vous avez utilisé les plages d’adresses IP autorisées pour votre 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. Vous pouvez également 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.

Récupérez votre adresse IP à l’aide de la commande suivante :

CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)

Ajoutez l’adresse IP aux plages approuvées au moyen de la commande az aks update.

az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32

Configurez kubectl pour qu’il se connecte à votre cluster AKS à l’aide de la commande az aks get-credentials.
```
az aks get-credentials -g $RG -n $AKSNAME
```

Déploiement d’un service public

Vous pouvez maintenant commencer à exposer des services et à déployer des applications sur ce cluster. Dans cet exemple, nous allons exposer un service public, mais vous pouvez également choisir d’exposer un service interne au moyen d’un équilibreur de charge interne.

Règle DNAT de service public

Copiez le code YAML suivant et enregistrez-le 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/aks/samples/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/aks/samples/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/aks/samples/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 à l’aide de la commande kubectl apply.
```
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 Azure 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, vous devez écrire une règle DNAT 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. Vous pouvez personnaliser l’adresse de destination. 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 également spécifier l’adresse IP interne attribuée à l’équilibreur de charge créé par le service Kubernetes.

Obtenez l’adresse IP interne attribuée à l’équilibreur de charge à l’aide de la commande kubectl get services.

kubectl get services

L’adresse IP est répertoriée dans la colonne EXTERNAL-IP, comme indiqué dans l’exemple de sortie suivant :

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

Obtenez l’adresse IP du service à l’aide de la commande kubectl get svc voting-app.

 SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')

Ajoutez la règle NAT à l’aide de la commande az network firewall nat-rule create.

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.

Capture d’écran montrant l’application AKS Voting avec des boutons pour Cats, Dogs, Reset et les totaux.

Nettoyer les ressources

Pour effacer les ressources Azure, supprimez le groupe de ressources AKS à l’aide de la commande az group delete.

az group delete -g $RG

Étapes suivantes

Dans cet article, vous avez appris à sécuriser votre trafic sortant à l’aide du Pare-feu Azure. Si nécessaire, vous pouvez généraliser la procédure ci-dessus pour transférer le trafic vers votre solution de sortie préférée, en suivant la documentation sur userDefinedRoute de type sortant.

Contrôler le trafic de sortie à l’aide du Pare-feu Azure dans Azure Kubernetes Service (AKS)

Définir la configuration à l’aide de variables d’environnement

Créer un réseau virtuel comprenant plusieurs sous-réseaux

Créer et configurer un Pare-feu Azure avec une route définie par l’utilisateur

Créer une route définie par l’utilisateur avec un tronçon vers le pare-feu Azure

Ajouter des règles de pare-feu

Associer la table de routage à AKS

Déployer un cluster AKS avec un type UDR sortant sur le réseau existant

Créer un cluster AKS avec des identités affectées par le système

Créer des identités attribuées par l’utilisateur

Créer un cluster AKS avec des identités affectées par l’utilisateur

Activer l’accès des développeurs au serveur d’API

Déploiement d’un service public

Ajouter une règle DNAT au pare-feu Azure

Valider la connectivité

Nettoyer les ressources

Étapes suivantes

Ressources supplémentaires

Ressources supplémentaires