Kontrollera utgående trafik för klusternoder i Azure Kubernetes Service (AKS)

Den här artikeln innehåller nödvändig information som gör att du kan skydda utgående trafik från din Azure Kubernetes Service (AKS). Den innehåller klusterkraven för en grundläggande AKS-distribution och ytterligare krav för valfria tillägg och funktioner. I slutet ges ett exempel på hur du konfigurerar dessa krav med Azure Firewall. Du kan dock använda den här informationen för alla metoder eller apparat för utgående begränsning.

Bakgrund

AKS-kluster distribueras i ett virtuellt nätverk. Det här nätverket kan hanteras (skapas av AKS) eller anpassat (förkonfigurerat av användaren i förväg). I båda fallen har klustret utgående beroenden av tjänster utanför det virtuella nätverket (tjänsten har inga inkommande beroenden).

För hantering och drift behöver noder i ett AKS-kluster komma åt vissa portar och fullständigt kvalificerade domännamn (FQDN). Dessa slutpunkter krävs för att noderna ska kunna kommunicera med API-servern eller för att ladda ned och installera kärnkomponenter för Kubernetes-kluster och nodsäkerhetsuppdateringar. Klustret måste till exempel hämta containeravbildningar för bassystem från Microsoft Container Registry (MCR).

De utgående AKS-beroendena är nästan helt definierade med FQDN, som inte har statiska adresser bakom sig. Bristen på statiska adresser innebär att nätverkssäkerhetsgrupper inte kan användas för att låsa utgående trafik från ett AKS-kluster.

Som standard har AKS-kluster obegränsad utgående (utgående) Internetåtkomst. Med den här nivån av nätverksåtkomst kan noder och tjänster som du kör komma åt externa resurser efter behov. Om du vill begränsa utgående trafik måste ett begränsat antal portar och adresser vara tillgängliga för att underhålla felfria klusterunderhållsuppgifter. Den enklaste lösningen för att skydda utgående adresser är att använda en brandväggsenhet som kan styra utgående trafik baserat på domännamn. Azure Firewall kan till exempel begränsa utgående HTTP- och HTTPS-trafik baserat på målets FQDN. Du kan också konfigurera dina önskade brandväggs- och säkerhetsregler för att tillåta dessa portar och adresser som krävs.

Nödvändiga regler för utgående nätverk och FQDN för AKS-kluster

Följande nätverk och FQDN/programregler krävs för ett AKS-kluster. Du kan använda dem om du vill konfigurera en annan lösning än Azure Firewall.

• IP-adressberoenden är för icke-HTTP/S-trafik (både TCP- och UDP-trafik)
• FQDN HTTP/HTTPS-slutpunkter kan placeras i brandväggsenheten.
• JOKERTECKEN HTTP/HTTPS-slutpunkter är beroenden som kan variera beroende på ditt AKS-kluster baserat på ett antal kvalificerare.
• AKS använder en antagningskontrollant för att mata in FQDN som en miljövariabel till alla distributioner under kube-system och gatekeeper-system, som säkerställer att all systemkommunikation mellan noder och API-server använder API-serverns FQDN och inte API-serverns IP-adress.
• Om du har en app eller lösning som behöver kommunicera med API-servern måste du lägga till ytterligare en nätverksregel som tillåter TCP-kommunikation till port 443 på API-serverns IP-adress.
• Om det finns en underhållsåtgärd kan API-serverns IP-adress ändras i sällsynta fall. Planerade underhållsåtgärder som kan ändra API-serverns IP-adress förmedlas alltid i förväg.

Globala nätverksregler som krävs för Azure

De nödvändiga nätverksreglerna och IP-adressberoendena är:

Azure Globala obligatoriska FQDN/programregler

Följande FQDN/programregler krävs:

Azure China 21Vianet nödvändiga nätverksregler

De nödvändiga nätverksreglerna och IP-adressberoendena är:

Azure China 21Vianet krävs FQDN/programregler

Följande FQDN/programregler krävs:

Nätverksregler som krävs för Azure US Government

De nödvändiga nätverksreglerna och IP-adressberoendena är:

Azure US Government krävs FQDN/programregler

Följande FQDN/programregler krävs:

Valfria rekommenderade FQDN/programregler för AKS-kluster

Följande FQDN/programregler är valfria men rekommenderas för AKS-kluster:

