Nasazení webové aplikace Amazon Web Services (AWS) do Azure

V tomto článku nasadíte aplikaci Yelb do clusteru Azure Kubernetes Service (AKS), který jste vytvořili v článku previous.

Kontrola prostředí

Před nasazením aplikace se ujistěte, že je cluster AKS správně nakonfigurovaný pomocí následujících příkazů:

1. Vypište obory názvů ve vašem clusteru pomocí příkazu kubectl get namespace.

   kubectl get namespace
   

   Pokud jste nainstalovali NGINX ingress controller pomocí doplňku pro směrování aplikace, měli byste ve výstupu vidět app-routing-system namespace:

   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
   

   Pokud jste nainstalovali kontroler příchozího přenosu dat NGINX přes Helm, měli byste ve výstupu vidět ingress-basic obor názvů:

   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. Získejte podrobnosti o službě app-routing-system, nebo o oboru názvů ingress-basic pomocí kubectl get service command.

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

   Pokud jste použili doplněk pro směrování aplikací, měli byste vidět, že EXTERNAL-IP služby nginx je privátní IP adresa. Tato adresa je privátní IP adresa konfigurace front-endové IP adresy v privátním kubernetes-internal nástroji pro vyrovnávání zatížení vašeho clusteru 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
   

   Pokud jste použili Helm, měli byste vidět, že EXTERNAL-IP služby nginx-ingress-ingress-nginx-controller má privátní IP adresu. Tato adresa je privátní IP front-endové konfigurace v privátním kubernetes-internal load balanceru vašeho clusteru 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
   

Příprava na nasazení aplikace Yelb

Pokud chcete ukázku nasadit pomocí ukončení protokolu TLS ve službě Application Gateway a volání Yelb prostřednictvím přístupu HTTP , najdete skripty Bash a šablony YAML pro nasazení aplikace Yelb ve http složce.

Pokud chcete ukázku nasadit pomocí architektury Implementing end-to-end TLS pomocí architektury Azure Application Gateway, najdete skripty Bash a šablony YAML pro nasazení webové aplikace do složky https.

Ve zbývajících částech tohoto článku vás provedeme procesem nasazení ukázkové aplikace pomocí kompletního přístupu TLS.

Přizpůsobení proměnných

1. Před spuštěním skriptů je nutné přizpůsobit hodnoty proměnných v 00-variables.sh souboru. Tento soubor je součástí všech skriptů a obsahuje následující proměnné:

   # 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. Spuštěním následujícího příkazu az aks show načtěte clientId uživatelskou přiřazenou spravovanou identitu použitou poskytovatelem Azure Key Vault pro ovladač CSI pro úložiště tajemství. Modul přiřadí roli keyVault.bicepKey Vault Administrator uživatelem přiřazené spravované identitě doplňku, aby mohla načíst certifikát používaný komponentou Kubernetes Ingress ke zpřístupnění služby yelb-ui prostřednictvím řadiče NGINX Ingress.

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

3. Pokud jste nasadili infrastrukturu Azure pomocí modulů Bicep poskytovaných touto ukázkou, můžete pokračovat v nasazení aplikace Yelb. Pokud chcete nasadit aplikaci v clusteru AKS, můžete ke konfiguraci prostředí použít následující skripty. Můžete použít 02-create-nginx-ingress-controller.sh k instalaci kontroleru příchozího přenosu dat NGINX s povoleným opensourcovým firewallem webových aplikací ModSecurity (WAF).

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

Nasazení aplikace

1. Spuštěním následujícího 03-deploy-yelb.sh skriptu nasaďte aplikaci Yelb a objekt Kubernetes Ingress, aby služba byla přístupná z veřejného internetu.

   #!/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. Aktualizujte manifest YAML yelb-ui tak, aby zahrnoval definici csi volume a volume mount, aby se certifikát přečetl jako tajný kód z 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

3. Teď můžete aplikaci nasadit. Skript používá manifest yelb.yml YAML k nasazení aplikace a ingress.yml k vytvoření objektu ingress. Jestliže pro rozlišení názvů domén používáte veřejnou zónu DNS Azure, můžete použít skript 04-configure-dns.sh. Tento skript přidruží veřejnou IP adresu kontroleru příchozího přenosu dat NGINX k doméně používané objektem příchozího yelb-ui přenosu dat, která službu zveřejňuje. Skript provede následující kroky:

   1. Načte veřejnou adresu Azure veřejné IP, kterou používá konfigurace front-endové IP služby Application Gateway.
   2. Zkontroluje, jestli A pro subdoménu yelb-ui používanou službou existuje záznam.
   3. A Pokud záznam neexistuje, skript ho vytvoří.

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

Poznámka:

Před nasazením aplikace Yelb a vytvořením objektu ingress skript vygeneruje SecretProviderClass, který načte certifikát TLS z Azure Key Vault a vygeneruje tajný kód Kubernetes pro objekt ingress. Je důležité si uvědomit, že Secrets Store CSI Driver pro Key Vault vytvoří Kubernetes tajemství obsahující TLS certifikát jen tehdy, když je SecretProviderClass spolu s definicí svazku zahrnuta v deployment. Abychom zajistili, že se certifikát TLS správně načte z Azure Key Vault a uloží se do tajného kódu Kubernetes používaného objektem ingress, musíme v manifestu YAML nasazení yelb-ui provést následující změny:

