Rozmieść aplikację internetową Amazon Web Services (AWS) na platformie Azure

W tym artykule wdrażasz aplikację Yelb do klastra Azure Kubernetes Service (AKS), który utworzyłeś w poprzednim artykule.

Sprawdź środowisko

Zanim wdrożysz aplikację, upewnij się, że klaster AKS jest prawidłowo skonfigurowany, używając następujących poleceń:

Wymień przestrzenie nazw w swoim klastrze za pomocą komendy kubectl get namespace.

kubectl get namespace

Jeśli zainstalowałeś kontroler wejściowy NGINX za pomocą dodatku do routingu aplikacji, powinieneś zobaczyć przestrzeń nazw app-routing-system w wynikach:

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

Jeśli zainstalowałeś kontroler wejściowy NGINX za pomocą Helm, w wynikowym wyjściu powinieneś zobaczyć przestrzeń nazw ingress-basic.

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

Uzyskaj szczegóły usługi przestrzeni nazw app-routing-system lub ingress-basic za pomocą kubectl get service command.

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

Jeśli użyłeś dodatku do routingu aplikacji, powinieneś zobaczyć, że EXTERNAL-IP usługi to adres IP prywatny. Ten adres to prywatny adres IP konfiguracji frontendowej adresu IP w prywatnym load balancerze klastra 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

Jeśli użyłeś Helm, powinieneś zobaczyć, że EXTERNAL-IP usługi nginx-ingress-ingress-nginx-controller jest prywatnym adresem IP. Ten adres jest prywatnym IP konfiguracji IP frontonu w prywatnym równoważeniu obciążenia kubernetes-internal w zestawie klastrowym 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

Przygotuj się do wdrożenia aplikacji Yelb

Jeśli chcesz wdrożyć przykładową aplikację przy użyciu podejścia terminacji TLS na poziomie Application Gateway i wywoływania Yelb za pośrednictwem HTTP, możesz znaleźć skrypty Bash i szablony YAML do wdrożenia aplikacji Yelb w folderze http.

Jeśli chcesz wdrożyć przykład, korzystając z architektury Implementing end-to-end TLS using Azure Application Gateway, znajdziesz skrypty Bash i szablony YAML do wdrożenia aplikacji internetowej w folderze https.

W pozostałych częściach tego artykułu przeprowadzimy Cię przez proces wdrażania przykładowej aplikacji przy użyciu metody TLS typu end-to-end.

Dostosuj zmienne

Zanim uruchomisz jakiekolwiek skrypty, musisz dostosować wartości zmiennych w pliku 00-variables.sh. Ten plik jest dołączony do wszystkich skryptów i zawiera następujące zmienne:

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

Możesz uruchomić następujące polecenie az aks show, aby uzyskać clientId przypisanej przez użytkownika zarządzanej tożsamości używanej przez Azure Key Vault Provider for Secrets Store CSI Driver. Moduł keyVault.bicep przypisuje rolę Key Vault Administrator do tożsamości zarządzanej użytkownika przypisanego do dodatku, aby umożliwić jej pobranie certyfikatu używanego przez Kubernetes Ingress do udostępnienia usługi yelb-ui za pośrednictwem kontrolera wejścia NGINX.
```
az aks show \
  --name <aks-name> \
  --resource-group <aks-resource-group-name> \
  --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
  --output tsv \
  --only-show-errors
```

Jeśli wdrożyłeś infrastrukturę Azure za pomocą modułów Bicep dostarczonych z tym przykładem, możesz przejść do wdrożenia aplikacji Yelb. Jeśli chcesz wdrożyć aplikację w swoim klastrze AKS, możesz użyć poniższych skryptów do skonfigurowania swojego środowiska. Możesz użyć 02-create-nginx-ingress-controller.sh do instalacji kontrolera wejścia NGINX z włączonym zaporą aplikacji webowych (WAF) ModSecurity open-source.

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

Wdrażanie aplikacji

Uruchom poniższy 03-deploy-yelb.sh skrypt, aby wdrożyć aplikację Yelb i obiekt Kubernetes Ingress, aby udostępnić usługę yelb-ui w publicznym internecie.

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

Zaktualizuj manifest YAML yelb-ui, aby uwzględniał definicję csi volume oraz volume mount, aby odczytać certyfikat jako tajny 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

Możesz teraz wdrożyć aplikację. Skrypt używa yelb.yml manifestu YAML do wdrożenia aplikacji i ingress.yml do utworzenia obiektu wejściowego. Jeśli używasz Azure Public DNS Zone do rozwiązywania nazw domen, możesz użyć skryptu 04-configure-dns.sh. Ten skrypt kojarzy publiczny adres IP kontrolera wejścia NGINX z domeną używaną przez obiekt wejściowy, który ujawnia usługę yelb-ui. Skrypt wykonuje następujące kroki:
1. Pobiera publiczny adres publicznego adresu IP Azure używanego przez konfigurację IP front-endu w Application Gateway.
2. Sprawdza, czy istnieje rekord A dla subdomeny używanej przez usługę yelb-ui.
3. Jeśli rekord A nie istnieje, skrypt go tworzy.

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

Uwaga

Przed wdrożeniem aplikacji Yelb i utworzeniem obiektu ingress, skrypt generuje SecretProviderClass, aby pobrać certyfikat TLS z Azure Key Vault i wygenerować sekret Kubernetes dla obiektu ingress. Warto zauważyć, że Secrets Store CSI Driver for Key Vault tworzy tajemnicę Kubernetes zawierającą certyfikat TLS tylko wtedy, gdy definicja SecretProviderClass i wolumin jest uwzględniona w deployment. Aby upewnić się, że certyfikat TLS jest prawidłowo pobierany z Azure Key Vault i przechowywany w sekrecie Kubernetes używanym przez obiekt ingress, musimy wprowadzić następujące zmiany w manifeście YAML wdrożenia yelb-ui:

