Använd Azure Firewall för att skydda ett AKS-kluster

Den här guiden beskriver hur du skapar ett privat Azure Kubernetes Service (AKS) kluster i en nätverkstopologi med hub-spoke med hjälp av Terraform och Azure DevOps. Azure Firewall inspekterar trafik till och från AKS-klustret. Det virtuella hubbnätverket är peer-kopplat till ett eller flera ekervirtuella nätverk som är värdar för klustret.

Architecture

Ladda ned en Visio-fil av den här arkitekturen.

Workflow

Följande arbetsflöde motsvarar föregående diagram:

Terraform-moduler distribuerar ett nytt virtuellt nätverk som har fyra undernät som är värdar för:

AKS-klustret (AksSubnet).
En virtuell jump box-dator (VM) och privata slutpunkter (VmSubnet).
Azure Application Gateway Web Application Firewall v2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet).

AKS-klustret använder en användardefinierad hanterad identitet för att skapa andra resurser, till exempel lastbalanserare och hanterade diskar i Azure. Genom att använda Terraform-moduler kan du distribuera ett AKS-kluster som har följande funktioner:

AKS-klustret består av:

En systemnodpool som endast är värd för kritiska systempoddar och tjänster.
En användarnodpool som innehåller användararbetslaster och artefakter.

En virtuell dator distribueras i det virtuella nätverk som är värd för AKS-klustret. När du distribuerar AKS som ett privat kluster kan systemadministratörer använda den här virtuella datorn för att hantera klustret via kommandoradsverktyget Kubernetes. Ett Azure Storage-konto lagrar loggarna för vm-startdiagnostik.

En Azure Bastion-värd ger SSH-anslutning med förbättrad säkerhet till jumpbox-VM:n. Azure Container Registry används för att skapa, lagra och hantera containeravbildningar och artefakter som Helm-diagram.

AKS tillhandahåller ingen inbyggd lösning för att skydda inkommande och utgående trafik mellan klustret och externa nätverk.

Därför innehåller arkitekturen i den här artikeln en Azure Firewall som styr inkommande trafik med hjälp av DNAT-regler (målnätverksadressöversättning) och utgående trafik med nätverks- och programregler. Brandväggen tillämpar källnätverksadressöversättning (SNAT) på utgående flöden från klustret. Den ersätter podd-IP-adressen med en av brandväggens offentliga IP-adresser, vilket blir klustrets utgående identitet för partner-tillåtna listor. Brandväggen skyddar även arbetsbelastningar med hjälp av hotinformationsbaserad filtrering. Azure Firewall och Azure Bastion distribueras till ett virtuellt navnätverk som är peer-kopplat till det virtuella nätverk som är värd för det privata AKS-klustret. En routningstabell och användardefinierade vägar (UDR) dirigerar utgående trafik från AKS-klustret till Azure Firewall.

Anmärkning

Vi rekommenderar starkt att du använder Azure Firewall Premium eftersom det ger avancerat skydd mot hot.

Arbetsbelastningar som körs på AKS använder Azure Key Vault som lagringsplats för hemligheter för att hämta nycklar, certifikat och hemligheter med hjälp av Microsoft Entra Workload Identity, Secrets Store CSI Driver eller Dapr. Azure Private Link gör det möjligt för AKS-arbetsbelastningar att komma åt Azure PaaS-tjänster (plattform som en tjänst), till exempel Key Vault, via en privat slutpunkt i det virtuella nätverket.

Topologin innehåller privata slutpunkter och privata DNS-zoner (Domain Name System) för dessa tjänster:

En virtuell nätverkslänk ansluter det virtuella nätverket som är värd för AKS-klustret till de privata DNS-zoner som beskrevs tidigare.

En Log Analytics arbetsyta samlar in diagnostikloggar och mått från Azure tjänster.

Components

