Beschränken des Netzwerkdatenverkehrs mit Azure Firewall in Azure Kubernetes Service (AKS)

Artikel
12/05/2023

Erfahren Sie, wie Sie die Regeln für ausgehendes Netzwerk und FQDN für AKS-Cluster verwenden, um den Datenverkehr mithilfe der Azure Firewall in AKS zu steuern. Um diese Konfiguration zu vereinfachen, bietet Azure Firewall ein Azure Kubernetes Service (AzureKubernetesService) vollqualifiziertes Domänenname (FQDN)-Tag, das den vom AKS-Cluster ausgehenden Datenverkehr einschränkt. In diesem Artikel wird erläutert, wie Sie Ihre AKS Cluster-Datenverkehrsregeln über die Azure-Firewall konfigurieren können.

Hinweis

Das FQDN-Tag enthält alle FQDNs, die unter Regeln für ausgehendes Netzwerk und FQDN für AKS-Cluster aufgeführt sind und wird automatisch aktualisiert.

Für Produktionsszenarios empfehlen wird, dass Sie über mindestens 20 Front-End-IPs auf der Azure Firewall verfügen, um Probleme mit der SNAT-Portauslastung zu vermeiden.

Die folgenden Informationen zeigen ein Beispielarchitektur der Bereitstellung:

Gesperrte Topologie

Öffentlicher eingehender Datenverkehr wird gezwungen, Firewallfilter zu durchlaufen
- AKS-Agent-Knoten sind in einem dedizierten Subnetz isoliert
- Azure Firewall ist in seinem eigenen Subnetz bereitgestellt
- Eine DNAT-Regel übersetzt die öffentliche IP-Adresse der Firewall in die Front-End-IP des Lastenausgleichs
Ausgehende Anforderungen starten von Agent-Knoten über eine benutzerdefinierte Route (User-Defined Route, UDR) an die interne IP-Adresse der Azure Firewall
- Anforderungen von AKS-Agent-Knoten folgen einer UDR, die in dem Subnetz platziert wurde, in dem der AKS-Cluster bereitgestellt wurde
- Azure Firewall leitet ausgehenden Datenverkehr über ein Front-End mit öffentlicher IP-Adresse aus dem virtuellen Netzwerk.
- Der Zugriff auf das öffentliche Internet oder andere Azure-Dienste erfolgt sowohl für eingehenden als auch für ausgehenden Datenverkehr über die IP-Adresse des Firewall-Front-Ends.
- Der Zugriff auf die AKS-Steuerungsebene kann durch vom API-Server autorisierte IP-Adressbereiche geschützt werden, einschließlich die öffentliche Front-End-IP-Adresse für die Firewall
Interner Datenverkehr
- Sie können einen internen Lastenausgleichs für internen Datenverkehr verwenden, den Sie in einem eigenen Subnetz isolieren könnten, entweder anstelle oder gemeinsam mit einem öffentlichen Lastenausgleich

Konfigurieren von Umgebungsvariablen

Definieren Sie eine Reihe von Umgebungsvariablen, die bei der Erstellung von Ressourcen verwendet werden können.

PREFIX="aks-egress"
RG="${PREFIX}-rg"
LOC="eastus"
PLUGIN=azure
AKSNAME="${PREFIX}"
VNET_NAME="${PREFIX}-vnet"
AKSSUBNET_NAME="aks-subnet"
# DO NOT CHANGE FWSUBNET_NAME - This is currently a requirement for Azure Firewall.
FWSUBNET_NAME="AzureFirewallSubnet"
FWNAME="${PREFIX}-fw"
FWPUBLICIP_NAME="${PREFIX}-fwpublicip"
FWIPCONFIG_NAME="${PREFIX}-fwconfig"
FWROUTE_TABLE_NAME="${PREFIX}-fwrt"
FWROUTE_NAME="${PREFIX}-fwrn"
FWROUTE_NAME_INTERNET="${PREFIX}-fwinternet"

