Déployer une application web Amazon Web Services (AWS) sur Azure

Dans cet article, vous déployez l’application Yelb sur le cluster Azure Kubernetes Service (AKS) que vous avez créé dans l’article précédent.

Vérifier l’environnement

Avant de déployer l’application, vérifiez que votre cluster AKS est correctement configuré à l’aide des commandes suivantes :

Répertoriez les espaces de noms dans votre cluster à l’aide de la kubectl get namespace commande.

kubectl get namespace

Si vous avez installé le contrôleur d’entrée NGINX à l’aide du module complémentaire de routage d’application, vous devez voir l’espace de noms app-routing-system dans la sortie :

NAME                 STATUS   AGE
app-routing-system   Active   4h28m
cert-manager         Active   109s
dapr-system          Active   4h18m
default              Active   4h29m
gatekeeper-system    Active   4h28m
kube-node-lease      Active   4h29m
kube-public          Active   4h29m
kube-system          Active   4h29m

Si vous avez installé le contrôleur NGINX Ingress via Helm, vous devriez voir l'espace de noms ingress-basic dans la sortie :

NAME                STATUS   AGE
cert-manager        Active   7m42s
dapr-system         Active   11m
default             Active   21m
gatekeeper-system   Active   20m
ingress-basic       Active   7m19s
kube-node-lease     Active   21m
kube-public         Active   21m
kube-system         Active   21m
prometheus          Active   8m9s

Obtenez les détails du service du app-routing-system ou de l’espace de noms ingress-basic à l’aide du kubectl get service command.

kubectl get service --namespace <namespace-name> -o wide

Si vous avez utilisé le module complémentaire de routage d'application, vous devriez voir que le EXTERNAL-IP du service nginx est une adresse IP privée. Cette adresse est l’adresse IP privée d’une configuration IP frontale dans l’équilibreur kubernetes-internal de charge privé de votre cluster AKS :

NAME    TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                                      AGE     SELECTOR
nginx   LoadBalancer   172.16.55.104   10.240.0.7    80:31447/TCP,443:31772/TCP,10254:30459/TCP   4h28m   app=nginx

Si vous avez utilisé Helm, vous devriez voir que le EXTERNAL-IP du service nginx-ingress-ingress-nginx-controller est une adresse IP privée. Cette adresse est l’adresse IP privée d’une configuration d’adresse IP frontale dans l’équilibreur kubernetes-internal de charge privé de votre cluster AKS.

NAME                                               TYPE           CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
nginx-ingress-ingress-nginx-controller             LoadBalancer   172.16.42.152    10.240.0.7    80:32117/TCP,443:32513/TCP   7m31s
nginx-ingress-ingress-nginx-controller-admission   ClusterIP      172.16.78.85     <none>        443/TCP                      7m31s
nginx-ingress-ingress-nginx-controller-metrics     ClusterIP      172.16.109.138   <none>        10254/TCP                    7m31s

Préparer le déploiement de l’application Yelb

Si vous souhaitez déployer l’exemple à l’aide de la terminaison TLS au niveau de l’Application Gateway et de l'appel Yelb via HTTP, vous pouvez trouver les scripts Bash et les modèles YAML pour déployer l’application Yelb dans le dossier http.

Si vous souhaitez déployer l’exemple en mettant en œuvre TLS de bout en bout à l'aide de l'architecture Azure Application Gateway, vous pouvez trouver les scripts Bash et les modèles YAML pour déployer l’application web dans le répertoire https.

Dans les sections restantes de cet article, nous vous guidons tout au long du processus de déploiement de l’exemple d’application à l’aide de l’approche TLS de bout en bout.

Personnaliser des variables

Avant d’exécuter des scripts, vous devez personnaliser les valeurs des variables dans le 00-variables.sh fichier. Ce fichier est inclus dans tous les scripts et contient les variables suivantes :