Azure Firewall är en molnbaserad, intelligent nätverksbrandväggssäkerhetstjänst som ger skydd mot hot för molnarbetsbelastningar som körs i Azure. I den här arkitekturen tillhandahåller Azure Firewall trafikkontroll i både öst-väst och nord-syd. Den använder DNAT-regler för att publicera inkommande flöden till privata arbetsbelastningar, nätverk och programregler för att filtrera utgående flöden och SNAT för att översätta utgående trafik till dess offentliga IP-adress. Det skyddar också arbetsbelastningar med hjälp av hotinformationsbaserad filtrering i det virtuella hubbnätverket.
Container Registry är en hanterad, privat Docker-registertjänst som baseras på Docker Registry 2.0 med öppen källkod. I den här arkitekturen skapar, lagrar och hanterar Container Registry containeravbildningar och artefakter som Helm-diagram som distribueras till AKS-klustret. Den stöder georeplikering för scenarier för haveriåterställning (DR).
AKS är en hanterad Kubernetes-tjänst som förenklar distribution och hantering av Kubernetes-kluster. I den här arkitekturen är AKS värd för det privata klustret med system- och användarnodpooler i ett spoke-virtuellt nätverk.
Key Vault är en molnbaserad tjänst som lagrar och styr åtkomsten till hemligheter som API-nycklar, lösenord, certifikat och kryptografiska nycklar med förbättrad säkerhet. I den här arkitekturen fungerar Key Vault som ett hemligt arkiv för arbetsbelastningar som körs på AKS.
Azure Bastion är en fullständigt hanterad PaaS som tillhandahåller Fjärrskrivbord Protocol (RDP) och SSH-anslutning till de virtuella datorerna i ditt virtuella nätverk, direkt från Azure portalen via TLS (Transport Layer Security). I den här arkitekturen ger Azure Bastion säkrare åtkomst till den virtuella jump box-datorn via TLS från Azure-portalen, vilket eliminerar behovet av att exponera virtuella datorer direkt till det offentliga Internet.
Azure Virtual Machines är en beräkningstjänst som tillhandahåller skalbara beräkningsresurser på begäran som ger dig flexibiliteten i virtualisering. I den här arkitekturen fungerar Virtual Machines som den jumpbox-värd som distribueras i det virtuella nätverk där AKS-klustret finns. Systemadministratörer använder Virtual Machines för att hantera det privata klustret via kubectl när direktåtkomsten till API-servern är begränsad.
Azure Virtual Network är den grundläggande byggstenen för Azure privata nätverk. Med virtuellt nätverk kan Azure-resurser, till exempel virtuella datorer, kommunicera med varandra, Internet och lokala nätverk med förbättrad säkerhet. I den här arkitekturen tillhandahåller Virtual Network nätverksisolering och anslutning med spetznätverket som är värd för AKS-klustret och undernät för olika komponenter. Den är peer-kopplad till hubbnätverket som innehåller Azure Firewall och Azure Bastion.
Virtuella nätverksgränssnitt är nätverkskomponenter som gör att virtuella Azure-datorer kan kommunicera med internet, Azure och lokala resurser. I den här arkitekturen tillhandahåller nätverksgränssnitt anslutning för jump box VM- och AKS-noderna. Du kan lägga till flera nätverkskort till en Azure virtuell dator så att underordnade virtuella datorer kan ha egna dedikerade nätverksenheter och IP-adresser.
Azure-hanterade diskar är lagringsvolymer på blocknivå som Azure hanterar på virtuella Azure-datorer. Ultra Diskar, Premium SSD, Standard SSD och Standard HDD är tillgängliga. I den här arkitekturen tillhandahåller hanterade diskar beständig lagring för den virtuella jump box-datorn och AKS-klusternoderna.
Blob Storage är en objektlagringslösning för molnet. Blob Storage är optimerad för lagring av enorma mängder ostrukturerade data. I den här arkitekturen lagrar Blob Storage startdiagnostikloggarna för den virtuella jump box-datorn.
Private Link är en nätverkstjänst som hjälper dig att komma åt Azure PaaS-tjänster via en privat slutpunkt i det virtuella nätverket. I den här arkitekturen tillhandahåller Private Link säker anslutning till tjänster som Blob Storage, Container Registry och Key Vault. Det säkerställer att trafiken förblir på Azure-stamnätet utan exponering för det offentliga Internet. Du kan också använda den för att komma åt Azure värdbaserade tjänster som du äger eller som en Microsoft-partner tillhandahåller.

Alternatives

Du kan använda en brandvägg som inte är Microsoft från Microsoft Marketplace i stället för Azure Firewall. Med den här metoden måste du konfigurera brandväggen korrekt för att inspektera och tillåta eller neka inkommande och utgående trafik från AKS-klustret.

Scenarioinformation

AKS-kluster distribueras i ett hanterat eller anpassat virtuellt nätverk. Klustret har fortfarande utgående beroenden på tjänster utanför nätverket. I hanterings- och driftsyfte måste AKS-klusternoder komma åt specifika portar och fullständigt kvalificerade domännamn (FQDN) som är associerade med dessa beroenden. Dessa krav omfattar åtkomst till klustrets Kubernetes API-server, åtkomst till portar för nedladdning av klusterkomponenter och åtkomst till Microsoft Container Registry för att hämta containeravbildningar. Dessa utgående beroenden definieras med FQDN och har inte statiska IP-adresser, vilket hindrar dig från att låsa utgående trafik med hjälp av nätverkssäkerhetsgrupper (NSG: er). Därför tillåter AKS-kluster obegränsad utgående internetåtkomst som standard så att noder och tjänster kan nå nödvändiga externa resurser.

I en produktionsmiljö är det dock vanligtvis bättre att skydda Kubernetes-klustret från dataexfiltrering och annan oönskad nätverkstrafik. All inkommande och utgående nätverkstrafik måste följa definierade säkerhetsregler. För att uppfylla detta krav begränsar du utgående trafik samtidigt som du tillåter åtkomst till nödvändiga portar och adresser för rutinmässiga klusterunderhållsuppgifter, utgående beroenden och arbetsbelastningskrav.

En enkel lösning är att använda en brandväggsenhet som kan styra utgående trafik baserat på domännamn. En brandvägg skapar en barriär mellan ett betrott nätverk och Internet. Använd Azure Firewall för att begränsa utgående trafik baserat på målets fullständiga domännamn, protokoll och port för att tillhandahålla detaljerad utgående trafikkontroll. Det möjliggör också allowlisting till FQDN:er som är associerade med ett AKS-klusters utgående beroenden, vilket inte är möjligt med hjälp av NSG:er. Dessutom kan hotinformationsbaserad filtrering på Azure Firewall distribueras till ett delat perimeternätverk styra inkommande trafik och förbättra säkerheten. Den här filtreringen kan generera aviseringar och neka trafik till och från kända skadliga IP-adresser och domäner.

