Amazon Web Services (AWS) webalkalmazás üzembe helyezése Azure

Ebben a cikkben üzembe helyezi a Yelb alkalmazást az Azure Kubernetes Service (AKS) fürtön, amelyet az előző cikkben hozott létre.

A környezet ellenőrzése

Az alkalmazás üzembe helyezése előtt győződjön meg arról, hogy az AKS-fürt megfelelően van konfigurálva az alábbi parancsokkal:

  1. A kubectl get namespace parancs használatával listázhatja a fürt névtereit.

    kubectl get namespace
    

    Ha az NGINX bejövőforgalom-vezérlőt az alkalmazás-útválasztási bővítmény használatával telepítette, a kimenetben meg kell jelennie a app-routing-system névtérnek:

    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
    

    Ha az NGINX bejövőforgalom-vezérlőt a Helmen keresztül telepítette, a kimenetben a névtérnek kell megjelennie 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
    
  2. Szerezze meg a app-routing-system vagy a ingress-basic névtér szolgáltatási adatait a kubectl get service command segítségével.

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

    Ha az alkalmazás-útválasztási bővítményt használta, látnia kell, hogy a EXTERNAL-IPnginx szolgáltatás privát IP-cím. Ez a cím az AKS-fürt kubernetes-internal privát terheléselosztójában lévő frontend IP-konfiguráció privát IP-címe.

    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
    

    Ha a Helmt használta, látnia kell, hogy a EXTERNAL-IPnginx-ingress-ingress-nginx-controller szolgáltatás privát IP-cím. Ez a cím egy előtérbeli IP-konfiguráció privát IP-címe az kubernetes-internal AKS-fürt privát terheléselosztójában.

    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
    

Felkészülés a Yelb-alkalmazás üzembe helyezésére

Ha a TLS-leállítást az Application Gatewaynél használva és a Yelb alkalmazást HTTP-n keresztül meghívva szeretné üzembe helyezni a mintát, a Bash-szkripteket és a YAML-sablonokat a Yelb alkalmazáshttp mappában találja.

Ha az Azure Application Gateway végponttól végpontig tartó TLS megvalósítása architektúrával kívánja üzembe helyezni a mintaprojektet, megtalálhatja a Bash-szkripteket és YAML-sablonokat a webalkalmazás üzembe helyezéséhez a https mappában.

A cikk további szakaszaiban végigvezetjük a mintaalkalmazás üzembehelyezési folyamatán a végpontok közötti TLS-megközelítés használatával.

Változók testreszabása

  1. A szkriptek futtatása előtt testre kell szabnia a fájl változóinak értékeit 00-variables.sh . Ez a fájl az összes szkriptben megtalálható, és a következő változókat tartalmazza:

    # 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. A következő az aks show parancs futtatásával lekérheti a clientId az Azure Key Vault szolgáltató által használt Secrets Store CSI-illesztőprogramhoz. A keyVault.bicep modul a Key Vault Administrator szerepkört a bővítmény felhasználó által hozzárendelt felügyelt identitásához rendeli, hogy le tudja kérni a Kubernetes Ingress által a yelb-ui szolgáltatás NGINX ingress controlleren keresztüli elérhetővé tételéhez használt tanúsítványt.

    az aks show \
      --name <aks-name> \
      --resource-group <aks-resource-group-name> \
      --query addonProfiles.azureKeyvaultSecretsProvider.identity.clientId \
      --output tsv \
      --only-show-errors
    
  3. Ha az Azure infrastruktúrát a mintában megadott Bicep modulokkal telepítette, folytathatja a Yelb alkalmazás üzembe helyezését. Ha az alkalmazást az AKS-fürtben szeretné üzembe helyezni, az alábbi szkriptekkel konfigurálhatja a környezetet. Az 02-create-nginx-ingress-controller.sh a ModSecurity nyílt forráskódú webalkalmazási tűzfal (WAF) engedélyezésével telepítheti.

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

Az alkalmazás üzembe helyezése

  1. Futtassa a következő 03-deploy-yelb.sh szkriptet a Yelb-alkalmazás és egy Kubernetes Ingress objektum telepítéséhez, hogy a yelb-ui szolgáltatás elérhetővé váljon a nyilvános interneten keresztül.

    #!/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. Frissítse a yelb-ui YAML-jegyzékfájlt úgy, hogy tartalmazza a csi volume definíciót és volume mount a tanúsítványt a Azure Key Vault titkos kódjaként való olvasásához.

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. Most már üzembe helyezheti az alkalmazást. A szkript a yelb.yml YAML-jegyzék használatával telepíti az alkalmazást, és a ingress.yml objektumot hoz létre az ingresszióhoz. Ha Azure nyilvános DNS-zónát használ tartománynévfeloldáshoz, használhatja a 04-configure-dns.sh szkriptet. Ez a szkript az NGINX bejövőforgalom-vezérlő nyilvános IP-címét társítja a bejövő objektum által használt tartományhoz, amely elérhetővé teszi a yelb-ui szolgáltatást. A szkript a következő lépéseket hajtja végre:

    1. Lekéri az Application Gateway előtérbeli IP-konfigurációja által használt Azure nyilvános IP-cím nyilvános címét.
    2. Ellenőrzi, hogy létezik-e A rekord a szolgáltatás által használt altartományhoz yelb-ui .
    3. Ha a A rekord nem létezik, a szkript létrehozza.
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

Megjegyzés:

