Ograniczanie ruchu sieciowego za pomocą usługi Azure Firewall w usłudze Azure Kubernetes Service (AKS)

Artykuł
08/02/2024

Dowiedz się, jak używać reguł sieci wychodzącej i nazw FQDN dla klastrów usługi AKS do kontrolowania ruchu wychodzącego przy użyciu usługi Azure Firewall w usłudze AKS. Aby uprościć tę konfigurację, usługa Azure Firewall udostępnia tag usługi Azure Kubernetes Service () w pełni kwalifikowanej nazwy domeny (AzureKubernetesServiceFQDN), który ogranicza ruch wychodzący z klastra usługi AKS. W tym artykule pokazano, jak skonfigurować reguły ruchu klastra usługi AKS za pośrednictwem zapory platformy Azure.

Uwaga

Tag FQDN zawiera wszystkie nazwy FQDN wymienione w regułach sieci wychodzącej i nazwy FQDN dla klastrów usługi AKS i są automatycznie aktualizowane.

W przypadku scenariuszy produkcyjnych zalecamy posiadanie co najmniej 20 adresów IP frontonu w usłudze Azure Firewall, aby uniknąć problemów z wyczerpaniem portów SNAT.

Poniższe informacje zawierają przykładową architekturę wdrożenia:

Topologia zablokowana

Publiczny ruch przychodzący jest zmuszony do przepływu przez filtry zapory
- Węzły agenta usługi AKS są izolowane w dedykowanej podsieci
- Usługa Azure Firewall jest wdrażana we własnej podsieci
- Reguła DNAT tłumaczy publiczny adres IP zapory na adres IP frontonu modułu równoważenia obciążenia
Żądania wychodzące rozpoczynają się od węzłów agenta do wewnętrznego adresu IP usługi Azure Firewall przy użyciu trasy zdefiniowanej przez użytkownika (UDR)
- Żądania z węzłów agenta usługi AKS są zgodne z trasę zdefiniowaną przez użytkownika, która została umieszczona w podsieci, w której wdrożono klaster usługi AKS
- Usługa Azure Firewall wychodząca z sieci wirtualnej z frontonu publicznego adresu IP
- Dostęp do publicznego Internetu lub innych usług platformy Azure przepływa do i z adresu IP frontonu zapory
- Dostęp do płaszczyzny sterowania usługi AKS może być chroniony przez autoryzowane zakresy adresów IP serwera interfejsu API, w tym publiczny adres IP frontonu zapory
Ruch wewnętrzny
- Możesz użyć wewnętrznego modułu równoważenia obciążenia dla ruchu wewnętrznego, który można odizolować we własnej podsieci, zamiast lub obok publicznego modułu równoważenia obciążenia

Skonfiguruj zmienne środowiskowe

Zdefiniuj zestaw zmiennych środowiskowych, które mają być używane w tworzeniu zasobów.

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"

Tworzenie sieci wirtualnej z wieloma podsieciami

Aprowizuj sieć wirtualną z dwiema oddzielnymi podsieciami: jedną dla klastra i jedną dla zapory. Opcjonalnie możesz utworzyć jeden dla ruchu przychodzącego usługi wewnętrznej.

Pusta topologia sieci

Utwórz grupę zasobów przy użyciu az group create polecenia .
```
az group create --name $RG --location $LOC
```

Utwórz sieć wirtualną z dwiema podsieciami do hostowania klastra usługi AKS i usługi Azure Firewall przy użyciu az network vnet create poleceń i 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

Tworzenie i konfigurowanie usługi Azure Firewall

Należy skonfigurować reguły ruchu przychodzącego i wychodzącego usługi Azure Firewall. Głównym celem zapory jest umożliwienie organizacjom konfigurowania szczegółowych reguł ruchu przychodzącego i wychodzącego do i z klastra usługi AKS.

Ważne

Jeśli klaster lub aplikacja tworzy dużą liczbę połączeń wychodzących kierowanych do tego samego lub małego podzestawu miejsc docelowych, może być konieczne wymaganie większej liczby adresów IP frontonu zapory, aby uniknąć maksymalnego limitu portów na adres IP frontonu.

Aby uzyskać więcej informacji na temat tworzenia usługi Azure Firewall z wieloma adresami IP, zobacz Tworzenie usługi Azure Firewall z wieloma publicznymi adresami IP przy użyciu Bicep.

Zapora i trasa zdefiniowana przez użytkownika