Du kan skapa ett privat AKS-kluster i en hub and spoke-nätverkstopologi med hjälp av Terraform och Azure DevOps. Azure Firewall inspekterar trafik till och från AKS-klustret. Klustret hanteras av ett eller flera virtuella ekernätverk som är peer-kopplade till det virtuella hubbnätverket.

Azure Firewall har stöd för tre olika SKU:er för att hantera en mängd olika kundanvändningsfall och inställningar:

Azure Firewall Premium rekommenderas för att skydda mycket känsliga program, till exempel betalningsbearbetning. Den stöder avancerade hotskyddsfunktioner som identifiering av skadlig kod och TLS-inspektion.
Azure Firewall Standard rekommenderas för kunder som behöver layer-3 via layer-7-brandväggsfunktioner och automatisk skalning som stöder trafiktoppar på upp till 30 Gbit/s. Den stöder företagsfunktioner som hotinformation, DNS-proxy, anpassade DNS- och webbkategorier.
Azure Firewall Basic rekommenderas för kunder med dataflödesbehov på mindre än 250 Mbit/s.

I följande tabell visas funktionerna i de tre Azure Firewall-SKU:erna. För mer information, se Azure Firewall-priser.

Som standard har AKS-kluster obegränsad utgående internetåtkomst. Med den här nivån av nätverksåtkomst kan noder och tjänster som körs i AKS-klustret komma åt externa resurser efter behov. Om du vill begränsa utgående trafik måste ett begränsat antal portar och adresser vara nåbara för att upprätthålla felfria klusterunderhållsuppgifter. Det enklaste sättet att ge säkerhet för utgående trafik från ett Kubernetes-kluster som AKS är att använda en programvarubrandvägg som kan styra utgående trafik baserat på domännamn. Azure Firewall kan begränsa utgående HTTP- och HTTPS-trafik baserat på målets fullständiga domännamn. Du kan också konfigurera brandväggs- och säkerhetsreglerna för att tillåta dessa portar och adresser som krävs. Mer information finns i Kontrollera utgående trafik för klusternoder i AKS.

Du kan också styra inkommande trafik och förbättra säkerheten genom att aktivera hotinformationsbaserad filtrering på en Azure Firewall distribuerad till ett delat perimeternätverk. Den här filtreringen kan ge aviseringar och neka trafik till och från kända skadliga IP-adresser och domäner.

Potentiella användningsfall

I det här scenariot åtgärdas behovet av att förbättra säkerheten för inkommande och utgående trafik till och från ett Kubernetes-kluster.

Konfigurera AKS-klustret så att det går ut via Azure Firewall

För att tvinga utgående trafik från AKS att gå via Azure Firewall måste du konfigurera klustret, inte bara brandväggen och vägtabellen. Fatta dessa beslut när du skapar klustret:

Ange utgående typ till userDefinedRouting. Med den här utgående typen etablerar AKS inte en offentlig standardlastbalanserare för utgående trafik och lägger inte till sina egna offentliga SNAT-IP-adresser. All utgående trafik från nodpoolens undernät följer UDR till den Azure Firewall privata IP-adressen, vilket ger brandväggen fullständig insyn i varje utgående flöde. Mer information finns i Konfigurera utgående klustertyper i AKS.
Använd taggen AzureKubernetesService FQDN för den obligatoriska tillåtelselistan för utgående trafik. AKS kräver utgående åtkomst till en lång och ofta uppdaterad lista över FQDN:er för kommunikation med kontrollplanet, bildhämtningar, identiteter och andra plattformstjänster. I stället för att underhålla dessa FQDN själv skapar du en Azure Firewall programregel som använder FQDN-taggenAzureKubernetesService. Azure Firewall håller den här taggen aktuell med plattformens nödvändiga slutpunkter. Kombinera den här taggen med målnätverksregler för NTP (Network Time Protocol), API-servern på TCP 9000 och UDP 1194 samt containerregister som dina arbetsbelastningar använder.
Använd api-serverintegrering av virtuella nätverk för att behålla API-servertrafik i det privata nätverket. API-serverintegrering av virtuella nätverk projicerar API-serverslutpunkten till ett delegerat undernät i ditt virtuella nätverk. Nod-till-API-server-trafik finns kvar i det privata nätverket och passerar inte Azure Firewall. Det här beteendet tar bort behovet av AKS-tunnelnätverksregler och minskar antalet utgående flöden som brandväggen måste inspektera. Kombinera integrering av virtuella API-servernätverk med inställningen för privat kluster om du också vill blockera åtkomst till det offentliga nätverket till API-servern. Mer information finns i Skapa ett AKS-kluster med integrering av virtuella API-servrar. Integrering av virtuella API-servrar är den rekommenderade metoden för nya privata kluster. Den äldre implementeringen av privata kluster som använder Private Link stöds men lägger till DNS- och tunnelkomplexitet som integrering av virtuella nätverk tar bort.

Planera Azure Firewall offentliga IP-adresser och SNAT-kapacitet

