Metodtips för nätverksanslutning och säkerhet i Azure Kubernetes Service (AKS)

När du skapar och hanterar kluster i Azure Kubernetes Service (AKS) tillhandahåller du nätverksanslutning för dina noder och program. Dessa nätverksresurser omfattar IP-adressintervall, lastbalanserare och ingresskontrollanter.

Den här artikeln om metodtips fokuserar på nätverksanslutning och säkerhet för klusteroperatorer. I den här artikeln lär du dig att:

Välj lämplig nätverksmodell

Vägledning för bästa praxis

Använd Azure CNI-överlägg för de flesta scenarier. Om arbetsbelastningar kräver direkt podd-IP-åtkomst från anslutna nätverk använder du ett platt nätverk med Azure CNI Pod-undernät.

Virtuella nätverk tillhandahåller den grundläggande anslutningen för AKS-noder och kunder för att få åtkomst till dina program. Det finns två olika sätt att distribuera AKS-kluster till virtuella nätverk:

• Överläggsnätverk: Azure CNI Overlay tilldelar podd-IP-adresser från en separat podd-CIDR. Trafik som lämnar klustret översätts till nodens IP-adress och poddar är inte direkt åtkomliga via sina privata IP-adresser från anslutna nätverk.
• Platt nätverk: Azure CNI Pod-undernät eller äldre Azure CNI Node-undernät tilldelar podd-IP-adresser från virtuellt nätverksutrymme. Poddar kan nås med sina privata IP-adresser från anslutna nätverk.

Mer information om hur du väljer en nätverksmodell finns i Planera poddnätverk för AKS.

översikt över Azure CNI-nätverk

Azure CNI tillhandahåller IP-adresshantering (IPAM) och anslutning för poddar och noder. IPAM-alternativet är separat från nätverksdataplanet. Du kan till exempel använda Azure CNI som drivs av Cilium med Azure CNI-överlägg eller ett alternativ för platt nätverk.

Följande diagram visar två AKS-noder som var och en är anslutna via en nätverksbrygga till ett delat Azure virtuellt nätverk.

Azure CNI-nätverk möjliggör separation av kontroll och hantering av resurser. Ur ett säkerhetsperspektiv vill du ofta att olika team ska hantera och skydda dessa resurser. Anslutningsegenskaperna beror på nätverksmodellen. Överläggspoddar initierar anslutningar till virtuella nätverk och lokala resurser via nodens IP-adress. Flat-network poddar kan kommunicera direkt med anslutna resurser via sina privata IP-adresser.

När du använder Azure CNI-nätverk finns den virtuella nätverksresursen i en separat resursgrupp till AKS-klustret. Delegera behörigheter för AKS-klusteridentiteten för att komma åt och hantera dessa resurser. Klusteridentiteten som används av AKS-klustret måste ha minst Nätverksmedverkande-behörighet på undernätet inom ditt virtuella nätverk.

Om du vill definiera en anpassad roll i stället för att använda den inbyggda rollen Nätverksdeltagare krävs följande behörigheter:

Som standard använder AKS en hanterad identitet för sin klusteridentitet. Du kan dock använda ett tjänsthuvudkonto i stället.

• Mer information om delegering av AKS-tjänstens huvudanvändarkonto finns i Delegera åtkomst till andra Azure-resurser.
• Mer information om hanterade identiteter finns i Använda hanterade identiteter.

Planera adressintervall baserat på nätverksmodellen. Tänk på följande kriterier:

• Med Azure CNI-överlägg, storleksanpassa nodundernätet för noder och använd en separat privat CIDR för poddar. Varje nod tar emot ett /24 adressutrymme från poddens CIDR.
• Med ett platt nätverk kan du ändra storleken på det virtuella nätverkets undernät för både noder och poddar. Azure CNI Pod Subnet använder separata noder och poddundernät, medan äldre Azure CNI-nodundernät använder ett undernät för båda.
• Undvik att använda IP-adressintervall som överlappar befintliga nätverksresurser.
  • Det är nödvändigt att tillåta anslutning till lokala eller peer-kopplade nätverk i Azure.
• För att hantera utskalningshändelser eller klusteruppgraderingar behöver du extra IP-adresser i det tilldelade undernätet.
  • Det här extra adressutrymmet är särskilt viktigt om du använder Windows Server containrar, eftersom dessa nodpooler kräver en uppgradering för att tillämpa de senaste säkerhetskorrigeringarna. Mer information om Windows Server noder finns i Uppgradera en nodpool i AKS.