Utwórz standardowy zasób publicznego adresu IP jednostki SKU przy użyciu az network public-ip create polecenia . Ten zasób będzie używany jako adres frontonu usługi Azure Firewall.
```
az network public-ip create --resource-group $RG -n $FWPUBLICIP_NAME --location $LOC --sku "Standard"
```
Zarejestruj rozszerzenie interfejsu wiersza polecenia usługi Azure Firewall, aby utworzyć usługę Azure Firewall przy użyciu az extension add polecenia .
```
az extension add --name azure-firewall
```
Utwórz usługę Azure Firewall i włącz serwer proxy DNS przy użyciu az network firewall create polecenia i ustawić wartość --enable-dns-proxy na true.
```
az network firewall create --resource-group $RG --name $FWNAME --location $LOC --enable-dns-proxy true
```

Skonfigurowanie publicznego adresu IP w usłudze Azure Firewall może potrwać kilka minut. Gdy wszystko będzie gotowe, adres IP utworzony wcześniej można przypisać do frontonu zapory.

Uwaga

Aby korzystać z nazwy FQDN w regułach sieci, potrzebujemy włączonego serwera proxy DNS. Po włączeniu serwera proxy DNS zapora nasłuchuje na porcie 53 i przekazuje żądania DNS do serwera DNS określonego powyżej. Dzięki temu zapora może automatycznie przetłumaczyć nazwę FQDN.

Utwórz konfigurację adresu IP usługi Azure Firewall przy użyciu az network firewall ip-config create polecenia .

az network firewall ip-config create --resource-group $RG --firewall-name $FWNAME --name $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME

Po pomyślnym zakończeniu poprzedniego polecenia zapisz adres IP frontonu zapory na potrzeby konfiguracji później.

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

Uwaga

Jeśli używasz bezpiecznego dostępu do serwera interfejsu API usługi AKS z autoryzowanymi zakresami adresów IP, musisz dodać publiczny adres IP zapory do autoryzowanego zakresu adresów IP.

Tworzenie trasy z przeskokiem do usługi Azure Firewall

Platforma Azure automatycznie kieruje ruchem między podsieciami platformy Azure, sieciami wirtualnymi i sieciami lokalnymi. Jeśli chcesz zmienić domyślny routing platformy Azure, możesz utworzyć tabelę tras.

Ważne

Typ ruchu wychodzącego trasy zdefiniowanej przez użytkownika (userDefinedRouting) wymaga trasy dla 0.0.0.0/0 i miejsca docelowego następnego przeskoku urządzenia WUS w tabeli tras. Tabela tras ma już domyślną 0.0.0.0/0 do Internetu. Bez publicznego adresu IP dla platformy Azure do użycia na potrzeby tłumaczenia adresów sieciowych źródła (SNAT), po prostu dodanie tej trasy nie zapewni wychodzącej łączności z Internetem. Usługa AKS sprawdza, czy nie utworzysz trasy 0.0.0.0/0 wskazującej Internet, ale zamiast bramy, urządzenia WUS itp. W przypadku korzystania z typu ruchu wychodzącego trasy zdefiniowanej przez użytkownika publiczny adres IP modułu równoważenia obciążenia dla żądań przychodzących nie jest tworzony, chyba że skonfigurowano usługę typu loadbalancer. Usługa AKS nigdy nie tworzy publicznego adresu IP dla żądań wychodzących, jeśli ustawisz typ ruchu wychodzącego trasy zdefiniowanej przez użytkownika. Aby uzyskać więcej informacji, zobacz Reguły ruchu wychodzącego dla usługi Azure Load Balancer.

Utwórz pustą tabelę tras, która ma być skojarzona z daną podsiecią az network route-table create przy użyciu polecenia . Tabela tras zdefiniuje następny przeskok jako utworzoną powyżej usługę Azure Firewall. Każda podsieć może mieć skojarzoną ze sobą żadną lub jedną tabelę tras.
```
az network route-table create --resource-group $RG --location $LOC --name $FWROUTE_TABLE_NAME
```

Utwórz trasy w tabeli tras dla podsieci przy użyciu az network route-table route create polecenia .

az network route-table route create --resource-group $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 --resource-group $RG --name $FWROUTE_NAME_INTERNET --route-table-name $FWROUTE_TABLE_NAME --address-prefix $FWPUBLIC_IP/32 --next-hop-type Internet

Aby uzyskać informacje na temat zastępowania domyślnych tras systemowych platformy Azure lub dodawania dodatkowych tras do tabeli tras podsieci, zobacz dokumentację tabeli tras sieci wirtualnej.