A Yelb-alkalmazás üzembe helyezése és a ingress objektum létrehozása előtt a szkript létrehoz egy SecretProviderClass parancsot, amely lekéri a TLS-tanúsítványt az Azure Key Vaultból, és létrehozza az ingress objektum Kubernetes-titkát. Fontos megjegyezni, hogy a Secrets Store CSI Driver for Key Vault csak akkor hozza létre a Kubernetes titkos kulcsot, amely a TLS-tanúsítványt tartalmazza, ha a SecretProviderClass és a kötetdefiníció szerepel a deployment. Annak érdekében, hogy a TLS-tanúsítvány megfelelően lekérhető legyen a Azure Key Vault és a ingress objektum által használt Kubernetes-titkos kódban legyen tárolva, az alábbi módosításokat kell hajtanunk végre a yelb-ui üzembe helyezés YAML-jegyzékében:

  • Adjon hozzá csi volume definíciót a secrets-store.csi.k8s.io illesztővel, amely a TLS-tanúsítvány Azure Key Vault való lekéréséért felelős SecretProviderClass objektumra hivatkozik.
  • Vegye fel a volume mount-t a tanúsítvány titkos kódként való beolvasásához az Azure Key Vault-ból.

További információért lásd: Secrets Store CSI Driver beállítása az NGINX ingresszvezérlő TLS-sel való engedélyezéséhez.

Az alkalmazás tesztelése

05-call-yelb-ui.sh A szkripttel meghívhatja a szolgáltatást, szimulálhatja az yelb-ui SQL-injektálást, az XSS-támadásokat, és megfigyelheti, hogy a ModSecurity felügyelt szabálykészlete hogyan blokkolja a rosszindulatú kéréseket.

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

A Bash-szkriptnek a következő kimenetet kell létrehoznia, ahol az első hívás sikeres, míg a ModSecurity-szabályok letiltják a következő két hívást:

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

Az alkalmazás figyelése

A javasolt megoldásban az üzembe helyezési folyamat automatikusan konfigurálja a Azure Application Gateway erőforrást, hogy diagnosztikai naplókat és metrikákat gyűjtsön egy Azure Log Analytics munkaterületre munkaterületre. A naplók engedélyezésével értékes betekintést kaphat az Application Gateway Azure Web Application Firewall (WAF) által végrehajtott értékelésekbe, találatokba és blokkokba. További információ: Diagnosztikai naplók az Application Gatewayhez. A tűzfalnaplókban lévő adatok vizsgálatához Log Analytics is használhatja. Ha a tűzfalnaplók a Log Analytics munkaterületen vannak, megtekintheti az adatokat, lekérdezéseket írhat, vizualizációkat hozhat létre, és hozzáadhatja őket a portál irányítópultjához. A napló lekérdezésekkel kapcsolatos részletes információkért lásd: Napló-lekérdezések megtekintése Azure Monitor.

Adatok felfedezése Kusto-lekérdezésekkel

A javasolt megoldásban az üzembe helyezési folyamat automatikusan konfigurálja a Azure Application Gateway erőforrást, hogy diagnosztikai naplókat és metrikákat gyűjtsön egy Azure Log Analytics munkaterületre. A naplók engedélyezésével betekintést nyerhet a Azure Web Application Firewall (WAF) által végrehajtott kiértékelésekbe, találatokba és blokkokba az Application Gatewayen belül. További információ: Diagnosztikai naplók az Application Gatewayhez.

A tűzfalnaplókban lévő adatok vizsgálatához Log Analytics is használhatja. Ha a tűzfalnaplók a Log Analytics munkaterületen vannak, megtekintheti az adatokat, lekérdezéseket írhat, vizualizációkat hozhat létre, és hozzáadhatja őket a portál irányítópultjához. A napló lekérdezésekkel kapcsolatos további információkért lásd: Napló-lekérdezések megtekintése Azure Monitor.

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

Másik lehetőségként az erőforrás-specifikus tábla használatakor a nyers tűzfalnapló-adatok az alábbi lekérdezéssel érhetők el. Az erőforrás-specifikus táblákkal kapcsolatos további információkért tekintse meg a monitorozási adatok referenciadokumentációját .

AGWFirewallLogs
| limit 10

Ha már rendelkezik az adatokkal, mélyebbre áshat, és grafikonokat vagy vizualizációkat hozhat létre. Íme néhány további példa a KQL-lekérdezésekre , amelyek felhasználhatók:

Egyeztetett/letiltott kérések IP-cím szerint

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

URI által egyeztetett/letiltott kérelmek

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

Legjobban illeszkedő szabályok

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

Az első öt egyező szabálycsoport

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

Üzembe helyezett erőforrások áttekintése

A Azure CLI vagy Azure PowerShell használatával listázhatja az erőforráscsoportban üzembe helyezett erőforrásokat.

Az [az resource list][az-resource-list] paranccsal listázhatja az erőforráscsoportban üzembe helyezett erőforrásokat.

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

Ha már nincs szüksége az oktatóanyagban létrehozott erőforrásokra, Azure CLI vagy Azure PowerShell törölheti az erőforráscsoportot.

Törölje az erőforráscsoportot és a hozzá tartozó erőforrásokat a az group delete parancs használatával.

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

Következő lépések

A megoldás biztonságát és fenyegetésvédelmet a Azure DDoS Protection és Azure Firewall használatával növelheti. További információkért lásd a következő cikkeket:

Ha az NGINX bejövőforgalom-vezérlőt vagy bármely más, a Azure Application Gateway helyett üzemeltetett AKS-vezérlőt használja, a Azure Firewall használatával megvizsgálhatja az AKS-fürtbe irányuló és onnan érkező forgalmat, és megvédheti a fürtöt az adatkiszivárgástól és más nem kívánt hálózati forgalomtól. További információkért lásd a következő cikkeket:

Közreműködők

Microsoft fenntartja ezt a cikket. A következő közreműködők eredetileg megírták:

Fő szerző:

Egyéb közreműködők: