Bereitstellen einer Aws-Webanwendung (Amazon Web Services) in Azure

In diesem Artikel stellen Sie die Yelb-Anwendung im Azure Kubernetes Service (AKS) -Cluster bereit, den Sie im vorherigen Artikel erstellt haben.

Überprüfung der Umgebung

Stellen Sie vor der Bereitstellung der Anwendung sicher, dass Ihr AKS-Cluster mit den folgenden Befehlen ordnungsgemäß konfiguriert ist:

Listen Sie die Namespaces in Ihrem Cluster mit dem Befehl kubectl get namespace auf.

kubectl get namespace

Wenn Sie den NGINX-Eingangscontroller mithilfe des Anwendungsrouting-Add-Ons installiert haben, sollte der Namespace app-routing-system in der Ausgabe angezeigt werden:

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

Wenn Sie den NGINX Ingress-Controller über Helm installiert haben, sollte der Namespace ingress-basic in der Ausgabe angezeigt werden.

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

Rufen Sie die Dienstdetails des app-routing-system oder des ingress-basic-Namespaces mithilfe von kubectl get service command ab.

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

Wenn Sie das Anwendungsrouting-Add-On verwendet haben, sollten Sie sehen, dass der EXTERNAL-IP des nginx-Dienstes eine private IP-Adresse ist. Diese Adresse ist die private IP einer Frontend-IP-Konfiguration im kubernetes-internal privaten Load-Balancer Ihres AKS-Clusters.

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

Wenn Sie Helm verwendet haben, sollten Sie sehen, dass die EXTERNAL-IP des Dienstes nginx-ingress-ingress-nginx-controller eine private IP-Adresse ist. Diese Adresse ist die private IP einer Frontend-IP-Konfiguration im privaten kubernetes-internal Load Balancer Ihres AKS-Clusters.

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

Vorbereiten der Bereitstellung der Yelb-Anwendung

Wenn Sie das Beispiel mithilfe der TLS-Beendigung an Application Gateway und Yelb-Aufruf über den HTTP-Ansatz bereitstellen möchten, finden Sie die Bash-Skripte und YAML-Vorlagen zur Bereitstellung der Yelb-Anwendung im http Ordner.

Wenn Sie das Beispiel mithilfe der Implementierung von End-to-End-TLS mithilfe der Azure Application Gateway-Architektur bereitstellen möchten, finden Sie die Bash-Skripts und YAML-Vorlagen, um die Webanwendung im https Ordner bereitzustellen.

In den verbleibenden Abschnitten dieses Artikels führen wir Sie durch den Bereitstellungsprozess der Beispielanwendung mithilfe des End-to-End-TLS-Ansatzes.

Anpassen von Variablen

Bevor Sie Skripts ausführen, müssen Sie die Werte der Variablen in der 00-variables.sh Datei anpassen. Diese Datei ist in allen Skripts enthalten und enthält die folgenden Variablen:

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

Sie können den folgenden Befehl "az aks show" ausführen, um die clientId vom Azure Key Vault-Anbieter für secrets Store CSI-Treiber verwendete vom Benutzer zugewiesene verwaltete Identität abzurufen. Die Rolle Key Vault-Administrator des Moduls keyVault.bicep für die benutzerseitig zugewiesene verwaltete Identität des Add-Ons, damit sie das von Kubernetes Ingress verwendete Zertifikat abrufen kann, das zum Verfügbarmachen des Diensts yelb-ui über den NGINX-Eingangscontroller verwendet wird.
```
az aks show \
  --name <aks-name> \
  --resource-group <aks-resource-group-name> \
  --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
  --output tsv \
  --only-show-errors
```

Wenn Sie die Azure-Infrastruktur mit den in diesem Beispiel bereitgestellten Bicep-Modulen bereitgestellt haben, können Sie mit der Bereitstellung der Yelb-Anwendung fortfahren. Wenn Sie die Anwendung in Ihrem AKS-Cluster bereitstellen möchten, können Sie die folgenden Skripts verwenden, um Ihre Umgebung zu konfigurieren. Sie können 02-create-nginx-ingress-controller.sh verwenden, um den NGINX-Eingangscontroller mit der aktivierten Open-Source-Webanwendungsfirewall (WAF) ModSecurity zu installieren.

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