Dodawanie reguł zapory

Uwaga

W przypadku aplikacji spoza przestrzeni nazw kube-system lub gatekeeper-system, które muszą komunikować się z serwerem interfejsu API, wymagana jest dodatkowa reguła sieci umożliwiająca komunikację TCP z portem 443 dla adresu IP serwera interfejsu API oprócz dodawania reguły aplikacji dla tagu fqdn-tag AzureKubernetesService .

W tej sekcji opisano trzy reguły sieciowe i regułę aplikacji, której można użyć do skonfigurowania zapory. Może być konieczne dostosowanie tych reguł na podstawie wdrożenia.

Pierwsza reguła sieci umożliwia dostęp do portu 9000 za pośrednictwem protokołu TCP.
Druga reguła sieci umożliwia dostęp do portu 1194 i 123 za pośrednictwem protokołu UDP. Jeśli wdrażasz na platformie Microsoft Azure obsługiwanej przez firmę 21Vianet, zapoznaj się z regułami sieci wymaganymi przez platformę Azure obsługiwaną przez firmę 21Vianet. Obie te reguły zezwalają tylko na ruch kierowany do trasy CIDR regionu świadczenia usługi Azure w tym artykule, czyli Wschodnie stany USA.
Trzecia reguła sieci otwiera port 123 do ntp.ubuntu.com nazwy FQDN za pośrednictwem protokołu UDP. Dodanie nazwy FQDN jako reguły sieciowej jest jedną z określonych funkcji usługi Azure Firewall, dlatego należy dostosować ją podczas korzystania z własnych opcji.
Czwarte i piąte reguły sieci umożliwiają dostęp do ściągania kontenerów z usługi GitHub Container Registry (ghcr.io) i usługi Docker Hub (docker.io).

Utwórz reguły sieci przy az network firewall network-rule create użyciu polecenia .

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

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

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

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

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

Utwórz regułę aplikacji przy użyciu az network firewall application-rule create polecenia .

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

Aby dowiedzieć się więcej o usłudze Azure Firewall, zobacz dokumentację usługi Azure Firewall.

Kojarzenie tabeli tras z usługą AKS

Aby skojarzyć klaster z zaporą, dedykowana podsieć dla podsieci klastra musi odwoływać się do tabeli tras utworzonej powyżej. az network vnet subnet update Użyj polecenia , aby skojarzyć tabelę tras z usługą AKS.

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

Wdrażanie klastra usługi AKS zgodnego z regułami ruchu wychodzącego

Teraz możesz wdrożyć klaster usługi AKS w istniejącej sieci wirtualnej. Użyjesz typu ruchu wychodzącegouserDefinedRouting, co gwarantuje, że cały ruch wychodzący zostanie wymuszony przez zaporę, a żadne inne ścieżki ruchu wychodzącego nie będą istnieć. loadBalancer Można również użyć typu ruchu wychodzącego.

aks-deploy

Podsieć docelowa do wdrożenia jest definiowana za pomocą zmiennej środowiskowej $SUBNETID. Ustaw wartość identyfikatora podsieci przy użyciu następującego polecenia:

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

Zdefiniujesz typ ruchu wychodzącego, aby użyć trasy zdefiniowanej przez użytkownika, która już istnieje w podsieci. Ta konfiguracja umożliwi usłudze AKS pominięcie konfiguracji i aprowizacji adresów IP dla modułu równoważenia obciążenia.

Napiwek

Do wdrożenia klastra można dodać dodatkowe funkcje, takie jak klastry prywatne.

Możesz dodać funkcję AKS dla autoryzowanych zakresów adresów IP serwera interfejsu API, aby ograniczyć dostęp serwera interfejsu API tylko do publicznego punktu końcowego zapory. Funkcja autoryzowanych zakresów adresów IP jest oznaczona na diagramie jako opcjonalna. Po włączeniu autoryzowanej funkcji zakresu adresów IP w celu ograniczenia dostępu do serwera interfejsu API narzędzia deweloperskie muszą używać serwera przesiadkowego z sieci wirtualnej zapory lub należy dodać wszystkie punkty końcowe dewelopera do autoryzowanego zakresu adresów IP.

Tworzenie klastra usługi AKS z tożsamościami przypisanymi przez system
Tworzenie klastra usługi AKS z tożsamościami przypisanymi przez użytkownika

Uwaga