• Přidejte definici csi volume pomocí ovladače secrets-store.csi.k8s.io, který odkazuje na objekt SecretProviderClass zodpovědný za načtení certifikátu TLS z Azure Key Vault.
• Zahrňte volume mount ke čtení certifikátu jako tajného klíče z Azure Key Vault.

Další informace naleznete v části Set up Secrets Store CSI Driver k povolení NGINX ingress controller s TLS.

Otestování aplikace

05-call-yelb-ui.sh Pomocí skriptu můžete vyvolat yelb-ui službu, simulovat injektáž SQL, útoky XSS a sledovat, jak spravovaná sada pravidel ModSecurity blokuje škodlivé požadavky.

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

Skript Bash by měl vytvořit následující výstup, kde první volání proběhne úspěšně, zatímco pravidla ModSecurity blokují následující dvě volání:

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

Monitorujte aplikaci

V navrhovaném řešení proces nasazení automaticky nakonfiguruje prostředek Azure Application Gateway ke shromažďování diagnostických protokolů a metrik do pracovního prostoru Azure Log Analytics. Povolením protokolů můžete získat cenné přehledy o vyhodnoceních, shodách a blocích provedených Azure Web Application Firewall (WAF) ve službě Application Gateway. Další informace najdete v diagnostických protokolech služby Application Gateway. K prozkoumání dat v protokolech brány firewall můžete použít také Log Analytics. Pokud máte v pracovním prostoru Log Analytics protokoly brány firewall, můžete zobrazit data, psát dotazy, vytvářet vizualizace a přidávat je na řídicí panel portálu. Podrobné informace o dotazech protokolu najdete v tématu Přehled dotazů protokolu v Azure Monitor.

Zkoumání dat pomocí dotazů Kusto

V navrhovaném řešení proces nasazení automaticky nakonfiguruje prostředek Azure Application Gateway ke shromažďování diagnostických protokolů a metrik do pracovního prostoru Azure Log Analytics. Povolením logů můžete získat přehled o vyhodnoceních, shodách a zablokování provedených Azure Web Application Firewall (WAF) v rámci Application Gateway. Další informace najdete v diagnostických protokolech služby Application Gateway.

K prozkoumání dat v protokolech brány firewall můžete použít také Log Analytics. Pokud máte v pracovním prostoru Log Analytics protokoly brány firewall, můžete zobrazit data, psát dotazy, vytvářet vizualizace a přidávat je na řídicí panel portálu. Další informace o dotazech protokolu najdete v tématu Přehled dotazů protokolu v Azure Monitor.

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

Při práci s Resource-specific tabulkou lze přistupovat k nezpracovaným datům z protokolu brány firewall pomocí následujícího dotazu. Další informace o tabulkách specifických pro prostředky najdete v referenční dokumentaci k datům monitorování .

AGWFirewallLogs
| limit 10

Jakmile máte data, můžete se ponořit hlouběji a vytvářet grafy nebo vizualizace. Tady je několik dalších příkladů dotazů KQL , které je možné využít:

Spárované nebo blokované požadavky podle IP adresy

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

Spárované nebo blokované požadavky podle identifikátoru URI

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

Nejvíce shodná pravidla

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

Prvních pět odpovídajících skupin pravidel

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

Kontrola nasazených prostředků

K výpisu nasazených prostředků ve skupině prostředků můžete použít Azure CLI nebo Azure PowerShell.

Azure CLI

Pomocí příkazu [az resource list][az-resource-list] zobrazte seznam nasazených prostředků ve skupině prostředků.

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

Azure PowerShell

Vypište nasazené prostředky ve skupině prostředků pomocí rutiny [Get-AzResource][get-azresource].

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

Skupinu prostředků můžete odstranit pomocí Azure CLI nebo Azure PowerShell, pokud už nepotřebujete prostředky, které jste vytvořili v tomto kurzu.

Azure CLI

Pomocí příkazu odstraňte skupinu prostředků a její přidružené prostředky az group delete .

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

Azure PowerShell

Pomocí rutiny Remove-AzResourceGroup odstraňte skupinu prostředků a její přidružené prostředky.

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

Další kroky

Zabezpečení a ochranu před hrozbami řešení můžete zvýšit pomocí služby Azure DDoS Protection a Azure Firewall. Další informace najdete v následujících článcích:

• Tutorial: Ochrana aplikační brány pomocí služby Azure DDoS Network Protection
• Firewall a aplikační brána pro virtuální sítě
• nulová důvěra (Zero Trust) síť pro webové aplikace s Azure Firewall a službou Application Gateway

Pokud místo Azure Application Gateway používáte kontroler příchozího přenosu dat NGINX nebo jakýkoli jiný kontroler příchozího přenosu dat hostovaný službou AKS, můžete ke kontrole provozu do a z clusteru AKS použít Azure Firewall a chránit cluster před exfiltrací dat a jiným nežádoucím síťovým provozem. Další informace najdete v následujících článcích:

• Použití Azure Firewall k ochraně clusterů Azure Kubernetes Service (AKS)
• Použití Azure Firewall k ochraně clusteru Azure Kubernetes Service (AKS)

Přispěvatelé

Microsoft tento článek udržuje. Následující přispěvatelé ho původně napsali:

Hlavní autor:

• Paolo Salvatori | Hlavní zákaznický inženýr

Další přispěvatelé:

• Ken Kilty | Hlavní technický programový manažer
• Russell de Pina | Hlavní manažer technického programu
• Erin Schaffer | Vývojář obsahu 2