Information om hur du beräknar det nödvändiga IP-adressutrymmet finns i IP-adressplanering för AKS-kluster.

När du skapar ett kluster med Azure CNI-nätverk anger du andra adressintervall för klustret, till exempel DNS-tjänstens IP-adressintervall och tjänstadressintervall. Se i allmänhet till att dessa adressintervall inte överlappar varandra eller nätverk som är associerade med klustret, inklusive virtuella nätverk, undernät, lokala nätverk och peer-kopplade nätverk.

Mer information om nätverksmodeller, gränser och adressstorlek finns i Azure översikt över CNI-nätverk.

Distribuera inkommande trafik

Vägledning för bästa praxis

Om du vill distribuera HTTP- eller HTTPS-trafik till dina program använder du inkommande resurser och kontrollanter. Jämfört med en Azure lastbalanserare ger ingresskontrollanter extra funktioner och kan hanteras som interna Kubernetes-resurser.

Även om en Azure lastbalanserare kan distribuera kundtrafik till program i ditt AKS-kluster är den begränsad i förståelsen av den trafiken. En lastbalanserarresurs fungerar på nivå 4 och distribuerar trafik baserat på protokoll eller portar.

De flesta webbprogram som använder HTTP eller HTTPS bör använda Kubernetes inkommande resurser och styrenheter, som fungerar på nivå 7. Ingress kan distribuera trafik baserat på applikationens URL och hantera TLS/SSL-terminering. Ingress minskar också antalet IP-adresser som du exponerar och mappar.

Med en lastbalanserare behöver varje program vanligtvis en offentlig IP-adress tilldelad och mappad till tjänsten i AKS-klustret. Med en ingressresurs kan en enskild IP-adress distribuera trafik till flera program.

Diagrammet visar en enda offentlig IP-adress som tar emot extern trafik och en inkommande kontrollant som distribuerar trafiken till flera tjänster i AKS-klustret.

Ingress har två komponenter: en ingressresurs och en ingresskontrollant.

Ingressresurs

Ingressresursen är ett YAML-manifest för kind: Ingress. Det definierar host, certifikaten och de regler som dirigerar trafik till tjänster som körs i ditt AKS-kluster.

I följande YAML-exempelmanifest används tillägget för programdirigering i den hanterade NGINX-ingressklassen. Den distribuerar trafik för myapp.com till en av två tjänster, bloggtjänst eller butikstjänst, och dirigerar kunden till en tjänst eller en annan baserat på den URL de kommer åt.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: myapp-ingress
spec:
  ingressClassName: webapprouting.kubernetes.azure.com
  tls:
  - hosts:
    - myapp.com
    secretName: myapp-secret
  rules:
  - host: myapp.com
    http:
      paths:
      - path: /blog
        pathType: Prefix
        backend:
          service:
            name: blogservice
            port:
              number: 80
      - path: /store
        pathType: Prefix
        backend:
          service:
            name: storeservice
            port:
              number: 80

Fältet ingressClassName väljer ingressklassen och måste matcha en klass som konfigurerats på en ingresskontrollant i klustret. Värdet webapprouting.kubernetes.azure.com väljer den hanterade NGINX-ingresskontrollanten som tillhandahålls av tillägget för programroutning. Ersätt den med klassnamnet för ingresskontrollanten om du använder en annan implementering.

Ingångskontrollant

En klusterbaserad ingress-styrenhet körs som en arbetslast på en AKS-nod och övervakar inkommande begäranden. Inkommande trafik distribueras sedan baserat på de regler som definierats i den ingressresurs som är associerad med styrenheten. Den vanligaste ingresskontrollanten är baserad på NGINX, men AKS begränsar dig inte till en specifik kontrollant. Du kan använda Application Gateway for Containers, Contour, HAProxy, Traefik, och andra.

Du måste schemalägga klusterhanterade ingresskontrollanter på en Linux-nod. Ange att resursen ska köras på en Linux-baserad nod med hjälp av en nodväljare i YAML-manifestet eller Helm-diagramdistributionen. Mer information finns i Använda nodväljare för att styra var poddar schemaläggs i AKS.

Ingress med tillägget för programroutning

Tillägget för programroutning tillhandahåller hanterade ingressimplementeringar för AKS. För nya, långvariga distributioner använder du implementeringen av gateway-API:et för programdirigering när den stöder dina krav. Gateway-API:et är den långsiktiga standarden för Kubernetes-ingress och Layer 7-trafikhantering.