# Azure subscription and tenant
RESOURCE_GROUP_NAME="<aks-resource-group>"
SUBSCRIPTION_ID="$(az account show --query id --output tsv)"
SUBSCRIPTION_NAME="$(az account show --query name --output tsv)"
TENANT_ID="$(az account show --query tenantId --output tsv)"
AKS_CLUSTER_NAME="<aks-name>"
AGW_NAME="<application-gateway-name>"
AGW_PUBLIC_IP_NAME="<application-gateway-public-ip-name>"
DNS_ZONE_NAME="<your-azure-dns-zone-name-eg-contoso.com>"
DNS_ZONE_RESOURCE_GROUP_NAME="<your-azure-dns-zone-resource-group-name>"
DNS_ZONE_SUBSCRIPTION_ID="<your-azure-dns-zone-subscription-id>"

# NGINX ingress controller installed via Helm
NGINX_NAMESPACE="ingress-basic"
NGINX_REPO_NAME="ingress-nginx"
NGINX_REPO_URL="https://kubernetes.github.io/ingress-nginx"
NGINX_CHART_NAME="ingress-nginx"
NGINX_RELEASE_NAME="ingress-nginx"
NGINX_REPLICA_COUNT=3

# Specify the ingress class name for the ingress controller
# - nginx: Unmanaged NGINX ingress controller installed via Helm
# - webapprouting.kubernetes.azure.com: Managed NGINX ingress controller installed via AKS application routing add-on
INGRESS_CLASS_NAME="webapprouting.kubernetes.azure.com"

# Subdomain of the Yelb UI service
SUBDOMAIN="<yelb-application-subdomain>"

# URL of the Yelb UI service
URL="https://$SUBDOMAIN.$DNS_ZONE_NAME"

# Secret provider class
KEY_VAULT_NAME="<key-vault-name>"
KEY_VAULT_CERTIFICATE_NAME="<key-vault-resource-group-name>"
KEY_VAULT_SECRET_PROVIDER_IDENTITY_CLIENT_ID="<key-vault-secret-provider-identity-client-id>"
TLS_SECRET_NAME="yelb-tls-secret"
NAMESPACE="yelb"

Vous pouvez exécuter la commande az aks show suivante pour récupérer l’clientId de l’identité managée affectée par l’utilisateur utilisée par leFournisseur Azure Key Vault du pilote CSI du magasin de secrets. Rôle Administrateur Key Vault du module keyVault.bicep à l’identité managée affectée par l’utilisateur du module complémentaire pour lui permettre de récupérer le certificat utilisé par Kubernetes Ingress utilisé pour exposer le service yelb-ui via le contrôleur d’entrée NGINX.
```
az aks show \
  --name <aks-name> \
  --resource-group <aks-resource-group-name> \
  --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
  --output tsv \
  --only-show-errors
```

Si vous avez déployé l’infrastructure Azure à l’aide des modules Bicep fournis avec cet exemple, vous pouvez continuer à déployer l’application Yelb. Si vous souhaitez déployer l’application dans votre cluster AKS, vous pouvez utiliser les scripts suivants pour configurer votre environnement. Vous pouvez utiliser le 02-create-nginx-ingress-controller.shcontrôleur d’entrée NGINX avec le pare-feu d’applications web open source ModSecurity activé.

#!/bin/bash

# Variables
source ./00-variables.sh

# Check if the NGINX ingress controller Helm chart is already installed
result=$(helm list -n $NGINX_NAMESPACE | grep $NGINX_RELEASE_NAME | awk '{print $1}')

if [[ -n $result ]]; then
  echo "[$NGINX_RELEASE_NAME] NGINX ingress controller release already exists in the [$NGINX_NAMESPACE] namespace"
else
  # Check if the NGINX ingress controller repository is not already added
  result=$(helm repo list | grep $NGINX_REPO_NAME | awk '{print $1}')

  if [[ -n $result ]]; then
    echo "[$NGINX_REPO_NAME] Helm repo already exists"
  else
    # Add the NGINX ingress controller repository
    echo "Adding [$NGINX_REPO_NAME] Helm repo..."
    helm repo add $NGINX_REPO_NAME $NGINX_REPO_URL
  fi

  # Update your local Helm chart repository cache
  echo 'Updating Helm repos...'
  helm repo update

  # Deploy NGINX ingress controller
  echo "Deploying [$NGINX_RELEASE_NAME] NGINX ingress controller to the [$NGINX_NAMESPACE] namespace..."
  helm install $NGINX_RELEASE_NAME $NGINX_REPO_NAME/$nginxChartName \
    --create-namespace \
    --namespace $NGINX_NAMESPACE \
    --set controller.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.replicaCount=$NGINX_REPLICA_COUNT \
    --set defaultBackend.nodeSelector."kubernetes\.io/os"=linux \
    --set controller.service.annotations."service\.beta\.kubernetes\.io/azure-load-balancer-health-probe-request-path"=/healthz