Azure Firewall använder SNAT för alla utgående flöden. Varje offentlig IP-adress som är kopplad till brandväggen innehåller ett fast antal SNAT-portar, cirka 2 496 portar per IP-adress per backend-instans. Ett AKS-produktionskluster genererar många samtidiga utgående flöden från poddar, särskilt när poddar öppnar många kortvariga anslutningar till ett litet antal externa mål. Om du allokerar för få offentliga IP-adresser tar SNAT-portarna slut, och utgående anrop börjar intermittent misslyckas med anslutningstimeouter som är svåra att diagnostisera.

AKS-vägledningen i Begränsa nätverkstrafik med Azure Firewall i AKS rekommenderar minst 20 offentliga IP-adresser på klientsidan på Azure Firewall för produktionsarbetsbelastningar för att undvika SNAT-portöverbelastning. Behandla det här talet som en startpunkt, inte ett fast krav. Det rätta antalet beror på arbetsbelastningens utgående samtidighet, mångfalden av mål och anslutningars livslängd.
Använd Azure Firewall NAT Gateway-integrering eller koppla ett offentligt IP-prefix för att förenkla hanteringen av många offentliga IP-adresser och utöka den tillgängliga SNAT-portpoolen. NAT Gateway ökar SNAT-kapaciteten dramatiskt och är det föredragna alternativet för utgående trafik med hög samtidighet.
Övervaka SNAT-portanvändning på Azure Firewall och skala offentliga IP-adresser i brandväggen innan de når mättnad. Mer information finns i Övervaka Azure Firewall.
Om ett litet antal arbetslaster dominerar den utgående flödesprofilen (till exempel loggavsändare eller insamlare som körs på varje nod men bara skickar trafik till en eller två slutpunkter) bör du överväga en dedikerad utgående väg via en statisk egress-gateway i stället för att skala antalet IP-adresser för brandväggen för att hantera en enskild arbetslast med mycket trafik.

Undvik asymmetrisk routning

I den här lösningen distribueras Azure Firewall till ett virtuellt navnätverk, medan det privata AKS-klustret distribueras till ett virtuellt kantnätverk. Azure Firewall använder nätverks- och programregelsamlingar för att styra utgående trafik. I det här fallet konfigurerar du inkommande trafik till alla offentliga slutpunkter som exponeras av alla tjänster som körs på AKS för att komma in i systemet via en av de offentliga IP-adresser som Azure Firewall använder.

Paket anländer till brandväggens offentliga IP-adress men återgår till brandväggen via den privata IP-adressen med hjälp av standardvägen. Undvik det här problemet genom att skapa en annan UDR för brandväggens offentliga IP-adress, enligt följande diagram. Paket som går till brandväggens offentliga IP-adress dirigeras via Internet. Den här konfigurationen undviker standardvägen till brandväggens privata IP-adress.

Om du vill dirigera trafiken för dina AKS-arbetsbelastningar till Azure Firewall i det virtuella hubbnätverket måste du:

Skapa och associera en routningstabell till varje undernät som är värd för arbetsnoderna i klustret.
Skapa en UDR för att vidarebefordra trafiken för 0.0.0.0/0 klasslös routning mellan domäner (CIDR) till den privata IP-adressen för Azure Firewall. Ange en virtuell installation för nästa hopptyp.

Mer information finns i Distribuera och konfigurera Azure Firewall med hjälp av Azure portalen.

Mer information finns i:

Distribuera arbetsbelastningar till ett privat AKS-kluster när du använder Azure DevOps

Om du använder Azure DevOps kan du inte använda Azure DevOps Microsoft värdbaserade agenter för att distribuera dina arbetsbelastningar till ett privat AKS-kluster eftersom de inte har åtkomst till dess API-server. Om du vill distribuera arbetsbelastningar till ditt privata AKS-kluster måste du etablera och använda en lokalt installerad Azure DevOps-agent i samma virtuella nätverk som ditt privata AKS-kluster eller i ett peer-kopplat virtuellt nätverk. I det andra fallet skapar du en virtuell nätverkslänk mellan aks-klustrets privata DNS-zon i nodresursgruppen och det virtuella nätverk som är värd för Azure DevOps lokalt installerad agent.

Du kan distribuera en enda Windows- eller Linux-Azure DevOps-agent på en virtuell dator, eller så kan du använda en Azure VM-skalningsuppsättning. Mer information finns i agenter för skalningsuppsättningar för virtuella datorer. Alternativt kan du konfigurera en lokalt installerad agent i Azure-pipelines så att den körs i en Windows Server Core-container (för Windows-värdar) eller Ubuntu-container (för Linux-värdar) med Docker. Distribuera den som en pod med en eller flera replikor i ditt privata AKS-kluster. Mer information finns i:

Om de undernät som är värdar för nodpoolerna i ditt privata AKS-kluster har konfigurerats för att dirigera utgående trafik till Azure Firewall via en routningstabell och UDR ska du skapa rätt program- och nätverksregler. Dessa regler måste tillåta agenten att komma åt externa webbplatser för att ladda ned och installera verktyg som Docker, Kubectl, Azure CLI och Helm på den virtuella agentdatorn. Mer information finns i Köra en lokalt installerad agent i Docker.