Om du väljer att blockera/inte tillåta dessa FQDN får noderna endast os-uppdateringar när du uppgraderar en nodavbildning eller uppgraderar klustret.

GPU-aktiverade AKS-kluster

Obligatoriskt FQDN/programregler

Följande FQDN/programregler krävs för AKS-kluster som har GPU aktiverat:

Windows serverbaserade nodpooler

Obligatoriskt FQDN/programregler

Följande FQDN/programregler krävs för att använda Windows serverbaserade nodpooler:

AKS-tillägg och integreringar

Azure Monitor för containrar

Det finns två alternativ för att ge åtkomst till Azure Monitor för containrar. Du kan tillåta Azure Monitor ServiceTag eller ge åtkomst till de FQDN/programregler som krävs.

Nätverksregler som krävs

Följande FQDN/programregler krävs:

Obligatoriskt FQDN/programregler

Följande FQDN/programregler krävs för AKS-kluster som har Azure Monitor för containrar aktiverade:

Azure Policy

Obligatoriskt FQDN/programregler

Följande FQDN/programregler krävs för AKS-kluster som har Azure Policy aktiverat.

Azure China 21Vianet krävs FQDN/programregler

Följande FQDN/programregler krävs för AKS-kluster som har Azure Policy aktiverat.

FQDN/programregler som krävs för Azure US Government

Följande FQDN/programregler krävs för AKS-kluster som har Azure Policy aktiverat.

Klustertillägg

Obligatoriskt FQDN/programregler

Följande FQDN/programregler krävs för att använda klustertillägg på AKS-kluster.

FQDN/programregler som krävs för Azure US Government

Följande FQDN/programregler krävs för att använda klustertillägg på AKS-kluster.

Begränsa utgående trafik med Hjälp av Azure Firewall

Azure Firewall innehåller en FQDN-tagg () Azure Kubernetes Service ( ) för AzureKubernetesService att förenkla den här konfigurationen.

Nedan visas ett exempel på en arkitektur för distributionen:

• Offentlig ingress tvingas att flöda genom brandväggsfilter
  • AKS-agentnoder är isolerade i ett dedikerat undernät.
  • Azure Firewall distribueras i ett eget undernät.
  • En DNAT-regel översätter den offentliga IP-adressen för den privata datorn till LB-ip-adressen för frontend.
• Utgående begäranden startar från agentnoder till Azure Firewall interna IP-adressen med hjälp av en användardefinierad väg
  • Begäranden från AKS-agentnoder följer en UDR som har placerats i det undernät som AKS-klustret distribuerades till.
  • Azure Firewall ut från det virtuella nätverket från en offentlig IP-server
  • Åtkomst till det offentliga Internet eller andra Azure-tjänster flödar till och från brandväggens IP-adress på frontend-sidan
  • Alternativt kan åtkomst till AKS-kontrollplanet skyddas av API-servernsauktoriserade IP-intervall , vilket inkluderar brandväggens offentliga IP-adress på serversidan.
• Intern trafik
  • Alternativt kan du i stället eller förutom en offentlig Load Balancer använda en intern Load Balancer för intern trafik, som du även kan isolera i sitt eget undernät.

Stegen nedan använder FQDN-taggen för Azure Firewall för att begränsa utgående trafik från AKS-klustret och ge ett exempel på hur du konfigurerar offentlig inkommande trafik AzureKubernetesService via brandväggen.

Ange konfiguration via miljövariabler

Definiera en uppsättning miljövariabler som ska användas i resursskapande.

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"

Skapa ett virtuellt nätverk med flera undernät

Etablera ett virtuellt nätverk med två separata undernät, ett för klustret, ett för brandväggen. Du kan också skapa en för intern tjänstingress.

Skapa en resursgrupp som ska innehålla alla resurser.

# Create Resource Group

az group create --name $RG --location $LOC

Skapa ett virtuellt nätverk med två undernät som värd för AKS-klustret och Azure Firewall. Var och en har sitt eget undernät. Vi börjar med AKS-nätverket.

# 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

Skapa och konfigurera en Azure Firewall med en UDR

Azure Firewall regler för inkommande och utgående måste konfigureras. Det huvudsakliga syftet med brandväggen är att göra det möjligt för organisationer att konfigurera detaljerade regler för in- och utgående trafik till och från AKS-klustret.

Skapa en offentlig IP-standardresurs för SKU:n som ska användas Azure Firewall på datorn.