Dodaj definicję csi volume korzystając z sterownika secrets-store.csi.k8s.io, który odnosi się do obiektu SecretProviderClass odpowiedzialnego za pobieranie certyfikatu TLS z Azure Key Vault.
Uwzględnij volume mount aby odczytać certyfikat jako tajemnicę z Azure Key Vault.

Aby uzyskać więcej informacji, zobacz Skonfiguruj Secrets Store CSI Driver, aby włączyć kontroler wejściowy NGINX z TLS.

Testowanie aplikacji

Użyj skryptu 05-call-yelb-ui.sh do wywołania usługi yelb-ui, zasymuluj SQL injection, ataki XSS i zobacz, jak zarządzany zestaw reguł ModSecurity blokuje złośliwe żądania.

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

Skrypt Bash powinien generować następujące wyniki, gdzie pierwsze wywołanie się powiedzie, natomiast reguły ModSecurity zablokują dwa kolejne wywołania.

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

Monitorowanie aplikacji

W proponowanym rozwiązaniu proces wdrażania automatycznie konfiguruje zasób Azure Application Gateway do zbierania dzienników diagnostycznych i metryk w przestrzeni roboczej Azure Log Analytics Workspace. Włączając dzienniki, możesz uzyskać cenne informacje na temat ocen, dopasowań i blokad przeprowadzanych przez zapory aplikacji internetowych Azure (WAF) w ramach Application Gateway. Aby uzyskać więcej informacji, zobacz Dzienniki diagnostyczne dla Application Gateway. Możesz także użyć Log Analytics do analizy danych w logach zapory sieciowej. Jeśli masz dzienniki zapory w obszarze roboczym usługi Log Analytics, możesz wyświetlać dane, zapisywać zapytania, tworzyć wizualizacje i dodawać je do pulpitu nawigacyjnego portalu. Aby uzyskać szczegółowe informacje na temat zapytań dziennika, zobacz Przegląd zapytań dziennika w Azure Monitor.

Eksploruj dane za pomocą zapytań Kusto

W proponowanym rozwiązaniu proces wdrażania automatycznie konfiguruje zasób Azure Application Gateway, aby zbierać dzienniki diagnostyczne i metryki do przestrzeni roboczej Azure Log Analytics. Włączając rejestrowanie, możesz uzyskać wgląd w oceny, dopasowania i blokady wykonywane przez Zaporę aplikacji internetowych Azure (WAF) w Bramce aplikacji. Aby uzyskać więcej informacji, zobacz Dzienniki diagnostyczne dla Application Gateway.

Możesz również używać Log Analytics, aby analizować dane zawarte w logach zapory. Jeśli masz dzienniki zapory w obszarze roboczym usługi Log Analytics, możesz wyświetlać dane, zapisywać zapytania, tworzyć wizualizacje i dodawać je do pulpitu nawigacyjnego portalu. Aby uzyskać więcej informacji na temat zapytań dzienników, zobacz Omówienie zapytań dzienników w Azure Monitor.

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

Alternatywnie, podczas pracy z tabelą Specyficzną dla zasobów, surowe dane z dziennika zapory sieciowej można uzyskać za pomocą następującego zapytania. Aby dowiedzieć się więcej o tabelach zależnych od zasobów, odniesienie znajduje się w dokumentacji Monitoring data reference.

AGWFirewallLogs
| limit 10

Gdy już masz dane, możesz zagłębić się głębiej i tworzyć wykresy lub wizualizacje. Oto kilka dodatkowych przykładów zapytań KQL, które można wykorzystać.

Dopasowane/zablokowane żądania według adresu IP

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

Dopasowane/zablokowane żądania według identyfikatora URI

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

Top matched rules

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

Top five matched rule groups

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

Przeglądanie wdrożonych zasobów

Możesz użyć Azure CLI lub Azure PowerShell, aby wyświetlić listę wdrożonych zasobów w grupie zasobów.

Azure CLI
Azure PowerShell

Wylistuj wdrożone zasoby w grupie zasobów za pomocą polecenia [az resource list][az-resource-list].

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

Wylistuj wdrożone zasoby w grupie zasobów za pomocą polecenia cmdlet [Get-AzResource][get-azresource].

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

Możesz użyć Azure CLI lub Azure PowerShell do usunięcia grupy zasobów, gdy nie potrzebujesz już zasobów, które utworzyłeś w tym samouczku.

Azure CLI
Azure PowerShell

Usuń grupę zasobów i powiązane z nią zasoby, używając polecenia az group delete.

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

Usuń grupę zasobów i powiązane z nią zasoby za pomocą polecenia cmdlet Remove-AzResourceGroup.

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

Następne kroki

Możesz zwiększyć bezpieczeństwo i ochronę przed zagrożeniami rozwiązania, korzystając z Azure DDoS Protection i Azure Firewall. Aby uzyskać więcej informacji, zobacz następujące artykuły:

Jeśli używasz kontrolera dostępu NGINX lub innego kontrolera dostępu hostowanego przez AKS zamiast Azure Application Gateway, możesz użyć Azure Firewall do monitorowania ruchu do i z klastra AKS oraz ochrony klastra przed wyciekiem danych i innym niepożądanym ruchem sieciowym. Aby uzyskać więcej informacji, zobacz następujące artykuły:

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy pierwotnie napisali to:

Główny autor:

Paolo Salvatori | Główny inżynier klienta

Inni współautorzy:

Ken Kilty | Główny Menedżer TPM
Russell de Pina | Principal TPM
Erin Schaffer | Content Developer 2

Sprzężenie zwrotne

Czy ta strona była pomocna?

Last updated on 2025-04-21