Du kan också konfigurera en hanterad DevOps-pool i det virtuella nätverk som är värd för ditt AKS-kluster eller i ett peer-kopplat virtuellt nätverk. Hanterade DevOps-pooler hjälper utvecklingsteam att skapa Azure DevOps agentpooler som är skräddarsydda för deras specifika behov. De implementerar metodtips för säkerhet, tillhandahåller alternativ för att balansera kostnader och prestanda, tillhandahålla sökvägar för vanliga scenarier och avsevärt minska den tid som ägnas åt att skapa och underhålla anpassade pooler. Mer information finns i Översikt över Arkitektur för Microsoft Managed DevOps-pooler.

Du kan lägga till agenter från en hanterad DevOps-pool i ditt virtuella nätverk så att CI/CD-pipelines kan interagera med Kubernetes API-servern i ditt privata AKS-kluster. Dessa agenter låter också pipelines komma åt Azure resurser, till exempel Container Registry, som blockerar åtkomst till offentliga nätverk och endast tillåter anslutningar via en privat slutpunkt som definierats i samma virtuella nätverk eller ett peer-kopplat nätverk. Mer information finns i Konfigurera nätverk för hanterade DevOps-pooler.

Använda Azure Firewall framför en offentlig lastbalanserare

I det här scenariot exponeras en arbetsbelastning som körs i AKS via en offentlig Azure lastbalanserare (en Kubernetes-tjänstLoadBalancer) i klustrets nodresursgrupp. Azure Firewall sitter framför lastbalanseraren och använder en dedikerad offentlig IP-adress och en DNAT-regel för att översätta inkommande trafik till lastbalanserarens offentliga IP-adress och port. Det här mönstret centraliserar inkommande inspektions-, DNAT- och hotinformationsbaserad filtrering i brandväggen och låter AKS fortsätta att hantera lastbalanseraren för Kubernetes-tjänsten. Använd den här metoden när arbetsbelastningen måste kunna nås från Internet, men du vill att all inkommande trafik ska passera hubbens brandvägg innan den når klustret.

Det här diagrammet visar scenariots nätverkstopologi.

Här är meddelandeflödet:

En begäran till webbprogrammet som körs på AKS skickas till en offentlig IP-adress som Azure Firewall exponerar via en konfiguration för offentlig IP-adress. Både den offentliga IP-adressen och den offentliga IP-adresskonfigurationen är dedikerade till den här arbetsbelastningen.
En Azure Firewall DNAT-regel översätter Azure Firewalls offentliga IP-adress och port till den offentliga IP-adress och port som arbetsbelastningen använder i AKS-klustrets offentliga lastbalanserare i nodresursgruppen.
Lastutjämnaren skickar begäran till en tjänstepodd i Kubernetes som körs på en agentnod i AKS-klustret.
Svarsmeddelandet skickas tillbaka till den ursprungliga anroparen via en UDR. Rutten anger Azure Firewalls offentliga IP-adress som adressprefix och Internet som typ av nästa hopp.
Alla utgående anrop som initieras av arbetsbelastningen dirigeras av standard-UDR:n till Azure Firewalls privata IP-adress. Routen använder 0.0.0.0/0 som adressprefix och virtuell nätverksinstallation som nästa hopptyp.

Använda Azure Firewall framför en intern lastbalanserare

I det här scenariot hanteras ett ASP.NET Core program som en tjänst av ett AKS-kluster och frontas av en ingresskontrollant som en intern lastbalanserare exponerar. De rekommenderade metoderna för ingress i AKS är Gateway API-implementeringen för programroutning eller Application Gateway for Containers. Api-implementeringen för programroutning använder Kubernetes Gateway API-standarden med ett Istio-baserat kontrollplan för hantering av inkommande trafik i klustret. Application Gateway for Containers är en fullständigt hanterad Azure inbyggd layer-7-lastbalanserare som också stöder Gateway-API:et och tillhandahåller avancerad trafikhantering, TLS-avslutning och värdtjänster för flera platser utanför klustret. Båda alternativen stöder konfiguration av en intern lastbalanserare med en privat IP-adress i det virtuella ekernätverket som är värd för AKS-klustret. När du distribuerar en ingress-styrenhet, eller mer allmänt en tjänst av typen LoadBalancer eller ClusterIP, med annoteringen service.beta.kubernetes.io/azure-load-balancer-internal: "true" i metadataavsnittet, skapas en intern lastbalanserare som kallas kubernetes-internal i nodresursgruppen. Mer information finns i Använda en intern lastbalanserare med AKS. Som du ser i följande diagram exponerar Azure Firewall testwebbappen med hjälp av en dedikerad Azure offentlig IP-adress.

Här är meddelandeflödet:

En begäran till testwebbprogrammet som finns i AKS skickas till en offentlig IP-adress som Azure Firewall exponerar via en konfiguration av offentlig IP-adress. Både den offentliga IP-adressen och den offentliga IP-adresskonfigurationen är dedikerade till den här arbetsbelastningen.
En Azure Firewall DNAT-regel översätter Azure Firewalls offentliga IP-adress och port till den privata IP-adress och port som den valda Ingress- eller Gateway-styrenheten använder i den interna lastbalanseraren för AKS-klustret i nodresursgruppen.
Den interna lastbalanseraren skickar begäran till en Kubernetes-tjänstpodd som körs på en agentnod i AKS-klustret.
Svarsmeddelandet återgår till den ursprungliga anroparen via en UDR. Routen använder 0.0.0.0/0 som adressprefix och virtuell enhet som typ av nästa hopp.
Alla arbetsbelastningsinitierade utgående anrop dirigeras av UDR till den privata IP-adressen för Azure Firewall.