fi

# Get values
helm get values $NGINX_RELEASE_NAME --namespace $NGINX_NAMESPACE

Déployer l’application

Exécutez le script suivant 03-deploy-yelb.sh pour déployer l’application Yelb et un objet d’entrée Kubernetes pour rendre le yelb-ui service accessible à l’Internet public.

#!/bin/bash

# Variables
source ./00-variables.sh

# Check if namespace exists in the cluster
result=$(kubectl get namespace -o jsonpath="{.items[?(@.metadata.name=='$NAMESPACE')].metadata.name}")

if [[ -n $result ]]; then
  echo "$NAMESPACE namespace already exists in the cluster"
else
  echo "$NAMESPACE namespace does not exist in the cluster"
  echo "creating $NAMESPACE namespace in the cluster..."
  kubectl create namespace $NAMESPACE
fi

# Create the Secret Provider Class object
echo "Creating the secret provider class object..."
cat <<EOF | kubectl apply -f -
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  namespace: $NAMESPACE
  name: yelb
spec:
  provider: azure
  secretObjects:
    - secretName: $TLS_SECRET_NAME
      type: kubernetes.io/tls
      data: 
        - objectName: $KEY_VAULT_CERTIFICATE_NAME
          key: tls.key
        - objectName: $KEY_VAULT_CERTIFICATE_NAME
          key: tls.crt
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "true"
    userAssignedIdentityID: $KEY_VAULT_SECRET_PROVIDER_IDENTITY_CLIENT_ID
    keyvaultName: $KEY_VAULT_NAME
    objects: |
      array:
        - |
          objectName: $KEY_VAULT_CERTIFICATE_NAME
          objectType: secret
    tenantId: $TENANT_ID
EOF

# Apply the YAML configuration
kubectl apply -f yelb.yml

echo "waiting for secret $TLS_SECRET_NAME in namespace $namespace..."

while true; do
  if kubectl get secret -n $NAMESPACE $TLS_SECRET_NAME >/dev/null 2>&1; then
    echo "secret $TLS_SECRET_NAME found!"
    break
  else
    printf "."
    sleep 3
  fi
done

# Create chat-ingress
cat ingress.yml |
  yq "(.spec.ingressClassName)|="\""$INGRESS_CLASS_NAME"\" |
  yq "(.spec.tls[0].hosts[0])|="\""$SUBDOMAIN.$DNS_ZONE_NAME"\" |
  yq "(.spec.tls[0].secretName)|="\""$TLS_SECRET_NAME"\" |
  yq "(.spec.rules[0].host)|="\""$SUBDOMAIN.$DNS_ZONE_NAME"\" |
  kubectl apply -f -

# Check the deployed resources within the yelb namespace:
kubectl get all -n yelb

Mettez à jour le yelb-ui manifeste YAML pour inclure la csi volume définition et volume mount pour lire le certificat en tant que secret depuis Azure Key Vault.

apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: yelb
  name: yelb-ui
spec:
  replicas: 1
  selector:
    matchLabels:
      app: yelb-ui
      tier: frontend
  template:
    metadata:
      labels:
        app: yelb-ui
        tier: frontend
    spec:
      containers:
        - name: yelb-ui
          image: mreferre/yelb-ui:0.7
          ports:
            - containerPort: 80
          volumeMounts:
            - name: secrets-store-inline
              mountPath: "/mnt/secrets-store"
              readOnly: true
      volumes:
        - name: secrets-store-inline
          csi:
            driver: secrets-store.csi.k8s.io
            readOnly: true
            volumeAttributes:
              secretProviderClass: yelb

