Delen via

Implementeer een webapplicatie van Amazon Web Services (AWS) naar Azure.

In dit artikel implementeer je de Yelb-applicatie naar de Azure Kubernetes Service (AKS) cluster die je in het vorige artikel hebt aangemaakt.

De omgeving controleren

Voordat je de applicatie implementeert, zorg ervoor dat je AKS-cluster correct is geconfigureerd met behulp van de volgende commando's:

  1. Zet de namespaces in uw cluster op een rij met behulp van de kubectl get namespace-opdracht.

    kubectl get namespace

    Als je de NGINX-ingresscontroller hebt geïnstalleerd met behulp van de applicatierouting-add-on, zou je de app-routing-system-namespace in de uitvoer moeten zien.

    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

    Als je de NGINX ingress controller via Helm hebt geïnstalleerd, zou je de ingress-basic namespace in de uitvoer moeten zien.

    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

  2. Verkrijg de servicedetails van de app-routing-system of de ingress-basic-naamruimte met behulp van de kubectl get service command.

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

    Als u de application routing add-on heeft gebruikt, zou u moeten zien dat de EXTERNAL-IP van de nginx-service een privé-IP-adres is. Dit adres is het privé-IP van een frontend IP-configuratie in de kubernetes-internal private load balancer van uw AKS-cluster.

    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

    Als u Helm hebt gebruikt, zou u moeten zien dat de EXTERNAL-IP van de nginx-ingress-ingress-nginx-controller service een privé-IP-adres is. Deze adres is het privé-IP-adres van een frontend IP-configuratie in de kubernetes-internal privé-load balancer van uw AKS-cluster.

    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

Maak je klaar om de Yelb-toepassing te implementeren

Als u het voorbeeld wilt implementeren met de TLS-terminatie bij Application Gateway en Yelb-aanroep via HTTP-benadering, kunt u de Bash-scripts en YAML-sjablonen vinden om de Yelb-applicatie te implementeren in de http map.

Als u het voorbeeld wilt implementeren met behulp van de Implementing end-to-end TLS using Azure Application Gateway architectuur, kunt u de Bash-scripts en YAML-sjablonen vinden om de webapplicatie te implementeren in de map https.

In de resterende secties van dit artikel begeleiden we u door het implementatieproces van de voorbeeldapplicatie met behulp van de end-to-end TLS-aanpak.

Pas variabelen aan

  1. Voordat u scripts uitvoert, moet u de waarden van de variabelen in het 00-variables.sh-bestand aanpassen. This file is included in all scripts and contains the following variables:

    # 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"

  2. U kunt het volgende az aks show commando uitvoeren om de clientId van de door de gebruiker toegewezen beheerde identiteit te verkrijgen, gebruikt door de Azure Key Vault Provider voor Secrets Store CSI Driver. Ken de module de keyVault.bicep-rol Key Vault Administrator toe aan de gebruikers toegewezen beheerde identiteit van de addon, zodat het het certificaat kan ophalen dat wordt gebruikt door Kubernetes Ingress om de yelb-ui-dienst beschikbaar te maken via de NGINX-ingresscontroller.

    az aks show \
  --name <aks-name> \
  --resource-group <aks-resource-group-name> \
  --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
  --output tsv \
  --only-show-errors

  3. Als je de Azure-infrastructuur hebt geïmplementeerd met de Bicep-modules die bij dit voorbeeld zijn geleverd, kun je doorgaan met het implementeren van de Yelb-toepassing. Als je de applicatie in je AKS-cluster wilt implementeren, kun je de volgende scripts gebruiken om je omgeving te configureren. Je kunt de 02-create-nginx-ingress-controller.sh gebruiken om de NGINX ingress controller te installeren met de ModSecurity open-source webapplicatiefirewall (WAF) ingeschakeld.

    #!/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

De toepassing implementeren

  1. Voer het volgende 03-deploy-yelb.sh script uit om de Yelb-applicatie te implementeren en een Kubernetes Ingress-object aan te maken zodat de yelb-ui service toegankelijk is voor het openbare internet.

    #!/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

  2. Werk het yelb-ui YAML-manifest bij om de csi volume definitie op te nemen en laat volume mount het certificaat lezen als een geheim uit 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

  1. Je kunt nu de applicatie implementeren. Het script gebruikt het yelb.yml YAML manifest om de applicatie te implementeren en de ingress.yml om het ingress-object te creëren. Als u een Azure Public DNS Zone gebruikt voor domeinnaamresolutie, kunt u het 04-configure-dns.sh script gebruiken. Dit script koppelt het publieke IP-adres van de NGINX-ingresscontroller met het domein dat wordt gebruikt door het ingress-object, dat de yelb-ui-dienst aanbiedt. Het script voert de volgende stappen uit:

    1. Haalt het openbare adres op van de Azure openbare IP die wordt gebruikt door de front-end IP-configuratie van de Application Gateway.
    2. Controleert of er een A record bestaat voor het subdomein dat door de yelb-ui service wordt gebruikt.
    3. Als het A record niet bestaat, maakt het script het aan.
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

Opmerking