Erstellen eines virtuellen Netzwerks mit mehreren Subnetzen

Stellen Sie ein virtuelles Netzwerk mit zwei separaten Subnetzen bereit: eines für den Cluster und eines für die Firewall. Optional können Sie eines für internen eingehenden Dienstdatenverkehr erstellen.

Leere Netzwerktopologie

Erstellen Sie mit dem Befehl az group create eine Ressourcengruppe.
```
az group create --name $RG --location $LOC
```

Erstellen Sie ein virtuelles Netzwerk mit zwei Subnetzen zum Hosten des AKS-Clusters und der Azure Firewall mittels den Befehlen az network vnet create und az network vnet subnet create.

# Dedicated virtual network with AKS subnet
az network vnet create \
    --resource-group $RG \
    --name $VNET_NAME \
    --location $LOC \
    --address-prefixes 10.42.0.0/16 \
    --subnet-name $AKSSUBNET_NAME \
    --subnet-prefix 10.42.1.0/24

# Dedicated subnet for Azure Firewall (Firewall name can't be changed)
az network vnet subnet create \
    --resource-group $RG \
    --vnet-name $VNET_NAME \
    --name $FWSUBNET_NAME \
    --address-prefix 10.42.2.0/24

Erstellen und Einrichten einer Azure-Firewall

Sie müssen Eingangs- und Ausgangsregeln für Azure Firewall konfigurieren. Die Firewall dient hauptsächlich dazu, Organisationen das Konfigurieren von granularen Regeln für eingehenden und ausgehenden Datenverkehr in den und aus dem AKS-Cluster zu ermöglichen.

Wichtig

Wenn Ihr Cluster oder Ihre Anwendung eine große Anzahl von ausgehenden Verbindungen erstellt, die jeweils das gleiche Ziel oder eine kleine Teilmenge von Zielen haben, benötigen Sie allenfalls mehr Front-End-IP-Adressen für die Firewall, um zu vermeiden, dass die Ports pro Frontend-IP-Adresse ausgeschöpft werden.

Weitere Informationen zum Erstellen einer Azure Firewall mit mehreren IP-Adressen finden Sie unter Erstellen einer Azure Firewall mit mehreren öffentlichen IP-Adressen mittels Bicep.

Firewall und benutzerdefinierte Routen

Erstellen Sie mithilfe des az network public-ip create-Befehls eine öffentliche IP-Ressource der Standard-SKU. Diese Ressource wird als Front-End-Adresse für die Azure Firewall verwendet.
```
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
```
Registrieren Sie die Azure Firewall CLI-Erweiterung, um mithilfe des az extension add-Befehls eine Azure Firewall zu erstellen.
```
az extension add --name azure-firewall
```
Erstellen Sie eine Azure Firewall, und aktivieren Sie den DNS-Proxy mithilfe des az network firewall create-Befehls, und legen Sie --enable-dns-proxy auf true fest.
```
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
```

Das Einrichten der öffentlichen IP-Adresse für die Azure Firewall kann einige Minuten dauern. Sobald sie bereit ist, kann die zuvor erstellte IP-Adresse dem Firewall-Front-End zugewiesen werden.

Hinweis

Um FQDN für Netzwerkregeln nutzen zu können, müssen wir den DNS-Proxy aktivieren. Wenn der DNS-Proxy aktiviert ist, lauscht die Firewall an Port 53 und leitet DNS-Anforderungen an den oben angegebenen DNS-Server weiter. Dies ermöglicht der Firewall, den FQDN automatisch zu übersetzen.

Erstellen Sie mithilfe des az network firewall ip-config create-Befehls eine Azure Firewall IP-Konfiguration.

az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME

Sobald der oben stehende Befehl erfolgreich ist, speichern Sie die IP-Adresse des Firewall-Front-Ends zur späteren Konfiguration.