Usługa AKS utworzy tożsamość kubelet przypisaną przez system w grupie zasobów węzła, jeśli nie określisz własnej tożsamości zarządzanej kubelet.

W przypadku routingu zdefiniowanego przez użytkownika tożsamość przypisana przez system obsługuje tylko wtyczkę sieci CNI.

Utwórz klaster usługi AKS przy użyciu tożsamości zarządzanej przypisanej przez system z wtyczką sieciową az aks create CNI przy użyciu polecenia .

az aks create --resource-group $RG --name $AKSNAME --location $LOC \
    --node-count 3 \
    --network-plugin azure \
    --outbound-type userDefinedRouting \
    --vnet-subnet-id $SUBNETID \
    --api-server-authorized-ip-ranges $FWPUBLIC_IP \
    --generate-ssh-keys

Tworzenie tożsamości przypisanych przez użytkownika

Jeśli nie masz tożsamości przypisanych przez użytkownika, wykonaj kroki opisane w tej sekcji. Jeśli masz już tożsamości przypisane przez użytkownika, przejdź do sekcji Tworzenie klastra usługi AKS z tożsamościami przypisanymi przez użytkownika.

Utwórz tożsamość zarządzaną przy użyciu az identity create polecenia .

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

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

 {
   "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"
 }

Utwórz tożsamość zarządzaną kubelet przy az identity create użyciu polecenia .

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

Dane wyjściowe powinny przypominać następujące przykładowe dane wyjściowe:

{
  "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"
}

Uwaga

Jeśli tworzysz własną sieć wirtualną i tabelę tras, w której zasoby znajdują się poza grupą zasobów węzła procesu roboczego, interfejs wiersza polecenia automatycznie doda przypisanie roli. Jeśli używasz szablonu usługi ARM lub innej metody, musisz użyć identyfikatora głównego tożsamości zarządzanej klastra do wykonania przypisania roli.

Tworzenie klastra usługi AKS przy użyciu istniejących tożsamości

Utwórz klaster usługi AKS z istniejącymi tożsamościami zarządzanymi przypisanymi przez użytkownika w podsieci przy użyciu az aks create polecenia . Podaj identyfikator zasobu tożsamości zarządzanej dla płaszczyzny sterowania i identyfikator zasobu tożsamości kubelet.

az aks create \
    --resource-group $RG \
    --name $AKSNAME \
    --location $LOC \
    --node-count 3 \
    --network-plugin kubenet \
    --outbound-type userDefinedRouting \
    --vnet-subnet-id $SUBNETID \
    --api-server-authorized-ip-ranges $FWPUBLIC_IP
    --assign-identity <identity-resource-id> \
    --assign-kubelet-identity <kubelet-identity-resource-id> \
    --generate-ssh-keys

Włączanie dostępu dewelopera do serwera interfejsu API

Jeśli w poprzednim kroku użyto autoryzowanych zakresów adresów IP dla klastra, należy dodać adresy IP narzędzi deweloperskich do listy zatwierdzonych zakresów adresów IP klastra usługi AKS, aby uzyskać dostęp do serwera interfejsu API z tego miejsca. Możesz również skonfigurować serwer przesiadkowy z wymaganymi narzędziami wewnątrz oddzielnej podsieci w sieci wirtualnej zapory.

Pobierz swój adres IP przy użyciu następującego polecenia:

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

Dodaj adres IP do zatwierdzonych zakresów przy użyciu az aks update polecenia .

az aks update --resource-group $RG --name $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32

Skonfiguruj kubectl , aby nawiązać połączenie z klastrem az aks get-credentials usługi AKS przy użyciu polecenia .
```
az aks get-credentials --resource-group $RG --name $AKSNAME
```

Wdrażanie usługi publicznej w usłudze AKS

Teraz możesz rozpocząć udostępnianie usług i wdrażanie aplikacji w tym klastrze. W tym przykładzie uwidocznimy usługę publiczną, ale możesz również uwidocznić usługę wewnętrzną przy użyciu wewnętrznego modułu równoważenia obciążenia.

DnaT usługi publicznej

Zapoznaj się z manifestem demonstracyjnego pokazu usługi AKS Store, aby wyświetlić wszystkie zasoby, które zostaną utworzone.

Wdróż usługę kubectl apply przy użyciu polecenia .

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

Zezwalaj na ruch przychodzący przez usługę Azure Firewall

Ważne