Den hanterade NGINX-implementeringen innehåller följande funktioner:

• Enkel konfiguration av hanterade NGINX-ingresskontrollanter baserat på Kubernetes NGINX-ingresskontrollant.
• Integrering med Azure DNS för offentlig och privat zonhantering.
• SSL-avslutning med certifikat som lagras i Azure Key Vault.

Mer information finns i Konfigurera ingress med gateway-API:et för programroutning och hanterad NGINX-ingress med tillägget för programroutning.

Skydda trafik med en brandvägg för webbprogram (WAF)

Vägledning för bästa praxis

Om du vill skanna inkommande trafik efter potentiella attacker, använder du en brandvägg för webbapplikationer (WAF), till exempel Barracuda WAF för Azure eller Azure Web Application Firewall on Application Gateway for Containers. Application Gateway for Containers dirigerar HTTP, HTTPS, gRPC, WebSocket och AI-slutsatsdragningstrafik och stöder TLS-avslutning.

En klusterhanterad ingresskontrollant körs som en Kubernetes-arbetsbelastning i ditt AKS-kluster och distribuerar trafik till tjänster och program. Den förbrukar en del av nodens resurser, till exempel PROCESSOR, minne och nätverksbandbredd. I större miljöer kanske du vill överväga följande:

• Avlasta en del av den här trafikroutningen eller TLS-avslutningen till en nätverksresurs utanför AKS-klustret.
• Sök igenom inkommande trafik efter potentiella attacker.

Diagrammet visar extern trafik som passerar genom Azure Application Gateway för containrar. När WAF-skydd har konfigurerats filtrerar WAF-regler begäranden innan Application Gateway för containrar vidarebefordrar tillåten trafik till tjänster i AKS-klustret.

För det extra säkerhetsskiktet filtrerar en brandvägg för webbprogram (WAF) inkommande trafik. Hanterade och anpassade regler skyddar mot attacker som skript mellan platser och SQL-inmatning. Application Gateway för containrar är en layer 7-tjänst för belastningsutjämning och trafikhantering som stöder Azure WAF.

WAF-skydd aktiveras inte genom att endast distribuera Application Gateway för containrar. Du måste skapa en WAF-princip och slutföra båda följande konfigurationer innan WAF inspekterar trafiken:

• Skapa en Azure-SecurityPolicyunderresurs som refererar till WAF-policyn.
• Använd en anpassad Kubernetes-resurs WebApplicationFirewallPolicy som refererar till samma WAF-princip och som riktar sig mot resursen Gateway eller HTTPRoute som ska skyddas.

När du har slutfört båda konfigurationerna kontrollerar du den anpassade resursstatusen och WAF-loggarna innan du förlitar dig på principen för skydd. Mer information finns i Azure Web Application Firewall på Application Gateway for Containers.

Eftersom andra lösningar från tredje part även utför dessa funktioner kan du fortsätta att använda befintliga investeringar eller expertis inom önskad produkt.

Lastbalanserare eller ingress-resurser körs kontinuerligt i ditt AKS-kluster och förfinar trafikfördelningen. Azure Application Gateway för containrar kan hanteras centralt som en ingresskontrollant med en resursdefinition. Kom igång genom att skapa en Application Gateway för containrar och sedan konfigurera WAF-skydd separat.

Kontrollera trafikflödet med nätverksprinciper

Vägledning för bästa praxis

Använd nätverksprinciper för att tillåta eller neka trafik till poddar. Som standard tillåts all trafik mellan poddar i ett kluster. För förbättrad säkerhet definierar du regler som begränsar poddkommunikationen.

Nätverksprincip är en Kubernetes-funktion som är tillgänglig i AKS som gör att du kan styra trafikflödet mellan poddar. Du tillåter eller nekar trafik till podden baserat på inställningar som tilldelade etiketter, namnrymd eller trafikport. Nätverksprinciper är ett molnbaserat sätt att styra flödet av trafik för poddar. Eftersom poddar skapas dynamiskt i ett AKS-kluster kan nödvändiga nätverksprinciper tillämpas automatiskt.

Om du vill använda nätverksprinciper i AKS väljer du en nätverksprincipmotor som stöder nodoperativsystem och nätverksdataplan. Du kan aktivera en policymotor när du skapar klustret eller på ett befintligt kluster som stöds.

För Linux-nodpooler använder du Azure CNI som drivs av Cilium och dess inbyggda Cilium-nätverksprinciptillämpning. Cilium stöds inte för Windows nodpooler. Använd Calico för Windows arbetsbelastningar.