Bereitstellen der Anwendung

Führen Sie das folgende 03-deploy-yelb.sh Skript aus, um die Yelb-Anwendung und ein Kubernetes Ingress-Objekt bereitzustellen, um den yelb-ui Dienst für das öffentliche Internet zugänglich zu machen.

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

Aktualisieren Sie das yelb-ui YAML-Manifest, um die csi volume Definition einzuschließen und volume mount das Zertifikat als geheimer Schlüssel aus Azure Key Vault zu lesen.

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

Sie können die Anwendung jetzt bereitstellen. Das Skript verwendet das yelb.yml YAML-Manifest zum Bereitstellen der Anwendung und zum ingress.yml Erstellen des Eingangsobjekts. Wenn Sie eine öffentliche Azure DNS-Zone für die Auflösung von Domänennamen verwenden, können Sie das 04-configure-dns.sh Skript verwenden. Dieses Skript ordnet die öffentliche IP-Adresse des NGINX-Eingangscontrollers der Domäne zu, die vom Ingressobjekt verwendet wird, wodurch der yelb-ui Dienst verfügbar gemacht wird. Das Skript führt die folgenden Schritte aus:
1. Ruft die öffentliche Adresse der öffentlichen Azure-IP ab, die von der Front-End-IP-Konfiguration des Anwendungsgateways verwendet wird.
2. Überprüft, ob ein A Datensatz für die vom yelb-ui Dienst verwendete Unterdomäne vorhanden ist.
3. Wenn der A Datensatz nicht vorhanden ist, erstellt es das Skript.

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

Hinweis

Bevor Sie die Yelb-Anwendung bereitstellen und das ingress Objekt erstellen, generiert das Skript ein SecretProviderClass TLS-Zertifikat aus Azure Key Vault und generiert den Kubernetes-Geheimschlüssel für das ingress Objekt. Es ist wichtig zu beachten, dass der Secrets Store CSI-Treiber für Key Vault das Kubernetes-Geheimnis mit dem TLS-Zertifikat nur erstellt, wenn die SecretProviderClass und die Volumendefinition in der deployment enthalten sind. Um sicherzustellen, dass das TLS-Zertifikat ordnungsgemäß aus Azure Key Vault abgerufen und im Kubernetes-Geheimnis gespeichert ist, das ingress vom Objekt verwendet wird, müssen wir die folgenden Änderungen am YAML-Manifest der yelb-ui Bereitstellung vornehmen:

Fügen Sie mithilfe des secrets-store.csi.k8s.io-Treibers eine Definition hinzu, die auf das SecretProviderClass-Objekt verweist, das für das Abrufen des TLS-Zertifikats aus dem Azure Key Vault verantwortlich ist.
Fügen Sie volume mount hinzu, um das Zertifikat als ein Geheimnis aus Azure Key Vault zu lesen.

Weitere Informationen finden Sie unter Einrichten des CSI-Treibers für den Geheimen Speicher, um den NGINX-Eingangscontroller mit TLS zu aktivieren.

Testen der Anwendung

Verwenden Sie das 05-call-yelb-ui.sh Skript, um den yelb-ui Dienst aufzurufen, SQL-Einfügungen, XSS-Angriffe zu simulieren und zu beobachten, wie der verwaltete Regelsatz von ModSecurity bösartige Anforderungen blockiert.

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

Das Bash-Skript sollte die folgende Ausgabe erzeugen, bei der der erste Aufruf erfolgreich ist, während ModSecurity-Regeln die folgenden beiden Aufrufe blockieren:

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

Die Anwendung überwachen