Voordat de Yelb-applicatie wordt geïmplementeerd en het ingress object wordt gemaakt, genereert het script een SecretProviderClass om het TLS-certificaat van Azure Key Vault op te halen en het Kubernetes-geheim voor het ingress object te genereren. Het is belangrijk op te merken dat de Secrets Store CSI Driver voor Key Vault het Kubernetes-geheim dat het TLS-certificaat bevat, alleen aanmaakt wanneer de SecretProviderClass en volumedefinitie is opgenomen in de deployment. Om ervoor te zorgen dat het TLS-certificaat correct wordt opgehaald uit Azure Key Vault en opgeslagen in het Kubernetes-geheim dat door het ingress-object wordt gebruikt, moeten we de volgende wijzigingen aanbrengen in het YAML-manifest van de yelb-ui-implementatie:

  • Voeg csi volume definities toe met behulp van de secrets-store.csi.k8s.io driver, die verwijst naar het SecretProviderClass object dat verantwoordelijk is voor het ophalen van het TLS-certificaat uit Azure Key Vault.
  • Neem volume mount op om het certificaat te lezen als een geheim uit Azure Key Vault.

Voor meer informatie kunt u Secrets Store CSI Driver instellen voor het inschakelen van NGINX ingress controller met TLS raadplegen.

De toepassing testen

Gebruik het 05-call-yelb-ui.sh script om de yelb-ui dienst aan te roepen, simuleer SQL-injectie, XSS-aanvallen, en observeer hoe de beheerde regelset van ModSecurity kwaadaardige verzoeken blokkeert.

#!/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

De Bash-script zou de volgende uitvoer moeten produceren, waarbij de eerste oproep slaagt, terwijl ModSecurity-regels de volgende twee oproepen blokkeren.

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

Het monitoren van de toepassing

In de voorgestelde oplossing configureert het implementatieproces automatisch de Azure Application Gateway-resource om diagnostische logboeken en statistieken te verzamelen in een Azure Log Analytics Workspace-werkruimte. Door logs in te schakelen, kunt u waardevolle inzichten verkrijgen in de evaluaties, overeenkomsten en blokkeringen die worden uitgevoerd door de Azure Web Application Firewall (WAF) binnen de Application Gateway. Voor meer informatie, zie Diagnostische logboeken voor Application Gateway. U kunt ook Log Analytics gebruiken om de gegevens in de firewall-logboeken te onderzoeken. Wanneer u de firewalllogboeken in uw Log Analytics-werkruimte hebt, kunt u gegevens bekijken, query's schrijven, visualisaties maken en deze toevoegen aan uw portaldashboard. Voor gedetailleerde informatie over logboekquery's, zie Overzicht van logboekquery's in Azure Monitor.

Onderzoek gegevens met Kusto-query's

In de voorgestelde oplossing configureert het implementatieproces automatisch de Azure Application Gateway-resource om diagnostische logs en statistieken te verzamelen in een Azure Log Analytics-werkruimte. Door logboeken in te schakelen, kunt u inzicht krijgen in de beoordelingen, overeenkomsten en blokkeringen die door de Azure Web Application Firewall (WAF) binnen de Application Gateway worden uitgevoerd. Voor meer informatie, zie Diagnostische logboeken voor Application Gateway.

U kunt ook Log Analytics gebruiken om de gegevens binnen de firewall-logboeken te onderzoeken. Wanneer u de firewalllogboeken in uw Log Analytics-werkruimte hebt, kunt u gegevens bekijken, query's schrijven, visualisaties maken en deze toevoegen aan uw portaldashboard. Voor meer informatie over logboekquery's, zie Overzicht van logboekquery's in Azure Monitor.

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

Als alternatief kan de ruwe firewall loggegevens worden benaderd via de volgende query wanneer u werkt met de Resource-specific tabel. Raadpleeg de Monitoringgegevensreferentie documentatie om meer te leren over resource-specifieke tabellen.

AGWFirewallLogs
| limit 10

Zodra je de gegevens hebt, kun je dieper graven en grafieken of visualisaties maken. Hier zijn enkele aanvullende voorbeelden van KQL-query's die kunnen worden gebruikt:

Overeenkomende/geblokkeerde aanvragen per IP

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

Overeenkomende/geblokkeerde aanvragen per URI

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

Meest overeenkomende regels

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

Top vijf overeenkomende regelgroepen

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

Geïmplementeerde middelen beoordelen

Je kunt Azure CLI of Azure PowerShell gebruiken om de geïmplementeerde resources in de resourcegroep weer te geven.

Lijst de geïmplementeerde resources in de resourcegroep met behulp van het [az resource list][az-resource-list] commando.

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

Je kunt Azure CLI of Azure PowerShell gebruiken om de resourcegroep te verwijderen wanneer je de middelen die je in deze tutorial hebt gemaakt niet meer nodig hebt.

Verwijder de resourcegroep en de bijbehorende resources met behulp van de az group delete opdracht.

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

Volgende stappen

U kunt de beveiliging en bedreigingsbescherming van de oplossing verbeteren met behulp van Azure DDoS Protection en Azure Firewall. Zie de volgende artikelen voor meer informatie:

Als u de NGINX-ingresscontroller of een andere AKS-gehoste ingresscontroller in plaats van de Azure Application Gateway gebruikt, kunt u de Azure Firewall gebruiken om verkeer van en naar het AKS-cluster te inspecteren en het cluster te beschermen tegen data-exfiltratie en ander ongewenst netwerkverkeer. Zie de volgende artikelen voor meer informatie:

Bijdragers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben het oorspronkelijk geschreven:

Hoofdauteur:

Andere Inzenders:

  • Last updated on