Jeśli używasz usługi Azure Firewall do ograniczania ruchu wychodzącego i tworzenia trasy zdefiniowanej przez użytkownika w celu wymuszenia całego ruchu wychodzącego, upewnij się, że utworzono odpowiednią regułę DNAT w usłudze Azure Firewall, aby poprawnie zezwalać na ruch przychodzący. Używanie usługi Azure Firewall z trasą zdefiniowaną przez użytkownika przerywa konfigurację ruchu przychodzącego z powodu routingu asymetrycznego. Problem występuje, gdy podsieć usługi AKS ma domyślną trasę, która przechodzi do prywatnego adresu IP zapory, ale używasz publicznego modułu równoważenia obciążenia — ruchu przychodzącego lub usługi Kubernetes typu loadBalancer. W takim przypadku przychodzący ruch modułu równoważenia obciążenia jest odbierany za pośrednictwem publicznego adresu IP, ale ścieżka powrotna przechodzi przez prywatny adres IP zapory. Ponieważ zapora jest stanowa, odrzuca zwracany pakiet, ponieważ zapora nie zna ustalonej sesji. Aby dowiedzieć się, jak zintegrować usługę Azure Firewall z modułem równoważenia obciążenia ruchu przychodzącego lub usługi, zobacz Integrowanie usługi Azure Firewall z usługą Azure usługa Load Balancer w warstwie Standardowa.

Aby skonfigurować łączność przychodzącą, musisz napisać regułę DNAT w usłudze Azure Firewall. Aby przetestować łączność z klastrem, zdefiniowano regułę dla publicznego adresu IP frontonu zapory w celu kierowania do wewnętrznego adresu IP uwidocznionego przez usługę wewnętrzną. Adres docelowy można dostosować. Przetłumaczony adres musi być adresem IP wewnętrznego modułu równoważenia obciążenia. Przetłumaczony port musi być uwidoczniony dla usługi Kubernetes. Należy również określić wewnętrzny adres IP przypisany do modułu równoważenia obciążenia utworzonego przez usługę Kubernetes.

Pobierz wewnętrzny adres IP przypisany do modułu równoważenia obciążenia przy użyciu kubectl get services polecenia .

kubectl get services

Adres IP zostanie wyświetlony w kolumnie EXTERNAL-IP , jak pokazano w następujących przykładowych danych wyjściowych:

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

Pobierz adres IP usługi przy użyciu kubectl get svc store-front polecenia .

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

Dodaj regułę translatora adresów sieciowych az network firewall nat-rule create przy użyciu polecenia .

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

Weryfikowanie łączności

Przejdź do adresu IP frontonu usługi Azure Firewall w przeglądarce, aby zweryfikować łączność.

Powinna zostać wyświetlona aplikacja ze sklepu AKS. W tym przykładzie publiczny adres IP zapory to 52.253.228.132.

Na tej stronie możesz wyświetlać produkty, dodawać je do koszyka, a następnie składać zamówienie.

Czyszczenie zasobów

Aby wyczyścić zasoby platformy Azure, usuń grupę az group delete zasobów usługi AKS przy użyciu polecenia .

az group delete --name $RG

Następne kroki

W tym artykule przedstawiono sposób zabezpieczania ruchu wychodzącego przy użyciu usługi Azure Firewall. W razie potrzeby możesz uogólnić powyższe kroki, aby przekazać ruch do preferowanego rozwiązania ruchu wychodzącego zgodnie z dokumentacją Typu userDefinedRoute ruchu wychodzącego.

Udostępnij za pośrednictwem

Ograniczanie ruchu sieciowego za pomocą usługi Azure Firewall w usłudze Azure Kubernetes Service (AKS)

Skonfiguruj zmienne środowiskowe

Tworzenie sieci wirtualnej z wieloma podsieciami

Tworzenie i konfigurowanie usługi Azure Firewall

Tworzenie trasy z przeskokiem do usługi Azure Firewall

Dodawanie reguł zapory

Kojarzenie tabeli tras z usługą AKS

Wdrażanie klastra usługi AKS zgodnego z regułami ruchu wychodzącego

Tworzenie tożsamości przypisanych przez użytkownika

Tworzenie klastra usługi AKS przy użyciu istniejących tożsamości

Włączanie dostępu dewelopera do serwera interfejsu API

Wdrażanie usługi publicznej w usłudze AKS

Zezwalaj na ruch przychodzący przez usługę Azure Firewall

Weryfikowanie łączności

Czyszczenie zasobów

Następne kroki

Dodatkowe zasoby