In der vorgeschlagenen Lösung konfiguriert der Bereitstellungsprozess automatisch die Azure Application Gateway-Ressource , um Diagnoseprotokolle und Metriken in einem Azure Log Analytics Workspace-Arbeitsbereich zu sammeln. Durch die Aktivierung von Protokollen können Sie wertvolle Einblicke in die Auswertungen, Übereinstimmungen und Blöcke erhalten, die von der Azure Web Application Firewall (WAF) innerhalb des Anwendungsgateways ausgeführt werden. Weitere Informationen finden Sie in den Diagnoseprotokollen für das Anwendungsgateway. Sie können log Analytics auch verwenden, um die Daten in den Firewallprotokollen zu untersuchen. Wenn sich die Firewallprotokolle in Ihrem Log Analytics-Arbeitsbereich befinden, können Sie Daten anzeigen, Abfragen schreiben, Visualisierungen erstellen und sie zu Ihrem Portaldashboard hinzufügen. Ausführliche Informationen zu Protokollabfragen finden Sie unter Übersicht über Protokollabfragen in Azure Monitor.

Erkunden von Daten mit Kusto-Abfragen

Sie können log Analytics auch verwenden, um die Daten in den Firewallprotokollen zu untersuchen. Wenn sich die Firewallprotokolle in Ihrem Log Analytics-Arbeitsbereich befinden, können Sie Daten anzeigen, Abfragen schreiben, Visualisierungen erstellen und sie zu Ihrem Portaldashboard hinzufügen. Weitere Informationen zu Protokollabfragen finden Sie unter Übersicht über Protokollabfragen in Azure Monitor.

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

Alternativ können beim Arbeiten mit der ressourcenspezifischen Tabelle mithilfe der folgenden Abfrage auf die unformatierten Firewallprotokolldaten zugegriffen werden. Weitere Informationen zu ressourcenspezifischen Tabellen finden Sie in der Dokumentation zur Überwachungsdatenreferenz .

AGWFirewallLogs
| limit 10

Sobald Sie die Daten haben, können Sie tiefer gehen und Diagramme oder Visualisierungen erstellen. Im Folgenden finden Sie einige zusätzliche Beispiele für KQL-Abfragen , die verwendet werden können:

Von IP abgeglichene/blockierte Anforderungen

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

Von URI abgeglichene/blockierte Anforderungen

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

Ersten übereinstimmende Regeln

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

Die ersten fünf übereinstimmenden Regelgruppen

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

Überprüfen der bereitgestellten Ressourcen

Sie können Azure CLI oder Azure PowerShell verwenden, um die bereitgestellten Ressourcen in der Ressourcengruppe auflisten zu können.

Azure CLI
Azure PowerShell

Listen Sie die bereitgestellten Ressourcen in der Ressourcengruppe mit dem Befehl [az resource listaz-resource-list] auf.

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

Listen Sie die bereitgestellten Ressourcen in der Ressourcengruppe mithilfe des Cmdlets [Get-AzResource][get-azresource] auf.

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

Sie können Azure CLI oder Azure PowerShell verwenden, um die Ressourcengruppe zu löschen, wenn Sie die in diesem Lernprogramm erstellten Ressourcen nicht mehr benötigen.

Azure CLI
Azure PowerShell

Löschen Sie die Ressourcengruppe und die zugehörigen Ressourcen mithilfe des az group delete Befehls.

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

Löschen Sie die Ressourcengruppe und die zugehörigen Ressourcen mithilfe des Remove-AzResourceGroup Cmdlets.

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

Nächste Schritte

Sie können den Sicherheits- und Bedrohungsschutz der Lösung mithilfe von Azure DDoS Protection und azure Firewall erhöhen. Weitere Informationen finden Sie in den folgenden Artikeln:

Wenn Sie den NGINX-Eingangscontroller oder einen anderen gehosteten AKS-Eingangscontroller anstelle des Azure-Anwendungsgateways verwenden, können Sie die Azure-Firewall verwenden, um Datenverkehr zu und vom AKS-Cluster zu prüfen und den Cluster vor Datenexfiltration und anderen unerwünschten Netzwerkdatenverkehr zu schützen. Weitere Informationen finden Sie in den folgenden Artikeln:

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden sind die ursprünglichen Autoren::

Hauptautor:

Paolo Salvadori | Principal Customer Engineer

Andere Mitwirkende:

Ken Kilty | Principal TPM
Russell de Pina | Principal TPM
Erin Schaffer | Inhaltsentwickler 2

Feedback

War diese Seite hilfreich?

Last updated on 2025-04-30