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

Artikel
03/18/2024

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 kan du se hur du:

Jämför nätverkslägena kubenet och Azure Container Networking Interface (CNI) i AKS.
Planera för nödvändig IP-adressering och anslutning.
Distribuera trafik med lastbalanserare, inkommande styrenheter eller en brandvägg för webbprogram (WAF).
Anslut säkert till klusternoder.

Välj lämplig nätverksmodell

Vägledning för bästa praxis

Använd Azure CNI-nätverk i AKS för integrering med befintliga virtuella nätverk eller lokala nätverk. Den här nätverksmodellen möjliggör större uppdelning av resurser och kontroller i en företagsmiljö.

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:

Azure CNI-nätverk: Distribuerar till ett virtuellt nätverk och använder plugin-programmet Azure CNI Kubernetes. Poddar tar emot enskilda IP-adresser som kan dirigeras till andra nätverkstjänster eller lokala resurser.
Kubenet-nätverk: Azure hanterar de virtuella nätverksresurserna när klustret distribueras och använder kubenet Kubernetes-plugin-programmet.

Azure CNI och kubenet är båda giltiga alternativ för produktionsdistributioner.

CNI-nätverk

Azure CNI är ett leverantörsneutralt protokoll som låter containerkörningen göra begäranden till en nätverksprovider. Den tilldelar IP-adresser till poddar och noder och tillhandahåller IPAM-funktioner (IPAM) när du ansluter till befintliga virtuella Azure-nätverk. Varje nod och poddresurs tar emot en IP-adress i det virtuella Azure-nätverket. Det finns inget behov av extra routning för att kommunicera med andra resurser eller tjänster.

Diagram som visar två noder med bryggor som ansluter var och en till ett enda virtuellt Azure-nätverk

I synnerhet möjliggör Azure CNI-nätverk för produktion separation av kontroll och hantering av resurser. Ur ett säkerhetsperspektiv vill du ofta att olika team ska hantera och skydda dessa resurser. Med Azure CNI-nätverk ansluter du till befintliga Azure-resurser, lokala resurser eller andra tjänster direkt via IP-adresser som tilldelats till varje podd.

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 behörighet som nätverksdeltagare i undernätet i det virtuella nätverket.

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:

Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/read

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

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

När varje nod och podd tar emot sin egen IP-adress planerar du adressintervallen för AKS-undernäten. Tänk på följande kriterier:

Undernätet måste vara tillräckligt stort för att tillhandahålla IP-adresser för varje nod, podd och nätverksresurs som du distribuerar.
- Med både kubenet- och Azure CNI-nätverk har varje nod som körs standardgränser för antalet poddar.
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 skalbara hä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 den IP-adress som krävs finns i Konfigurera Azure CNI-nätverk i AKS.

När du skapar ett kluster med Azure CNI-nätverk anger du andra adressintervall för klustret, till exempel Docker-bryggadressen, DNS-tjänstens IP-adressintervall och tjänstadressintervall. I allmänhet kontrollerar du 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.

Specifik information om gränser och storleksändring för dessa adressintervall finns i Konfigurera Azure CNI-nätverk i AKS.

Kubenet-nätverk

Kubenet kräver inte att du konfigurerar de virtuella nätverken innan du distribuerar klustret, men det finns nackdelar med att vänta, till exempel:

Eftersom noder och poddar placeras i olika IP-undernät dirigerar UDR (Användardefinierad routning) och IP-vidarebefordran trafik mellan poddar och noder. Den här extra routningen kan minska nätverksprestandan.
Anslut till befintliga lokala nätverk eller peering till andra virtuella Azure-nätverk kan vara komplexa.

Eftersom du inte skapar det virtuella nätverket och undernäten separat från AKS-klustret är Kubenet perfekt för följande scenarier:

Små utvecklings- eller testarbetsbelastningar.
Enkla webbplatser med låg trafik.
Lyfta och flytta arbetsbelastningar till containrar.

För produktionsdistributioner är både kubenet och Azure CNI giltiga alternativ. Miljöer som kräver separation av kontroll och hantering kan Azure CNI vara det bästa alternativet. Dessutom passar kubenet endast för Linux-miljöer där bevarande av IP-adressintervall är en prioritet.

Du kan också konfigurera dina egna IP-adressintervall och virtuella nätverk med kubenet. Precis som Azure CNI-nätverk bör dessa adressintervall inte överlappa varandra eller nätverk som är associerade med klustret (virtuella nätverk, undernät, lokala och peerkopplade nätverk).