FWPUBLIC_IP=$(az network public-ip show -g $RG -n $FWPUBLICIP_NAME --query "ipAddress" -o tsv)
FWPRIVATE_IP=$(az network firewall show -g $RG -n $FWNAME --query "ipConfigurations[0].privateIPAddress" -o tsv)

Hinweis

Wenn Sie den sicheren Zugriff auf den AKS-API-Server mit autorisierten IP-Adressbereichen verwenden, müssen Sie die öffentliche IP-Adresse der Firewall zum autorisierten IP-Adressbereich hinzufügen.

Erstellen Sie eine Route mit einem Hop zur Azure Firewall

Azure führt für Datenverkehr automatisch das Routing zwischen Azure-Subnetzen, virtuellen Netzwerken und lokalen Netzwerken durch. Wenn Sie das Standardrouting von Azure ändern möchten, können Sie eine Routingtabelle erstellen.

Wichtig

Der ausgehende Typ „UDR“ (userDefinedRouting) erfordert eine Route für 0.0.0.0/0 und ein Ziel des nächsten Hops des virtuellen Netzwerkgeräts (Network Virtual Appliance, NVA) in der Routingtabelle. Die Routingtabelle weist bereits die Standardeinstellung 0.0.0.0/0 zum Internet auf. Ohne eine öffentliche IP-Adresse, die Azure für die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) verwenden kann, bietet das einfache Hinzufügen dieser Route keine ausgehende Internetverbindung. AKS überprüft, dass Sie keine 0.0.0.0/0-Route erstellen, die auf das Internet verweist, sondern stattdessen auf ein Gateway, ein NVA, etc. Bei Verwendung des Ausgangstyps „UDR“ wird eine öffentliche Lastenausgleichs-IP-Adresse für eingehende Anforderungen nur dann erstellt, wenn ein Dienst vom Typ loadbalancer konfiguriert wird. Eine öffentliche IP-Adresse für ausgehende Anforderungen wird von Azure Kubernetes Service (AKS) nie erstellt, wenn UDR als Ausgangstyp festgelegt ist. Weitere Informationen finden Sie unter Ausgangsregeln für Azure Load Balancer.

Erstellen Sie eine leere Routingtabelle mittels dem az network route-table create-Befehl, die einem bestimmten Subnetz zugeordnet werden soll. Die Routingtabelle definiert die oben erstellte Azure Firewall-Instanz als nächsten Hop. Jedem Subnetz können null oder mehr Routentabellen zugeordnet sein.
```
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
```

Erstellen Sie Routen in der Routingtabelle für die Subnetze mithilfe des az network route-table route create-Befehls.

az network route-table route create -g $RG --name $FWROUTE_NAME --route-table-name $FWROUTE_TABLE_NAME --address-prefix 0.0.0.0/0 --next-hop-type VirtualAppliance --next-hop-ip-address $FWPRIVATE_IP

az network route-table route create -g $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet

Informationen zum Überschreiben der Standardsystemrouten von Azure oder zum Hinzufügen zusätzlicher Routen zur Routingtabelle eines Subnetzes finden Sie in der Dokumentation zu Routingtabellen für virtuelle Netzwerke.

Hinzufügen von Firewallregeln

Hinweis

Für Anwendungen außerhalb der Namespaces „kube-system“ oder „gatekeeper-system“, die mit dem API-Server kommunizieren müssen, wird zusätzlich zum Hinzufügen einer Anwendungsregel für das FQDN-Tag AzureKubernetesService eine zusätzliche Netzwerkregel benötigt, um die TCP-Kommunikation mit Port 443 für die API-Server-IP zuzulassen.

In diesem Abschnitt werden drei Netzwerkregeln und eine Anwendungsregel behandelt, die Sie zum Konfigurieren ihrer Firewall verwenden können. Möglicherweise müssen Sie diese Regeln basierend auf Ihrer Bereitstellung anpassen.