Överväganden

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Några av följande överväganden är allmänna rekommendationer snarare än Azure Firewall specifik vägledning för att skydda ett AKS-kluster. Vi anser att dessa saker är viktiga krav för lösningen. Den här vägledningen gäller för överväganden för säkerhet, prestanda, tillgänglighet och tillförlitlighet, lagring, servicenät och övervakning.

Reliability

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

Överväg följande metoder för att optimera tillgängligheten för ditt AKS-kluster och dina arbetsbelastningar.

Resiliens inom en region

Under distributionen kan du konfigurera Azure Firewall så att den omfattar flera tillgänglighetszoner för ökad tillgänglighet. För drifttidsprocent, se Azure Firewall serviceavtal (SLA) i serviceavtal för Microsoft online služby. Du kan också associera Azure Firewall med en specifik zon för närhet. Den här konfigurationen påverkar dock serviceavtalet. Ingen extra kostnad gäller för en brandvägg som distribueras i en tillgänglighetszon, inklusive dataöverföringar mellan tillgänglighetszoner.
Överväg att distribuera nodpoolerna i ditt AKS-kluster i alla tillgänglighetszoner i en region. Använd en Azure lastbalanserare eller Application Gateway framför nodpoolerna. Den här topologin ger bättre återhämtning om det uppstår ett enda datacenterfel. Klusternoderna distribueras över flera datacenter i tre separata tillgänglighetszoner i en region.
Aktivera zonredundans i Container Registry för intraregionåterhämtning och hög tillgänglighet.
Använd begränsningar för poddtopologispridning för att styra hur poddar sprids över ditt AKS-kluster bland feldomäner som regioner, tillgänglighetszoner och noder.
Överväg att använda prisnivån Standard eller Premium för AKS-kluster som är värdar för verksamhetskritiska arbetsbelastningar. Dessa nivåer inkluderar ett ekonomiskt uppbackat SLA för klustrets tillgänglighet. Standardnivån garanterar 99,95% tillgänglighet för Kubernetes API-serverslutpunkten för kluster som använder tillgänglighetszoner eller 99,9% för kluster som inte använder tillgänglighetszoner. Premium-nivån ger samma SLA-garantier med extra långsiktigt stöd (LTS) för Kubernetes-versioner. Mer information finns i AKS-prisnivåer. AKS använder kontrollplansrepliker över uppdaterings- och feldomäner för att säkerställa att SLA-kraven uppfylls.
Överväg att använda AKS Automatisk SKU för nya kluster som drar nytta av en fullständigt hanterad nodhantering med inbyggda metodtips för tillförlitlighet, säkerhet och prestanda. AKS Automatic använder standardprisnivån som standard.

Affärskontinuitet och haveriberedskap

Överväg att distribuera din lösning till minst två kopplade Azure-regioner inom ett geografiskt område. Använd en global lastbalanserare, till exempel Azure Traffic Manager eller Azure Front Door, med en aktiv-aktiv eller aktiv-passiv routningsmetod, för att garantera affärskontinuitet och haveriberedskap (BC/DR).
Azure Firewall är en regional tjänst. Om du distribuerar lösningen i två eller flera regioner måste du skapa en Azure Firewall i varje region. Du kan skapa en global Azure Firewall Policy för att inkludera regler med organisations mandat som gäller för alla regionala hubbar. Du kan använda den här principen som en överordnad princip för regionala Azure-principer. Policys som skapats med icke-tomma överordnade policys ärver alla regeluppsättningar från den överordnade policyn. Nätverksregelsamlingar som ärvs från en överordnad princip prioriteras alltid ovanför nätverksregelsamlingar som definieras som en del av en ny princip. Samma logik gäller för programregelsamlingar. Nätverksregelsamlingar bearbetas dock alltid före programregelsamlingar, oavsett arv. Mer information om Standard- och Premium-principer finns i Azure Firewall Manager principöversikt.
Skriv skript för, dokumentera och testa regelbundet er process för regional redundansväxling i en QA-miljö. Den här testningen hjälper dig att undvika oförutsägbara problem om ett avbrott påverkar en kärntjänst i den primära regionen. Dessa tester verifierar också om DR-metoden uppfyller RPO- och RTO-målen samt vilka manuella steg eller operatörsingripanden som krävs under en felväxling.
Testa redundansprocedurer för att verifiera att de fungerar som förväntat.
Lagra dina containeravbildningar i Container Registry. Geo-replikera registret till alla AKS-regioner. För mer information, se Geo-replikering i Container Registry.
När en regional replik blir försämrad omdirigerar Container Registry automatiskt hämtningar via sin globala slutpunkt (<registry>.azurecr.io) till en fungerande replik. Den här redundansväxlingen sker internt inom några minuter och kräver inga ändringar i AKS-sidan eller DNS-konfigurationen.
Undvik om möjligt att lagra servicetillståndet i containern. Använd i stället en Azure PaaS som stöder replikering i flera regioner.
Om du använder Storage förbereder och testar du en process för att migrera ditt lagringsutrymme från den primära regionen till säkerhetskopieringsregionen.