Specifik information om gränser och storleksändring för dessa adressintervall finns i Använda kubenet-nätverk med dina egna IP-adressintervall i AKS.

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 att förstå 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. Inkommande kan distribuera trafik baserat på programmets URL och hantera TLS/SSL-avslutning. 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.

Diagram som visar inkommande trafikflöde i ett AKS-kluster

Det finns två komponenter för ingress:

En ingressresurs
En ingresskontrollant

Ingressresurs

Ingressresursen är ett YAML-manifest för kind: Ingress. Den definierar värden, certifikaten och reglerna för att dirigera trafik till tjänster som körs i AKS-klustret.

I följande exempel distribuerar YAML-manifestet trafik för myapp.com till någon av två tjänster, bloggtjänst eller storeservice, 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: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

Ingångskontrollant

En ingresskontrollant är en daemon som körs på en AKS-nod och som bevakar inkommande begäranden. Trafiken distribueras sedan baserat på de regler som definierats i ingressresursen. Den vanligaste ingresskontrollanten är baserad på NGINX, men AKS begränsar dig inte till en specifik kontrollant. Du kan använda Contour, HAProxy, Traefik osv.

Ingresskontrollanter måste schemaläggas 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 är det rekommenderade sättet att konfigurera en ingresskontrollant i AKS. Tillägget för programroutning är en fullständigt hanterad inkommande kontrollant för Azure Kubernetes Service (AKS) som tillhandahå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 om tillägget för programroutning finns i 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 söka igenom inkommande trafik efter potentiella attacker använder du en brandvägg för webbprogram (WAF) som Barracuda WAF för Azure eller Azure Application Gateway. Dessa mer avancerade nätverksresurser kan också dirigera trafik utöver bara HTTP- och HTTPS-anslutningar eller grundläggande TLS-avslutning.

Vanligtvis är en ingresskontrollant en Kubernetes-resurs i ditt AKS-kluster som distribuerar trafik till tjänster och program. Kontrollanten körs som en daemon på en AKS-nod och förbrukar vissa 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.

En brandvägg för webbprogram (WAF) som Azure App Gateway kan skydda och distribuera trafik för ditt AKS-kluster

För det extra säkerhetsskiktet filtrerar en brandvägg för webbprogram (WAF) inkommande trafik. Med en uppsättning regler bevakar OWASP (Open Web Application Security Project) attacker som skript för flera webbplatser eller cookieförgiftning. Azure Application Gateway (för närvarande i förhandsversion i AKS) är en WAF som integreras med AKS-kluster och låser in dessa säkerhetsfunktioner innan trafiken når aks-klustret och programmen.

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 inkommande resurser körs kontinuerligt i AKS-klustret och förfinar trafikfördelningen. App Gateway kan hanteras centralt som en ingresskontrollant med en resursdefinition. Kom igång genom att skapa en Application Gateway-ingresskontrollant.

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ätverksprincip aktiverar du funktionen när du skapar ett nytt AKS-kluster. Du kan inte aktivera nätverksprincip i ett befintligt AKS-kluster. Planera i förväg för att aktivera nätverksprincip i de kluster som behövs.

Kommentar

Nätverksprincip bör endast användas för Linux-baserade noder och poddar i AKS.

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ätverksprincip på poddar med appen: serverdelsetikett som tillämpas på dem. Ingressregeln tillåter endast trafik från poddar med appen: klientdelsetikett .

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 Skydda trafik mellan poddar med hjälp av nätverksprinciper i Azure Kubernetes Service (AKS).

Anslut säkert till noder via en skyddsvärd

Vägledning för bästa praxis

Exponera inte fjärranslutning till dina AKS-noder. Skapa en skyddsvärd eller en hoppruta i ett virtuellt hanteringsnätverk. Använd skyddsvärden för att på ett säkert sätt dirigera trafik till AKS-klustret till fjärrhanteringsuppgifter.

Du kan utföra de flesta åtgärder i AKS med hjälp av Azure-hanteringsverktygen eller via Kubernetes API-servern. AKS-noder är endast tillgängliga i ett privat nätverk och är inte anslutna till det offentliga Internet. Om du vill ansluta till noder och tillhandahålla underhåll och support dirigerar du dina anslutningar via en skyddsvärd eller en jump box. Kontrollera att den här värden finns i ett separat, säkert peer-kopplat virtuellt nätverk till det virtuella AKS-klustrets virtuella nätverk.

Anslut till AKS-noder med hjälp av en skyddsvärd eller jump box

Du bör också skydda hanteringsnätverket för skyddsvärden. Använd en Azure ExpressRoute - eller VPN-gateway för att ansluta till ett lokalt nätverk och styra åtkomsten med hjälp av 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)