Mit der ersten Netzwerkregel wird der Zugriff auf den Port 9000 über TCP zugelassen.
Mit der zweiten Netzwerkregel wird der Zugriff auf Port 1194 und 123 über UDP zugelassen. Wenn Sie in Microsoft Azure, betrieben von 21Vianet, bereitstellen, lesen Sie die erforderlichen Netzwerkregeln für Azure, betrieben von 21Vianet. Durch beide Regeln wird jeweils nur Datenverkehr zugelassen, der für das klassenlose domänenübergreifende Routing der Azure-Region in diesem Artikel bestimmt ist, d. h. „USA, Osten“
Die dritte Netzwerkregel öffnet Port 123 über UDP für FQDN ntp.ubuntu.com . Das Hinzufügen eines FQDN als Netzwerkregel ist eines der spezifischen Features von Azure Firewall, deshalb müssen Sie es anpassen, wenn Sie Ihre eigene Optionen verwenden.
Die vierten und fünften Netzwerkregeln ermöglichen den Zugriff auf Container aus GitHub-Containerregistrierung (ghcr.io) und Docker Hub (docker.io).

Erstellen Sie die Netzwerkregeln mithilfe des az network firewall network-rule create-Befehls.

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apiudp' --protocols 'UDP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 1194 --action allow --priority 100

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'apitcp' --protocols 'TCP' --source-addresses '*' --destination-addresses "AzureCloud.$LOC" --destination-ports 9000

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'time' --protocols 'UDP' --source-addresses '*' --destination-fqdns 'ntp.ubuntu.com' --destination-ports 123

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'ghcr' --protocols 'TCP' --source-addresses '*' --destination-fqdns ghcr.io pkg-containers.githubusercontent.com --destination-ports '443'

az network firewall network-rule create -g $RG -f $FWNAME --collection-name 'aksfwnr' -n 'docker' --protocols 'TCP' --source-addresses '*' --destination-fqdns docker.io registry-1.docker.io production.cloudflare.docker.com --destination-ports '443'

Erstellen Sie die Anwendungsregel mithilfe des az network firewall application-rule create-Befehls.

az network firewall application-rule create -g $RG -f $FWNAME --collection-name 'aksfwar' -n 'fqdn' --source-addresses '*' --protocols 'http=80' 'https=443' --fqdn-tags "AzureKubernetesService" --action allow --priority 100

Weitere Informationen zur Azure Firewall finden Sie in der Azure Firewall-Dokumentation.

Zuordnen der Routingtabelle zu AKS

Um den Cluster der Firewall zuzuordnen, muss das dedizierte Subnetz für das Subnetz des Clusters auf die oben erstellte Routingtabelle verweisen. Verwenden Sie den az network vnet subnet update-Befehl, um die Routingtabelle mit AKS zu verknüpfen.

az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME

Bereitstellen eines AKS-Clusters, der Ihren ausgehenden Regeln folgt

Jetzt können Sie einen AKS-Cluster im vorhandenen virtuellen Netzwerk bereitstellen. Sie verwenden den ausgehenden userDefinedRouting-Typ, der sicherstellt, dass sämtlicher ausgehender Datenverkehr durch die Firewall erzwungen wird und keine anderen ausgehenden Pfade vorhanden sind. Der ausgehende loadBalancer-Typ kann auch verwendet werden.

aks-deploy

Das Zielsubnetz, in dem die Bereitstellung erfolgen soll, wird mit der Umgebungsvariable $SUBNETID definiert. Legen Sie den Wert für die Subnetz-ID mit dem folgenden Befehl fest:

SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)

Sie definieren den ausgehenden Typ für die Verwendung der benutzerdefinierten Route, die bereits im Subnetz vorhanden ist. Diese Konfiguration ermöglicht es AKS, die Einrichtung und die IP-Adressbereitstellung für den Lastenausgleich zu überspringen.

Tipp

Sie können der Clusterbereitstellung weitere Features hinzufügen, beispielsweise private Cluster.