Security

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

Den Azure plattformen ger skydd mot olika hot, till exempel nätverksintrång och DDoS-attacker. Använd en brandvägg för webbprogram (WAF) för att skydda alla AKS-värdbaserade webbprogram och -tjänster som exponerar en offentlig HTTPS-slutpunkt. Du måste skydda dig mot vanliga hot som SQL-inmatning, skript för flera webbplatser och andra webbexploateringar. Använd OWASP-regler (Open Web Application Security Project) och anpassade regler för detta ändamål. Azure Web Application Firewall tillhandahåller centraliserat skydd för dina webbapplikationer mot vanliga angrepp och sårbarheter. Du kan distribuera Azure Web Application Firewall med Azure Application Gateway, Azure Front Door och Azure Content Delivery Network.

DDoS-attacker är bland de största tillgänglighets- och säkerhetsproblemen för organisationer som flyttar sina program till molnet. En DDoS-attack försöker uttömma ett programs resurser, vilket gör programmet otillgängligt för legitima användare. DDoS-attacker kan riktas mot alla slutpunkter som kan nås offentligt via Internet. Varje egenskap i Azure omfattar skydd via Azure DDoS-infrastrukturskydd utan extra kostnad. Skalan och kapaciteten i det globalt distribuerade Azure-nätverket ger skydd mot vanliga attacker på nätverksnivå genom alltid aktiv trafikövervakning och riskreducering i realtid. DDoS-infrastrukturskydd kräver ingen användarkonfiguration eller programändringar. Det hjälper till att skydda alla Azure-tjänster, inklusive PaaS-tjänster som Azure DNS.

Azure DDoS Network Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Aktivera DDoS-nätverksskydd i virtuella perimeternätverk.

Andra säkerhetsöverväganden är:

Skapa en privat slutpunkt för alla PaaS-tjänster som AKS-arbetsbelastningar använder, till exempel Key Vault, Azure Service Bus och Azure SQL Database. Trafik mellan programmen och dessa tjänster exponeras inte för det offentliga Internet. Trafik mellan det virtuella nätverket för AKS-klustret och en instans av en PaaS-tjänst via en privat slutpunkt går via Microsofts stamnät, men kommunikationen går inte via Azure Firewall. Den här mekanismen ger bättre säkerhet och bättre skydd mot dataläckage. Mer information finns i Private Link.
När du använder Application Gateway framför AKS-klustret använder du en Web Application Firewall princip för att skydda offentliga arbetsbelastningar som körs på AKS från attacker.
Använd nätverksprinciper för att separera och skydda intratjänstkommunikation. Kontrollera vilka komponenter som kan kommunicera med varandra. Som standard kan alla poddar i ett Kubernetes-kluster skicka och ta emot trafik utan begränsningar. Använd Azure CNI som drivs av Cilium för att tillämpa nätverksprinciper. Calico stöds också om du behöver det för kompatibilitet med befintliga verktyg. Mer information finns i Nätverksprinciper i AKS.
Exponera inte fjärranslutning till dina AKS-noder. Skapa en bastionvärd eller en jump box i ett hanteringsnätverk för virtuella miljöer. Använd bastion host för att routa trafik till ditt AKS-kluster.
Överväg att använda ett privat AKS-kluster i produktionsmiljön, eller åtminstone säker åtkomst till API-servern med hjälp av auktoriserade IP-adressintervall i AKS. När du använder auktoriserade IP-adressintervall i ett offentligt kluster tillåter du alla utgående IP-adresser i Azure Firewall-nätverksregelsamlingen. I klusterdrift konsumerar Kubernetes API-servern.
Om du aktiverar DNS-proxy i Azure Firewall kan Azure Firewall bearbeta och vidarebefordra DNS-frågor från ett eller flera virtuella nätverk till en DNS-server som du väljer. Den här funktionen är avgörande och krävs för tillförlitlig FQDN-filtrering i nätverksregler. Du kan aktivera DNS-proxy i inställningarna för Azure-brandvägg och Brandväggspolicy. Mer information om DNS-proxyloggar finns i Azure Firewall-loggar och mätvärden.
Du kan använda Azure Firewall framför en GATEWAY API-baserad ingresskontrollant för att exponera arbetsbelastningar via HTTPS och använda en separat underdomän och ett certifikat för varje program. De rekommenderade hanterade ingresslösningarna för AKS är Application Gateway for Containers och Gateway API-implementeringen för programdirigering. Application Gateway for Containers är en fullständigt hanterad Azure inbyggd layer-7-lastbalanserare utanför klustret som stöder Kubernetes Gateway API och värdtjänster för flera platser. Implementeringen av Gateway API för programroutning använder ett Istio-baserat kontrollplan för att tillhandahålla trafikdirigering inom klustret via Kubernetes-resurserna Gateway och HTTPRoute. Använd inte AGIC för nya distributioner.
Du kan använda Azure Firewall framför en GATEWAY API-baserad ingresskontrollant för att exponera arbetsbelastningar via HTTPS och använda en separat underdomän och ett certifikat för varje program. De rekommenderade hanterade ingresslösningarna för AKS är Application Gateway for Containers och Gateway API-implementeringen för programroutning. Application Gateway for Containers är en fullständigt hanterad Azure inbyggd layer-7-lastbalanserare utanför klustret som stöder Kubernetes Gateway API och värdtjänster för flera platser. Implementeringen av Gateway API för applikationsroutning använder en Istio-baserad kontrollplan för att tillhandahålla trafikdirigering inom klustret via Kubernetes-resurserna Gateway och HTTPRoute. Använd inte AGIC för nya distributioner.
Konfigurera TLS-avslutning vid den valda ingressen. Information om TLS med Application Gateway för containrar finns i TLS-principen med Application Gateway för containrar. Information om TLS med programroutning finns i Säker ingress med hjälp av implementeringen av gateway-API:et för programroutning. Du kan också använda cert-manager för att automatiskt generera TLS-certifikat med Let's Encrypt.
Strikt samordning mellan Azure Firewall-operatören och klustret och arbetsbelastningsteamen är nödvändiga för den inledande klusterdistributionen och för pågående åtgärder när arbetsbelastnings- och klusterbehoven utvecklas. Den här samordningen är särskilt viktig när du konfigurerar autentiseringsmekanismerna, till exempel OAuth 2.0 och OpenID Connect, som arbetsbelastningar använder för att autentisera sina klienter.
Använd följande riktlinjer för att skydda miljön som beskrivs i den här artikeln:

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