Du skapar en nätverksprincip som en Kubernetes-resurs med hjälp av ett YAML-manifest. Principer tillämpas på definierade poddar, med ingress- eller utgående regler som definierar trafikflödet.

I följande exempel tillämpas en nätverkspolicy på poddar på vilka etiketten app: backend tillämpas. Ingressregeln tillåter endast trafik från poddar med app: frontend etiketten.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

Information om hur du kommer igång med principer finns i Säkerhetstrafik mellan poddar med hjälp av nätverksprinciper i Azure Kubernetes Service (AKS).

Optimera DNS-upplösning med LocalDNS

Vägledning för bästa praxis

Använd LocalDNS för att förbättra DNS-prestanda och tillförlitlighet och minska belastningen på centraliserade CoreDNS-poddar. LocalDNS är förkonfigurerat i AKS Automatic. I AKS Standard aktiverar och konfigurerar du LocalDNS per nodpool.

LocalDNS distribuerar en DNS-proxy som en systemd tjänst på varje nod för att hantera DNS-frågor lokalt. Som standard skickar poddar alla DNS-frågor till centraliserade CoreDNS-poddar. I stor skala kan centralisering av dessa frågor skapa en flaskhals, medan lokal upplösning minskar nätverkshopp och svarstid.

LocalDNS eliminerar conntrack också tabellposter för DNS-trafik, vilket förhindrar conntrack tabellöverbelastning och konkurrensförhållanden som kan orsaka avbrutna anslutningar. Anslutningar från den lokala cachen till CoreDNS uppgraderas till TCP, vilket möjliggör ombalansering av anslutningar och snabbare rensning av spårningsposter.

För arbetsbelastningar som kräver hög DNS-tillgänglighet har LocalDNS stöd för att hantera inaktuella cachelagrade svar under en konfigurerbar varaktighet när överordnade DNS inte är tillgängligt. Den här bästa funktionen kan bidra till att upprätthålla poddanslutningen och tjänstens tillförlitlighet vid tillfälliga DNS-avbrott, men det garanterar inte att en inaktuell post är tillgänglig.

På AKS Standard innebär aktivering av LocalDNS på en befintlig nodpool att dess noder avbildas om. Planera distributionen för att ta hänsyn till den här störningen.

Mer information om LocalDNS-arkitektur och -funktioner finns i DNS-matchning i AKS. Konfigurationsinstruktioner finns i Konfigurera LocalDNS.

Anslut säkert till noder

Vägledning för bästa praxis

Exponera inte fjärranslutning till dina AKS-noder. För rutinmässig felsökning av Linux-noder använder du kubectl debug via Kubernetes-API:et. När du behöver SSH-åtkomst ansluter du via privata nätverk eller Azure Bastion.

Du kan utföra de flesta åtgärder i AKS med hjälp av Azure hanteringsverktyg eller Kubernetes API-servern. AKS-noder är endast tillgängliga i ett privat nätverk och är inte anslutna till det offentliga Internet. För Linux-noder använder du kubectl debug för att starta en privilegierad felsökningscontainer via Kubernetes-API:et. Den här metoden kräver inte direkt SSH-anslutning till noden.

Om Kubernetes API-åtkomst inte är lämplig eller om du behöver SSH använder du nodens privata IP-adress från ett anslutet nätverk. Azure Bastion kan tillhandahålla privat anslutning utan att exponera en offentlig IP-adress på noden. För Windows noder använder du en värdprocesscontainer eller ansluter via en Linux-proxynod. Azure Bastion är ett alternativ om proxynoden inte är tillgänglig. Mer information finns i Ansluta till AKS-klusternoder för underhåll eller felsökning.

Diagrammet visar ett virtuellt hanteringsnätverk som innehåller en Bastion-värd som dirigerar anslutningar via en säker peeringanslutning till det virtuella nätverket för AKS-klustret.

Om du använder en bastionvärd eller jump box, placerar du den i ett separat, säkert peer-kopplat virtuellt hanteringsnätverk. Skydda hanteringsnätverket med hjälp av Azure ExpressRoute eller en VPN-gateway för att ansluta till ett lokalt nätverk och styra åtkomsten med nätverkssäkerhetsgrupper.

Nästa steg

Den här artikeln fokuserar på nätverksanslutning och säkerhet. Mer information om nätverksgrunderna i Kubernetes finns i Nätverksbegrepp för program i Azure Kubernetes Service (AKS)