Sie können das AKS-Feature für vom API-Server autorisierte IP-Adressbereiche hinzufügen, um den Zugriff des API-Servers auf den öffentlichen Endpunkt der Firewall zu beschränken. Das Feature für autorisierte IP-Adressbereiche ist im Diagramm als optional gekennzeichnet. Wenn Sie das Feature für autorisierte IP-Adressbereiche verwenden, um den API-Serverzugriff einzuschränken, müssen Ihre Entwicklertools eine Jumpbox aus dem virtuelle Netzwerk der Firewall verwenden, oder Sie müssen alle Entwicklerendpunkte zum autorisierten IP-Adressbereich hinzufügen.

Erstellen eines AKS-Clusters mit systemseitig zugewiesenen Identitäten
Erstellen eines AKS-Clusters mit benutzerseitig zugewiesenen Identitäten

Hinweis

AKS wird eine systemseitig zugewiesene Kubelet-Identität in der Knotenressourcengruppe erstellen, wenn Sie Ihre eigene verwaltete Kubelet-Identität nicht angeben.

Für das benutzerdefinierte Routing unterstützt die systemseitig zugewiesene Identität nur das CNI-Netzwerk-Plug-In.

Erstellen Sie einen AKS-Cluster mithilfe einer systemseitig zugewiesenen verwalteten Identität mit dem CNI-Netzwerk-Plug-In mittels dem az aks create-Befehl.

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 \
  --network-plugin azure \
  --outbound-type userDefinedRouting \
  --vnet-subnet-id $SUBNETID \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP

Erstellen benutzerseitig zugewiesener Identitäten

Wenn Sie nicht über benutzerseitig zugewiesene Identitäten verfügen, folgen Sie den Schritten in diesem Abschnitt. Wenn Sie bereits über benutzerseitig zugewiesene Identitäten verfügen, fahren Sie mit Erstellen eines AKS-Clusters mit benutzerseitig zugewiesenen Identitäten fort.

Erstellen Sie mithilfe des az identity create-Befehls eine verwaltete Identität.

az identity create --name myIdentity --resource-group $RG

Die Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

 {
   "clientId": "<client-id>",
   "clientSecretUrl": "<clientSecretUrl>",
   "id": "/subscriptions/<subscriptionid>/resourcegroups/aks-egress-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myIdentity",
   "location": "eastus",
   "name": "myIdentity",
   "principalId": "<principal-id>",
   "resourceGroup": "aks-egress-rg",
   "tags": {},
   "tenantId": "<tenant-id>",
   "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
 }

Erstellen Sie mithilfe des az identity create-Befehls eine verwaltete Kubelet-Identität.

az identity create --name myKubeletIdentity --resource-group $RG

Die Ausgabe sollte in etwa wie die folgende Beispielausgabe aussehen:

{
  "clientId": "<client-id>",
  "clientSecretUrl": "<clientSecretUrl>",
  "id": "/subscriptions/<subscriptionid>/resourcegroups/aks-egress-rg/providers/Microsoft.ManagedIdentity/userAssignedIdentities/myKubeletIdentity",
  "location": "westus2",
  "name": "myKubeletIdentity",
  "principalId": "<principal-id>",
  "resourceGroup": "aks-egress-rg",
  "tags": {},
  "tenantId": "<tenant-id>",
  "type": "Microsoft.ManagedIdentity/userAssignedIdentities"
}

Hinweis

Wenn Sie Ihr eigenes VNet und Ihre eigene Routingtabelle erstellen, bei dem/der sich die Ressourcen außerhalb der Ressourcengruppe des Workerknotens befinden, fügt die CLI die Rollenzuweisung automatisch hinzu. Wenn Sie eine ARM-Vorlage oder eine andere Methode verwenden, müssen Sie die Prinzipal-ID der vom Cluster verwalteten Identität verwenden, um eine Rollenzuweisung durchzuführen.

Erstellen eines AKS-Clusters mit Ihren vorhandenen Identitäten