az network public-ip create -g $RG -n $FWPUBLICIP_NAME -l $LOC --sku "Standard"

Registrera cli-tillägget preview för att skapa en 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

IP-adressen som skapades tidigare kan nu tilldelas till brandväggens frontend.

# 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

När föregående kommando har lyckats sparar du brandväggens IP-adress på serversidan för konfiguration senare.

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

Skapa en UDR med ett hopp till Azure Firewall

Azure dirigerar automatiskt trafik mellan Azure-undernät, virtuella nätverk och lokala nätverk. Om du vill ändra någon av Azures standardroutning gör du det genom att skapa en routningstabell.

Skapa en tom vägtabell som ska associeras med ett visst undernät. Vägtabellen definierar nästa hopp som den Azure Firewall skapade ovan. Varje undernät kan ha noll eller en associerad routningstabell.

# 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

Läs dokumentationen om virtuell nätverksvägtabell om hur du kan åsidosätta Azures standardsystemvägar eller lägga till ytterligare vägar i ett undernäts vägtabell.

Lägga till brandväggsregler

Nedan visas tre nätverksregler som du kan använda för att konfigurera i brandväggen. Du kan behöva anpassa dessa regler baserat på din distribution. Den första regeln tillåter åtkomst till port 9000 via TCP. Den andra regeln tillåter åtkomst till port 1194 och 123 via UDP (om du distribuerar till Azure China 21Vianet kan du behöva mer). Båda dessa regler tillåter endast trafik till den Azure-region-CIDR som vi använder, i det här fallet USA, östra. Slutligen lägger vi till en tredje nätverksregel som öppnar port 123 till FQDN via UDP (att lägga till ett FQDN som en nätverksregel är en av de specifika funktionerna i Azure Firewall och du måste anpassa det när du använder dina ntp.ubuntu.com egna alternativ).

När du har lagt till nätverksregler lägger vi även till en programregel med som omfattar alla nödvändiga FQDN som är tillgängliga via AzureKubernetesService TCP-port 443 och port 80.

# Add FW Network Rules

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

# Add FW Application Rules

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

Mer Azure Firewall tjänsten finns i Azure Firewall dokumentationen.

Associera vägtabellen med AKS

Om du vill associera klustret med brandväggen måste det dedikerade undernätet för klustrets undernät referera till den vägtabell som skapades ovan. Association kan göras genom att utfärda ett kommando till det virtuella nätverket som innehåller både klustret och brandväggen för att uppdatera vägtabellen för klustrets undernät.

# 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

Distribuera AKS med utgående typ av UDR till det befintliga nätverket

Nu kan ett AKS-kluster distribueras till det befintliga virtuella nätverket. Vi använder även userDefinedRouting utgående typ . Den här funktionen säkerställer att all utgående trafik tvingas genom brandväggen och att inga andra utgående sökvägar finns (som standard Load Balancer utgående typ kan användas).

Skapa ett huvudnamn för tjänsten med åtkomst till etablering i det befintliga virtuella nätverket

En klusteridentitet (hanterad identitet eller tjänstens huvudnamn) används av AKS för att skapa klusterresurser. Ett huvudnamn för tjänsten som skickas vid tidpunkten för att skapa används för att skapa underliggande AKS-resurser som Storage-resurser, IP-adresser och lastbalanserare som används av AKS (du kan också använda en hanterad identitet i stället). Om du inte har beviljats lämpliga behörigheter nedan kan du inte etablera AKS-klustret.

# Create SP and Assign Permission to Virtual Network

az ad sp create-for-rbac -n "${PREFIX}sp"

Ersätt nu och APPID nedan PASSWORD med appid för tjänstens huvudnamn och lösenordet för tjänstens huvudnamn som genererades automatiskt av föregående kommandoutdata. Vi refererar till VNET-resurs-ID:t för att bevilja behörigheter till tjänstens huvudnamn så att AKS kan distribuera resurser till det.

APPID="<SERVICE_PRINCIPAL_APPID_GOES_HERE>"
PASSWORD="<SERVICEPRINCIPAL_PASSWORD_GOES_HERE>"
VNETID=$(az network vnet show -g $RG --name $VNET_NAME --query id -o tsv)

# Assign SP Permission to VNET

az role assignment create --assignee $APPID --scope $VNETID --role "Network Contributor"

Du kan kontrollera de detaljerade behörigheter som krävs här.