Vous pouvez maintenant déployer l’application. Le script utilise le yelb.yml manifeste YAML pour déployer l’application et créer ingress.yml l’objet d’entrée. Si vous utilisez une zone DNS publique Azure pour la résolution de noms de domaine, vous pouvez utiliser le 04-configure-dns.sh script. Ce script associe l’adresse IP publique du contrôleur d’entrée NGINX au domaine utilisé par l’objet d’entrée, qui expose le yelb-ui service. Le script effectue les étapes suivantes :
1. Récupère l’adresse publique de l’adresse IP publique Azure utilisée par la configuration IP frontale de l'Application Gateway.
2. Vérifie si un A enregistrement existe pour le sous-domaine utilisé par le yelb-ui service.
3. Si l’enregistrement A n’existe pas, le script le crée.

source ./00-variables.sh

# Get the address of the Application Gateway Public IP
echo "Retrieving the address of the [$AGW_PUBLIC_IP_NAME] public IP address of the [$AGW_NAME] Application Gateway..."
PUBLIC_IP_ADDRESS=$(az network public-ip show \
    --resource-group $RESOURCE_GROUP_NAME \
    --name $AGW_PUBLIC_IP_NAME \
    --query ipAddress \
    --output tsv \
    --only-show-errors)
if [[ -n $PUBLIC_IP_ADDRESS ]]; then
    echo "[$PUBLIC_IP_ADDRESS] public IP address successfully retrieved for the [$AGW_NAME] Application Gateway"
else
    echo "Failed to retrieve the public IP address of the [$AGW_NAME] Application Gateway"
    exit
fi
# Check if an A record for todolist subdomain exists in the DNS Zone
echo "Retrieving the A record for the [$SUBDOMAIN] subdomain from the [$DNS_ZONE_NAME] DNS zone..."
IPV4_ADDRESS=$(az network dns record-set a list \
    --zone-name $DNS_ZONE_NAME \
    --resource-group $DNS_ZONE_RESOURCE_GROUP_NAME \
    --subscription $DNS_ZONE_SUBSCRIPTION_ID \
    --query "[?name=='$SUBDOMAIN'].ARecords[].IPV4_ADDRESS" \
    --output tsv \
    --only-show-errors)
if [[ -n $IPV4_ADDRESS ]]; then
    echo "An A record already exists in [$DNS_ZONE_NAME] DNS zone for the [$SUBDOMAIN] subdomain with [$IPV4_ADDRESS] IP address"
    if [[ $IPV4_ADDRESS == $PUBLIC_IP_ADDRESS ]]; then
        echo "The [$IPV4_ADDRESS] ip address of the existing A record is equal to the ip address of the ingress"
        echo "No additional step is required"
        continue
    else
        echo "The [$IPV4_ADDRESS] ip address of the existing A record is different than the ip address of the ingress"
    fi
    # Retrieving name of the record set relative to the zone
    echo "Retrieving the name of the record set relative to the [$DNS_ZONE_NAME] zone..."
    RECORDSET_NAME=$(az network dns record-set a list \
        --zone-name $DNS_ZONE_NAME \
        --resource-group $DNS_ZONE_RESOURCE_GROUP_NAME \
        --subscription $DNS_ZONE_SUBSCRIPTION_ID \
        --query "[?name=='$SUBDOMAIN'].name" \
        --output tsv \
        --only-show-errors 2>/dev/null)
    if [[ -n $RECORDSET_NAME ]]; then
        echo "[$RECORDSET_NAME] record set name successfully retrieved"
    else
        echo "Failed to retrieve the name of the record set relative to the [$DNS_ZONE_NAME] zone"
        exit
    fi
    # Remove the A record
    echo "Removing the A record from the record set relative to the [$DNS_ZONE_NAME] zone..."
    az network dns record-set a remove-record \
        --ipv4-address $IPV4_ADDRESS \
        --record-set-name $RECORDSET_NAME \
        --zone-name $DNS_ZONE_NAME \
        --resource-group $DNS_ZONE_RESOURCE_GROUP_NAME \
        --subscription $DNS_ZONE_SUBSCRIPTION_ID \
        --only-show-errors 1>/dev/null
    if [[ $? == 0 ]]; then
        echo "[$IPV4_ADDRESS] ip address successfully removed from the [$RECORDSET_NAME] record set"
    else
        echo "Failed to remove the [$IPV4_ADDRESS] ip address from the [$RECORDSET_NAME] record set"
        exit
    fi
