Używanie usługi Azure Firewall do ochrony klastrów usługi Azure Kubernetes Service (AKS)
W tym artykule przedstawiono sposób ochrony klastrów usługi Azure Kubernetes Service (AKS) przy użyciu usługi Azure Firewall w celu zabezpieczenia ruchu wychodzącego i przychodzącego.
Tło
Usługa Azure Kubernetes Service (AKS) oferuje zarządzany klaster Kubernetes na platformie Azure. Aby uzyskać więcej informacji, zobacz Azure Kubernetes Service.
Mimo że usługa AKS jest w pełni zarządzanym rozwiązaniem, nie oferuje wbudowanego rozwiązania do zabezpieczania ruchu przychodzącego i wychodzącego między klastrem a sieciami zewnętrznymi. Usługa Azure Firewall oferuje rozwiązanie tego problemu.
Klastry AKS są wdrażane w sieci wirtualnej. Tę sieć można zarządzać (utworzoną przez usługę AKS) lub niestandardową (wstępnie skonfigurowaną przez użytkownika wcześniej). W obu przypadkach klaster ma zależności wychodzące od usług spoza tej sieci wirtualnej (usługa nie ma zależności przychodzących). Do celów zarządzania i działania węzły w klastrze usługi AKS muszą uzyskiwać dostęp do określonych portów i w pełni kwalifikowanych nazw domen (FQDN) opisujących te zależności wychodzące. Jest to wymagane w przypadku różnych funkcji, w tym między innymi węzłów komunikujących się z serwerem interfejsu API Kubernetes. Pobierają i instalują podstawowe składniki klastra Kubernetes oraz aktualizacje zabezpieczeń węzłów lub ściągają podstawowe obrazy kontenerów systemu z usługi Microsoft Container Registry (MCR) itd. Te zależności wychodzące są prawie całkowicie zdefiniowane za pomocą nazw FQDN, które nie mają za nimi statycznych adresów. Brak adresów statycznych oznacza, że sieciowe grupy zabezpieczeń nie mogą być używane do blokowania ruchu wychodzącego z klastra usługi AKS. Z tego powodu domyślnie klastry usługi AKS mają nieograniczony dostęp do Internetu (wychodzący). Ten poziom dostępu do sieci umożliwia węzłom i usługom, które są uruchamiane w celu uzyskania dostępu do zasobów zewnętrznych zgodnie z potrzebami.
Jednak w środowisku produkcyjnym komunikacja z klastrem Kubernetes powinna być chroniona, aby zapobiec eksfiltracji danych wraz z innymi lukami w zabezpieczeniach. Cały ruch sieciowy przychodzący i wychodzący musi być monitorowany i kontrolowany na podstawie zestawu reguł zabezpieczeń. Jeśli chcesz to zrobić, musisz ograniczyć ruch wychodzący, ale ograniczona liczba portów i adresów musi pozostać dostępna, aby zachować zadania konserwacji klastra w dobrej kondycji i spełnić te wcześniej wymienione zależności wychodzące.
Najprostsze rozwiązanie używa urządzenia zapory, które może kontrolować ruch wychodzący na podstawie nazw domen. Zapora zazwyczaj ustanawia barierę między zaufaną siecią a niezaufaną siecią, taką jak Internet. Usługa Azure Firewall może na przykład ograniczyć wychodzący ruch HTTP i HTTPS na podstawie nazwy FQDN miejsca docelowego, zapewniając szczegółową kontrolę ruchu wychodzącego, ale jednocześnie umożliwia zapewnienie dostępu do nazw FQDN obejmujących zależności wychodzące klastra usługi AKS (czego nie można zrobić przez sieciowe grupy zabezpieczeń). Podobnie możesz kontrolować ruch przychodzący i zwiększyć bezpieczeństwo, włączając filtrowanie oparte na analizie zagrożeń w usłudze Azure Firewall wdrożonej w udostępnionej sieci obwodowej. Takie filtrowanie może zapewnić alerty oraz zablokować ruch do i ze znanych złośliwych adresów IP i domen.
Zapoznaj się z poniższym filmem wideo Abhinav Sriram, aby zapoznać się z krótkim omówieniem sposobu działania tego rozwiązania w środowisku przykładowym:
Możesz pobrać plik zip z Centrum pobierania Microsoft, który zawiera plik skryptu powłoki bash i plik yaml, aby automatycznie skonfigurować przykładowe środowisko używane w filmie wideo. Konfiguruje usługę Azure Firewall w celu ochrony ruchu przychodzącego i wychodzącego. W poniższych przewodnikach bardziej szczegółowo przedstawiono poszczególne kroki skryptu, dzięki czemu można skonfigurować konfigurację niestandardową.
Na poniższym diagramie przedstawiono przykładowe środowisko z filmu wideo skonfigurowanego przez skrypt i przewodnik:
Istnieje jedna różnica między skryptem a poniższym przewodnikiem. Skrypt używa tożsamości zarządzanych, ale w przewodniku jest używana jednostka usługi. Przedstawia to dwa różne sposoby tworzenia tożsamości do zarządzania zasobami klastra i tworzenia ich.
Ograniczanie ruchu wychodzącego przy użyciu usługi Azure Firewall
Ustawianie konfiguracji za pomocą zmiennych środowiskowych
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
Utwórz sieć wirtualną z dwiema oddzielnymi podsieciami— jedną dla klastra — jedną dla zapory. Opcjonalnie możesz również utworzyć jeden dla ruchu przychodzącego usługi wewnętrznej.
Utwórz grupę zasobów do przechowywania wszystkich zasobów.
# Create Resource Group
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. Każda z nich ma własną podsieć. Zacznijmy od sieci usługi AKS.
# 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 cannot 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 przy użyciu trasy zdefiniowanej przez użytkownika
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 zapory platformy Azure z wieloma adresami IP, zobacz tutaj
Utwórz standardowy zasób publicznego adresu IP jednostki SKU, który jest używany jako adres frontonu usługi Azure Firewall.
az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"
Zarejestruj rozszerzenie interfejsu wiersza polecenia w wersji zapoznawczej, aby utworzyć usługę Azure Firewall.
# Install Azure Firewall preview CLI extension
az extension add --name azure-firewall
# Deploy Azure Firewall
az network firewall create -g $RG -n $FWNAME -l $LOC --enable-dns-proxy true
Utworzony wcześniej adres IP można teraz przypisać do frontonu zapory.
Uwaga
Skonfigurowanie publicznego adresu IP w usłudze Azure Firewall może potrwać kilka minut. Aby korzystać z nazwy FQDN w regułach sieciowych, potrzebujemy włączonego serwera proxy DNS, po włączeniu zapory nasłuchuje na porcie 53 i przekaże żądania DNS do określonego wcześniej serwera DNS. Umożliwi to automatyczne tłumaczenie tej nazwy FQDN przez zaporę.
# Configure Firewall IP Config
az network firewall ip-config create -g $RG -f $FWNAME -n $FWIPCONFIG_NAME --public-ip-address $FWPUBLICIP_NAME --vnet-name $VNET_NAME
Gdy poprzednie polecenie zakończyło się pomyślnie, zapisz adres IP frontonu zapory na potrzeby konfiguracji później.
# Capture Firewall IP Address for Later Use
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)
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 zdefiniowanej przez użytkownika 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, należy to zrobić, tworząc tabelę tras.
Utwórz pustą tabelę tras, która ma być skojarzona z daną podsiecią. Tabela tras zdefiniuje następny przeskok jako utworzoną wcześniej usługę Azure Firewall. Każda podsieć może mieć skojarzoną ze sobą żadną lub jedną tabelę tras.
# Create UDR and add a route for Azure Firewall
az network route-table create -g $RG -l $LOC --name $FWROUTE_TABLE_NAME
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
Zobacz dokumentację tabeli tras sieci wirtualnej, aby dowiedzieć się, jak można zastąpić domyślne trasy systemowe platformy Azure lub dodać więcej tras do tabeli tras podsieci.
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.
Aby skonfigurować zaporę, możesz użyć następujących trzech reguł sieciowych. Może być konieczne dostosowanie tych reguł na podstawie wdrożenia. Pierwsza reguła umożliwia dostęp do portu 9000 za pośrednictwem protokołu TCP. Druga reguła umożliwia dostęp do portu 1194 i 123 za pośrednictwem protokołu UDP. Obie te reguły zezwalają tylko na ruch kierowany do trasy CIDR regionu świadczenia usługi Azure, z którego korzystamy— w tym przypadku Wschodnie stany USA.
Na koniec dodamy trzecią regułę sieci otwierającą port 123 do nazwy FQDN serwera czasu internetowego (na przykład:ntp.ubuntu.com) za pośrednictwem protokołu UDP. Dodanie nazwy FQDN jako reguły sieciowej jest jedną z określonych funkcji usługi Azure Firewall i trzeba ją dostosować podczas korzystania z własnych opcji.
Po ustawieniu reguł sieci dodamy również regułę aplikacji, korzystając z tej AzureKubernetesService reguły, która obejmuje wymagane nazwy FQDN dostępne za pośrednictwem portu TCP 443 i portu 80. Ponadto może być konieczne skonfigurowanie większej liczby reguł sieci i aplikacji na podstawie wdrożenia. Aby uzyskać więcej informacji, zobacz Reguły sieci wychodzącej i nazwy FQDN dla klastrów usługi Azure Kubernetes Service (AKS).
Dodawanie reguł sieci FW
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
Dodawanie reguł aplikacji FW
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
Zobacz dokumentację usługi Azure Firewall, aby dowiedzieć się więcej o usłudze Azure Firewall.
Kojarzenie tabeli tras z usługą AKS
Aby skojarzyć klaster z zaporą, dedykowana podsieć dla podsieci klastra musi odwoływać się do utworzonej wcześniej tabeli tras. Skojarzenie można wykonać, wydając polecenie do sieci wirtualnej zawierającej zarówno klaster, jak i zaporę, aby zaktualizować tabelę tras podsieci klastra.
# Associate route table with next hop to Firewall to the AKS subnet
az network vnet subnet update -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --route-table $FWROUTE_TABLE_NAME
Wdrażanie usługi AKS z typem ruchu wychodzącego trasy zdefiniowanej przez użytkownika w istniejącej sieci
Teraz klaster usługi AKS można wdrożyć w istniejącej sieci wirtualnej. Używasz również typu userDefinedRoutingruchu wychodzącego , ta funkcja zapewnia, że cały ruch wychodzący jest wymuszany przez zaporę i nie istnieją żadne inne ścieżki ruchu wychodzącego (domyślnie można użyć typu wychodzącego modułu równoważenia obciążenia).
Podsieć docelowa do wdrożenia jest definiowana za pomocą zmiennej środowiskowej $SUBNETID. Nie zdefiniowaliśmy zmiennej $SUBNETID w poprzednich krokach. Aby ustawić wartość identyfikatora podsieci, możesz użyć następującego polecenia:
SUBNETID=$(az network vnet subnet show -g $RG --vnet-name $VNET_NAME --name $AKSSUBNET_NAME --query id -o tsv)
Należy zdefiniować typ ruchu wychodzącego, aby użyć trasy zdefiniowanej przez użytkownika, która już istnieje w podsieci. Ta konfiguracja umożliwia usłudze AKS pomijanie konfiguracji i aprowizacji adresów IP dla modułu równoważenia obciążenia.
Ważne
Aby uzyskać więcej informacji na temat trasy zdefiniowanej przez użytkownika typu ruchu wychodzącego, w tym ograniczeń, zobacz trasa zdefiniowana przez użytkownika typu ruchu wychodzącego wychodzącego.
Napiwek
Do wdrożenia klastra można dodać dodatkowe funkcje, takie jak klaster prywatny lub zmiana jednostki SKU systemu operacyjnego.
Funkcję AKS dla autoryzowanych zakresów adresów IP serwera interfejsu API można dodać, 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 funkcji autoryzowanego 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 deweloperów do autoryzowanego zakresu adresów IP.
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
Uwaga
Aby utworzyć własną sieć wirtualną i tabelę tras z wtyczką kubenet sieciową i używać jej, musisz użyć tożsamości zarządzanej przypisanej przez użytkownika. W przypadku tożsamości zarządzanej przypisanej przez system nie możemy uzyskać identyfikatora tożsamości przed utworzeniem klastra, co powoduje opóźnienie w przypisaniu roli.
Aby utworzyć własną sieć wirtualną i tabelę tras z wtyczką azure sieciową i używać jej, obsługiwane są tożsamości zarządzane przypisane przez system i przypisane przez użytkownika.
Włączanie dostępu dewelopera do serwera interfejsu API
Jeśli w poprzednim kroku użyto autoryzowanych zakresów adresów IP 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. Inną opcją jest skonfigurowanie serwera przesiadkowego z wymaganymi narzędziami wewnątrz oddzielnej podsieci w sieci wirtualnej zapory.
Dodaj kolejny adres IP do zatwierdzonych zakresów za pomocą następującego polecenia
# Retrieve your IP address
CURRENT_IP=$(dig @resolver1.opendns.com ANY myip.opendns.com +short)
# Add to AKS approved list
az aks update -g $RG -n $AKSNAME --api-server-authorized-ip-ranges $CURRENT_IP/32
Użyj polecenia az aks get-credentials, aby skonfigurować kubectl połączenie z nowo utworzonym klastrem Kubernetes.
az aks get-credentials -g $RG -n $AKSNAME
Ograniczanie ruchu przychodzącego przy użyciu usługi Azure Firewall
Teraz możesz rozpocząć udostępnianie usług i wdrażanie aplikacji w tym klastrze. W tym przykładzie uwidaczniamy usługę publiczną, ale możesz również uwidocznić usługę wewnętrzną za pośrednictwem wewnętrznego modułu równoważenia obciążenia.
Wdróż aplikację aplikacji do głosowania platformy Azure, kopiując następujący kod yaml do pliku o nazwie example.yaml.
# voting-storage-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-storage
spec:
replicas: 1
selector:
matchLabels:
app: voting-storage
template:
metadata:
labels:
app: voting-storage
spec:
containers:
- name: voting-storage
image: mcr.microsoft.com/azuredocs/voting/storage:2.0
args: ["--ignore-db-dir=lost+found"]
resources:
requests:
cpu: 100m
memory: 128Mi
limits:
cpu: 250m
memory: 256Mi
ports:
- containerPort: 3306
name: mysql
volumeMounts:
- name: mysql-persistent-storage
mountPath: /var/lib/mysql
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
volumes:
- name: mysql-persistent-storage
persistentVolumeClaim:
claimName: mysql-pv-claim
---
# voting-storage-secret.yaml
apiVersion: v1
kind: Secret
metadata:
name: voting-storage-secret
type: Opaque
data:
MYSQL_USER: ZGJ1c2Vy
MYSQL_PASSWORD: UGFzc3dvcmQxMg==
MYSQL_DATABASE: YXp1cmV2b3Rl
MYSQL_ROOT_PASSWORD: UGFzc3dvcmQxMg==
---
# voting-storage-pv-claim.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: mysql-pv-claim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
---
# voting-storage-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-storage
labels:
app: voting-storage
spec:
ports:
- port: 3306
name: mysql
selector:
app: voting-storage
---
# voting-app-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-app
spec:
replicas: 1
selector:
matchLabels:
app: voting-app
template:
metadata:
labels:
app: voting-app
spec:
containers:
- name: voting-app
image: mcr.microsoft.com/azuredocs/voting/app:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
- name: ANALYTICS_HOST
value: "voting-analytics"
---
# voting-app-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-app
labels:
app: voting-app
spec:
type: LoadBalancer
ports:
- port: 80
targetPort: 8080
name: http
selector:
app: voting-app
---
# voting-analytics-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: voting-analytics
spec:
replicas: 1
selector:
matchLabels:
app: voting-analytics
version: "2.0"
template:
metadata:
labels:
app: voting-analytics
version: "2.0"
spec:
containers:
- name: voting-analytics
image: mcr.microsoft.com/azuredocs/voting/analytics:2.0
imagePullPolicy: Always
ports:
- containerPort: 8080
name: http
env:
- name: MYSQL_HOST
value: "voting-storage"
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: voting-storage-secret
key: MYSQL_DATABASE
---
# voting-analytics-service.yaml
apiVersion: v1
kind: Service
metadata:
name: voting-analytics
labels:
app: voting-analytics
spec:
ports:
- port: 8080
name: http
selector:
app: voting-analytics
Wdróż usługę, uruchamiając polecenie:
kubectl apply -f example.yaml
Dodawanie reguły DNAT do usługi 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 zaporze, 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, jeśli podsieć usługi AKS ma trasę domyślną, 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ą, należy zapisać 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ć w miarę uzyskiwania dostępu do portu zapory. 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 określić wewnętrzny adres IP przypisany do modułu równoważenia obciążenia utworzonego przez usługę Kubernetes. Pobierz adres, uruchamiając polecenie:
kubectl get services
Wymagany adres IP znajduje się w kolumnie EXTERNAL-IP, podobnie jak poniżej.
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.41.0.1 <none> 443/TCP 10h
voting-analytics ClusterIP 10.41.88.129 <none> 8080/TCP 9m
voting-app LoadBalancer 10.41.185.82 20.39.18.6 80:32718/TCP 9m
voting-storage ClusterIP 10.41.221.201 <none> 3306/TCP 9m
Pobierz adres IP usługi, uruchamiając polecenie:
SERVICE_IP=$(kubectl get svc voting-app -o jsonpath='{.status.loadBalancer.ingress[*].ip}')
Dodaj regułę translatora adresów sieciowych, uruchamiając polecenie:
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 do głosowania w usłudze AKS. W tym przykładzie publiczny adres IP zapory to 52.253.228.132.
Czyszczenie zasobów
Aby wyczyścić zasoby platformy Azure, usuń grupę zasobów usługi AKS.
az group delete -g $RG
Następne kroki
- Dowiedz się więcej o usłudze Azure Kubernetes Service, zobacz Podstawowe pojęcia dotyczące platformy Kubernetes dla usługi Azure Kubernetes Service (AKS).
Opinia
Dostępne już wkrótce: W 2024 r. będziemy stopniowo wycofywać zgłoszenia z serwisu GitHub jako mechanizm przesyłania opinii na temat zawartości i zastępować go nowym systemem opinii. Aby uzyskać więcej informacji, sprawdź: https://aka.ms/ContentUserFeedback.
Prześlij i wyświetl opinię dla