RTID=$(az network route-table show -g $RG -n $FWROUTE_TABLE_NAME --query id -o tsv)
az role assignment create --assignee $APPID --scope $RTID --role "Network Contributor"

Distribuera AKS

Slutligen kan AKS-klustret distribueras till det befintliga undernät som vi har dedikerat för klustret. Målundernätet som ska distribueras till definieras med miljövariabeln $SUBNETID . Vi har inte definierat $SUBNETID variabeln i föregående steg. Om du vill ange värdet för undernäts-ID:t kan du använda följande kommando:

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

Du definierar den utgående typen för att använda den UDR som redan finns i undernätet. Med den här konfigurationen kan AKS hoppa över installationen och IP-etableringen för lastbalanseraren.

az aks create -g $RG -n $AKSNAME -l $LOC \
  --node-count 3 --generate-ssh-keys \
  --network-plugin $PLUGIN \
  --outbound-type userDefinedRouting \
  --service-cidr 10.41.0.0/16 \
  --dns-service-ip 10.41.0.10 \
  --docker-bridge-address 172.17.0.1/16 \
  --vnet-subnet-id $SUBNETID \
  --service-principal $APPID \
  --client-secret $PASSWORD \
  --api-server-authorized-ip-ranges $FWPUBLIC_IP

Aktivera utvecklaråtkomst till API-servern

Om du använde auktoriserade IP-intervall för klustret i föregående steg måste du lägga till dina IP-adresser för utvecklingsverktyg i AKS-klusterlistan över godkända IP-intervall för att få åtkomst till API-servern därifrån. Ett annat alternativ är att konfigurera en jumpbox med nödvändiga verktyg i ett separat undernät i brandväggens virtuella nätverk.

Lägg till ytterligare en IP-adress i godkända intervall med följande kommando

# 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

Använd kommandot [az aks get-credentials][az-aks-get-credentials] för att konfigurera för att ansluta till ditt nyligen skapade kubectl Kubernetes-kluster.

az aks get-credentials -g $RG -n $AKSNAME

Distribuera en offentlig tjänst

Nu kan du börja exponera tjänster och distribuera program till det här klustret. I det här exemplet exponerar vi en offentlig tjänst, men du kan också välja att exponera en intern tjänst via den interna lastbalanseraren.

Distribuera appen Azure Voting genom att kopiera yaml nedan till en fil med namnet 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/aks/samples/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/aks/samples/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/aks/samples/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

Distribuera tjänsten genom att köra:

kubectl apply -f example.yaml

Lägga till en DNAT-regel för att Azure Firewall

För att konfigurera inkommande anslutningar måste en DNAT-regel skrivas till Azure Firewall. För att testa anslutningen till klustret definieras en regel för brandväggens offentliga IP-adress på serversidan som dirigeras till den interna IP-adress som exponeras av den interna tjänsten.

Måladressen kan anpassas eftersom det är porten i brandväggen som ska nås. Den översatta adressen måste vara IP-adressen för den interna lastbalanseraren. Den översatta porten måste vara den exponerade porten för Kubernetes-tjänsten.

Du måste ange den interna IP-adressen som tilldelats till lastbalanseraren som skapas av Kubernetes-tjänsten. Hämta adressen genom att köra:

kubectl get services

IP-adressen som behövs visas i kolumnen EXTERNAL-IP, ungefär så här.

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

Hämta tjänstens IP-adress genom att köra:

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

Lägg till NAT-regeln genom att köra:

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

Validera anslutningen

Gå till Azure Firewall IP-adress i en webbläsare för att verifiera anslutningen.

Du bör se AKS-röstningsappen. I det här exemplet var brandväggens offentliga IP-adress 52.253.228.132 .

Rensa resurser

Om du vill rensa Azure-resurser tar du bort AKS-resursgruppen.

az group delete -g $RG

Nästa steg

I den här artikeln har du lärt dig vilka portar och adresser som ska tillåtas om du vill begränsa utgående trafik för klustret. Du har också sett hur du skyddar din utgående trafik med hjälp av Azure Firewall.

Om det behövs kan du generalisera stegen ovan för att vidarebefordra trafiken till din önskade utgående lösning genom att följa dokumentationen för utgående userDefinedRoute typ.

Om du vill begränsa hur poddar kommunicerar mellan sig själva och East-West trafikbegränsningar i klustret kan du se Skydda trafik mellan poddar med nätverksprinciper i AKS.