Erstellen Sie mithilfe des Befehls az aks create einen AKS-Cluster mit Ihren vorhandenen Identitäten im Subnetz, und geben Sie die Ressourcen-ID der verwalteten Identität für die Steuerungsebene an, indem Sie das Argument assign-kubelet-identity einschließen.

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 \
  --network-plugin kubenet \
  --outbound-type userDefinedRouting \
  --vnet-subnet-id $SUBNETID \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP
  --enable-managed-identity \
  --assign-identity <identity-resource-id> \
  --assign-kubelet-identity <kubelet-identity-resource-id>

Ermöglichen des Entwicklerzugriffs auf den API-Server

Wenn Sie im vorherigen Schritt autorisierte IP-Adressbereiche für Ihren Cluster verwendet haben, müssen Sie die IP-Adressen Ihrer Entwicklertools der AKS-Clusterliste mit den genehmigten IP-Adressbereichen hinzufügen, d. h. Sie greifen von dort aus auf den API-Server zu. Sie können auch eine Jumpbox mit den benötigten Tools in einem separaten Subnetz im virtuellen Netzwerk der Firewall konfigurieren.

Rufen Sie Ihre IP-Adresse mit dem folgenden Befehl ab:

CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)

Fügen Sie Ihre IP-Adresse den bewilligten Bereichen mittels demaz aks update-Befehl hinzu.
```
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
```
Konfigurieren Sie kubectl, um mithilfe des Befehls az aks get-credentials eine Verbindung mit Ihrem AKS-Cluster herzustellen.
```
az aks get-credentials -g $RG -n $AKSNAME
```

Einen öffentlichen Dienst auf AKS einrichten

Nun können Sie damit beginnen, Dienste verfügbar zu machen und Anwendungen in diesem Cluster bereitzustellen. In diesem Beispiel werden wir einen öffentlicher Dienst verfügbar machen, aber möglicherweise wollen Sie auch einen internen Dienst über den internen Lastenausgleich verfügbar machen.

DNAT für öffentlichen Dienst

Überprüfen Sie das AKS Store Demo-Schnellstart-Manifest, um alle Ressourcen anzuzeigen, die erstellt werden sollen.

Stellen Sie den Dienst mit dem kubectl apply-Befehl bereit.

kubectl apply -f https://raw.githubusercontent.com/Azure-Samples/aks-store-demo/main/aks-store-quickstart.yaml

Eingehenden Datenverkehr über die Azure Firewall zulassen

Wichtig

Wenn Sie Azure Firewall verwenden, um ausgehenden Datenverkehr einzuschränken, und eine UDR erstellen, um den ausgehenden Datenverkehr zu erzwingen, stellen Sie sicher, dass Sie in Azure Firewall eine entsprechende DNAT-Regel erstellen, um eingehenden Datenverkehr korrekt zuzulassen. Durch die Verwendung von Azure Firewall mit einer UDR wird das Setup für eingehenden Datenverkehr aufgrund von asymmetrischem Routing unterbrochen. Das Problem tritt auf, wenn das AKS-Subnetz über eine Standardroute verfügt, die zur privaten IP-Adresse der Firewall führt, Sie aber einen öffentlichen Lastenausgleich verwenden – eingehend oder Kubernetes-Dienst vom Typ loadBalancer. In diesem Fall wird der eingehende Load Balancer-Datenverkehr über die öffentliche IP-Adresse empfangen, während der Rückpfad über die private IP-Adresse der Firewall verläuft. Die Firewall löscht das zurückgegebene Paket, weil sie zustandsbehaftet ist und nichts über eine vorhandene Sitzung weiß. Informationen zur Integration von Azure Firewall in ihren Eingangs- oder Service Dienst-Load Balancer finden Sie unter Integrieren von Azure Firewall mit Azure Load Balancer Standard.