Kostnaden för den resulterande arkitekturen beror på följande konfigurationsinformation:

Tjänstnivåer
Skalbarhet (antalet instanser som tjänster dynamiskt allokerar för att stödja en viss efterfrågan)
Automatiseringsskript
Din DR-nivå

När du har utvärderat konfigurationsinformationen använder du priskalkylatorn Azure för att beräkna dina kostnader.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

DevOps

Distribuera dina arbetsbelastningar till AKS med hjälp av ett Helm-diagram i en CI/CD-pipeline. Använd ett DevOps-system som GitHub Actions eller Azure DevOps. Mer information finns i Skapa och distribuera till AKS.
Testa ett program korrekt innan du gör det tillgängligt för användare med hjälp av A/B-testning och kanariedistributioner i programmets livscykelhantering. Du kan använda flera tekniker för att dela upp trafiken mellan olika versioner av samma tjänst. Du kan också använda de funktioner för trafikdelning som en tjänstnätimplementering tillhandahåller. Mer information finns i Trafikhantering i Istio.
Använd Azure Container Registry eller ett annat containerregister (som Docker Hub) för att lagra privata Docker-avbildningar som distribueras till klustret. AKS kan autentisera med Azure Container Registry med hjälp av dess Microsoft Entra-identitet.
Testa ingress och utgående trafik på dina arbetsbelastningar i en separat förproduktionsmiljö som speglar nätverkstopologin och brandväggsreglerna i produktionsmiljön. En stegvis distributionsstrategi hjälper dig att identifiera eventuella nätverk eller säkerhetsproblem innan du släpper en ny funktion eller nätverksregel i produktion.
Bestäm vilka Azure Firewall och routningsresurser som din IaC-pipeline (infrastruktur som kod) hanterar och vilka resurser nätverket eller säkerhetsoperatörerna hanterar utan band. Om du använder Terraform kan du använda metaargumentet livscykel med ignore_changes på resurserna Azure Firewall Policy och Azure Route Table. Med den här konfigurationen kan Terraform skapa och äga resurserna samtidigt som DNAT-, program- och nätverksregler för brandväggsprincipen och UDR:erna i routningstabellen kan hanteras utanför Terraform utan att återställas vid nästa tillämpning. Terraform-exempelmodulerna för det här scenariot använder det här mönstret.

Monitoring

Azure Firewall är helt integrerat med Azure Monitor för loggning av inkommande och utgående trafik som brandväggen bearbetar. Mer information finns i Hotinformationsbaserad filtrering i Azure Firewall.

Aktivera strukturerade loggar för Azure Firewall för detaljerad, schemabaserad loggning som förenklar frågor och analys. Strukturerade loggar ger insyn i trafikmönster, regelträffar, hotinformationsåtgärder och IDPS-signaler (intrångsidentifiering och skyddssystem) i ett format som integreras med Azure Monitor Log Analytics, Microsoft Sentinel och icke-Microsoft SIEM-verktyg.
Använd Kubernetes-övervakning i Azure Monitor för att övervaka hälsotillståndet för AKS-klustret och arbetsbelastningarna.
Konfigurera alla PaaS-tjänster (till exempel Container Registry och Key Vault) för att samla in diagnostikloggar och mått.

Contributors

Microsoft ansvarar för den här artikeln. Följande bidragsgivare skrev den här texten ursprungligen.

Huvudförfattare:

Paolo Salvatori | Huvudtjänsttekniker

Övriga medarbetare:

Sam Cogan | Senior Cloud Solution Architect

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

Well-Architected Framework-tjänstguide för AKS

Feedback

Var den här sidan till hjälp?

Last updated on 2026-06-23