fi
# Create the A record
echo "Creating an A record in [$DNS_ZONE_NAME] DNS zone for the [$SUBDOMAIN] subdomain with [$PUBLIC_IP_ADDRESS] IP address..."
az network dns record-set a add-record \
    --zone-name $DNS_ZONE_NAME \
    --resource-group $DNS_ZONE_RESOURCE_GROUP_NAME \
    --subscription $DNS_ZONE_SUBSCRIPTION_ID \
    --record-set-name $SUBDOMAIN \
    --ipv4-address $PUBLIC_IP_ADDRESS \
    --only-show-errors 1>/dev/null
if [[ $? == 0 ]]; then
    echo "A record for the [$SUBDOMAIN] subdomain with [$PUBLIC_IP_ADDRESS] IP address successfully created in [$DNS_ZONE_NAME] DNS zone"
else
    echo "Failed to create an A record for the $SUBDOMAIN subdomain with [$PUBLIC_IP_ADDRESS] IP address in [$DNS_ZONE_NAME] DNS zone"
fi

Remarque

Avant de déployer l’application Yelb et de créer l’objet ingress , le script génère un SecretProviderClass certificat TLS à partir d’Azure Key Vault et génère le secret Kubernetes pour l’objet ingress . Il est important de noter que le Pilote CSI du magasin de secrets pour Key Vault ne crée le secret Kubernetes contenant le certificat TLS que lorsque la définition du SecretProviderClass et du volume sont incluses dans le deployment. Pour vous assurer que le certificat TLS est correctement récupéré à partir d’Azure Key Vault et stocké dans le secret Kubernetes utilisé par l’objet ingress , nous devons apporter les modifications suivantes au manifeste YAML du yelb-ui déploiement :

Ajoutez la définition csi volume à l’aide du pilote secrets-store.csi.k8s.io, qui fait référence à l’objet SecretProviderClass responsable de la récupération du certificat TLS à partir d'Azure Key Vault.
Inclure volume mount pour lire le certificat en tant que secret à partir d’Azure Key Vault.

Pour plus d’informations, consultez Configurer le pilote CSI du magasin de secrets pour activer le contrôleur d’entrée NGINX avec TLS.

Tester l’application

Utilisez le 05-call-yelb-ui.sh script pour appeler le yelb-ui service, simuler l’injection SQL, les attaques XSS et observer comment l’ensemble de règles managées de ModSecurity bloque les requêtes malveillantes.

#!/bin/bash
# Variables
source ./00-variables.sh
# Call REST API
echo "Calling Yelb UI service at $URL..."
curl -w 'HTTP Status: %{http_code}\n' -s -o /dev/null $URL
# Simulate SQL injection
echo "Simulating SQL injection when calling $URL..."
curl -w 'HTTP Status: %{http_code}\n' -s -o /dev/null $URL/?users=ExampleSQLInjection%27%20--
# Simulate XSS
echo "Simulating XSS when calling $URL..."
curl -w 'HTTP Status: %{http_code}\n' -s -o /dev/null $URL/?users=ExampleXSS%3Cscript%3Ealert%28%27XSS%27%29%3C%2Fscript%3E
# A custom rule blocks any request with the word blockme in the querystring.
echo "Simulating query string manipulation with the 'blockme' word in the query string..."
curl -w 'HTTP Status: %{http_code}\n' -s -o /dev/null $URL/?users?task=blockme

Le script Bash doit produire la sortie suivante, où le premier appel réussit, tandis que les règles ModSecurity bloquent les deux appels suivants :

Calling Yelb UI service at https://yelb.contoso.com...
HTTP Status: 200
Simulating SQL injection when calling https://yelb.contoso.com...
HTTP Status: 403
Simulating XSS when calling https://yelb.contoso.com...
HTTP Status: 403
Simulating query string manipulation with the 'blockme' word in the query string...
HTTP Status: 403

Surveiller l’application

Dans la solution proposée, le processus de déploiement configure automatiquement la ressource Azure Application Gateway pour collecter les journaux de diagnostic et les métriques dans un espace de travail Azure Log Analytics. En activant les journaux d’activité, vous pouvez obtenir de précieux insights sur les évaluations, les correspondances et les blocs effectués par le Azure Web Application Firewall (WAF) dans Application Gateway. Pour plus d’informations, consultez journaux de diagnostic pour Application Gateway. Vous pouvez également utiliser Log Analytics pour examiner les données dans les journaux de pare-feu. Une fois les journaux du pare-feu dans votre espace de travail Log Analytics, vous pouvez afficher les données, écrire des requêtes, créer des visualisations, et ajouter ces dernières au tableau de bord de votre portail. Pour plus d’informations sur les requêtes de journal, consultez Vue d’ensemble des requêtes de journal dans Azure Monitor.