Um die eingehende Konnektivität korrekt zu konfigurieren, müssen Sie eine DNAT-Regel zur Azure Firewall schreiben. Zum Testen der Konnektivität mit dem Cluster wird eine Regel definiert, durch die die öffentliche IP-Adresse des Firewall-Front-Ends an die interne IP-Adresse weitergeleitet wird, die durch den internen Dienst verfügbar gemacht wird. Die Zieladresse kann angepasst werden. Die übersetzte Adresse muss die IP-Adresse des internen Lastenausgleichs sein. Der übersetzte Port muss der verfügbar gemachte Port für Ihren Kubernetes-Dienst sein. Sie müssen auch die interne IP-Adresse angeben, die der vom Kubernetes-Dienst erstellten Lastenausgleichsressource zugewiesen ist.

Rufen Sie mithilfe des kubectl get services-Befehls die interne IP-Adresse ab, die dem Lastenausgleich zugewiesen ist.

kubectl get services

Die IP-Adresse wird in der Spalte EXTERNAL-IP aufgeführt, wie in der folgenden Beispielausgabe gezeigt:

NAME              TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)              AGE
kubernetes        ClusterIP      10.0.0.1       <none>        443/TCP              9m10s
order-service     ClusterIP      10.0.104.144   <none>        3000/TCP             11s
product-service   ClusterIP      10.0.237.60    <none>        3002/TCP             10s
rabbitmq          ClusterIP      10.0.161.128   <none>        5672/TCP,15672/TCP   11s
store-front       LoadBalancer   10.0.89.139    20.39.18.6    80:32271/TCP         10s

Rufen Sie die Dienst-IP-Adresse mithilfe des kubectl get svc voting-app-Befehls ab.

SERVICE_IP=$(kubectl get svc store-front -o jsonpath='{.status.loadBalancer.ingress[*].ip}')

Fügen Sie die NAT-Regel mithilfe des az network firewall nat-rule create-Befehls hinzu.

az network firewall nat-rule create --collection-name exampleset --destination-addresses $FWPUBLIC_IP --destination-ports 80 --firewall-name $FWNAME --name inboundrule --protocols Any --resource-group $RG --source-addresses '*' --translated-port 80 --action Dnat --priority 100 --translated-address $SERVICE_IP

Überprüfen der Konnektivität

Navigieren Sie in einem Browser zur IP-Adresse des Azure Firewall-Front-Ends, um die Konnektivität zu überprüfen.

Die AKS Store-App sollte angezeigt werden. In diesem Beispiel lautete die öffentliche IP-Adresse der Firewall 52.253.228.132.

Auf dieser Seite können Sie Produkte anzeigen und ihrem Warenkorb hinzufügen und dann eine Bestellung aufgeben.

Bereinigen von Ressourcen

Um die Azure-Ressourcen zu bereinigen, löschen Sie die AKS-Ressourcengruppe mittels dem Befehl az group delete.

az group delete -g $RG

Nächste Schritte

In diesem Artikel haben Sie erfahren, wie Sie Ihren ausgehenden Datenverkehr mithilfe von Azure Firewall sichern. Sie können die obigen Schritte bei Bedarf generalisieren, um den Datenverkehr an Ihre bevorzugte Lösung für ausgehenden Datenverkehr weiterzuleiten, wie in der Dokumentation für den ausgehenden Typ userDefinedRoute beschrieben.

Beschränken des Netzwerkdatenverkehrs mit Azure Firewall in Azure Kubernetes Service (AKS)

Konfigurieren von Umgebungsvariablen

Erstellen eines virtuellen Netzwerks mit mehreren Subnetzen

Erstellen und Einrichten einer Azure-Firewall

Erstellen Sie eine Route mit einem Hop zur Azure Firewall

Hinzufügen von Firewallregeln

Zuordnen der Routingtabelle zu AKS

Bereitstellen eines AKS-Clusters, der Ihren ausgehenden Regeln folgt

Ermöglichen des Entwicklerzugriffs auf den API-Server

Einen öffentlichen Dienst auf AKS einrichten

Eingehenden Datenverkehr über die Azure Firewall zulassen

Überprüfen der Konnektivität

Bereinigen von Ressourcen

Nächste Schritte

Zusätzliche Ressourcen