Explorer des données avec des requêtes Kusto

Vous pouvez également utiliser Log Analytics pour examiner les données dans les journaux de pare-feu. Une fois les journaux du pare-feu dans votre espace de travail Log Analytics, vous pouvez afficher les données, écrire des requêtes, créer des visualisations, et ajouter ces dernières au tableau de bord de votre portail. Pour plus d’informations sur les requêtes de journal, consultez Vue d’ensemble des requêtes de journal dans Azure Monitor.

AzureDiagnostics 
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| limit 10

Vous pouvez également accéder aux données brutes du journal de pare-feu en utilisant la table spécifique à la ressource avec la requête suivante. Pour en savoir plus sur les tables spécifiques aux ressources, reportez-vous à la documentation de référence sur les données de surveillance .

AGWFirewallLogs
| limit 10

Une fois que vous disposez des données, vous pouvez approfondir et créer des graphiques ou des visualisations. Voici quelques exemples supplémentaires de requêtes KQL qui peuvent être utilisées :

Requêtes mises en correspondance/bloquées par adresse IP

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| summarize count() by clientIp_s, bin(TimeGenerated, 1m)
| render timechart

Requêtes mises en correspondance/bloquées par URI

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| summarize count() by requestUri_s, bin(TimeGenerated, 1m)
| render timechart

Principales règles mises en correspondance

| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| summarize count() by ruleId_s, bin(TimeGenerated, 1m)
| where count_ > 10
| render timechart

Cinq principaux groupes de règles mis en correspondance

AzureDiagnostics
| where ResourceProvider == "MICROSOFT.NETWORK" and Category == "ApplicationGatewayFirewallLog"
| summarize Count=count() by details_file_s, action_s
| top 5 by Count desc
| render piechart

Passer en revue les ressources déployées

Vous pouvez utiliser Azure CLI ou Azure PowerShell pour répertorier les ressources déployées dans le groupe de ressources.

Azure CLI
Azure PowerShell

Répertoriez les ressources déployées dans le groupe de ressources à l’aide de la commande [az resource list][az-resource-list].

az resource list --resource-group <resource-group-name>

Répertoriez les ressources déployées dans le groupe de ressources à l’aide de l’applet de commande [Get-AzResource][get-azresource].

Get-AzResource -ResourceGroupName <resource-group-name>

Vous pouvez utiliser Azure CLI ou Azure PowerShell pour supprimer le groupe de ressources lorsque vous n’avez plus besoin des ressources que vous avez créées dans ce didacticiel.

Azure CLI
Azure PowerShell

Supprimez le groupe de ressources et ses ressources associées à l’aide de la az group delete commande.

az group delete --name <resource-group-name>

Supprimez le groupe de ressources et ses ressources associées à l’aide de la cmdlet Remove-AzResourceGroup.

Remove-AzResourceGroup -Name <resource-group-name>

Étapes suivantes

Vous pouvez augmenter la sécurité et la protection contre les menaces de la solution à l’aide d’Azure DDoS Protection et du Pare-feu Azure. Pour plus d’informations, consultez les articles suivants :

Si vous utilisez le contrôleur d’entrée NGINX ou tout autre contrôleur d’entrée hébergé PAR AKS à la place d’Azure Application Gateway, vous pouvez utiliser le pare-feu Azure pour inspecter le trafic vers et depuis le cluster AKS et protéger le cluster contre l’exfiltration des données et d’autres trafics réseau non souhaités. Pour plus d’informations, consultez les articles suivants :

Contributeurs

Microsoft gère cet article. Les contributeurs suivants ont rédigé sa version d’origine:

Auteur principal :

Paolo Salvatori | Ingénieur client principal

Autres contributeurs :

Ken Kilty Responsable de programme technique principal
Russell de Pina | Responsable de programme technique principal
Erin Schaffer | Développeur de contenu 2

Commentaires

Cette page a-t-elle été utile ?

Last updated on 2025-04-23