Best practices voor netwerkverbinding en -beveiliging in Azure Kubernetes Service (AKS)

  • Artikel

Wanneer u clusters in Azure Kubernetes Service (AKS) maakt en beheert, biedt u netwerkconnectiviteit voor uw knooppunten en toepassingen. Deze netwerkresources omvatten IP-adresbereiken, load balancers en toegangsbeheerobjectcontrollers.

Dit artikel met aanbevolen procedures is gericht op netwerkconnectiviteit en -beveiliging voor clusteroperators. In dit artikel leert u het volgende:

  • Vergelijk de netwerkmodi kubenet en Azure Container Networking Interface (CNI) in AKS.
  • Plan de vereiste IP-adressering en connectiviteit.
  • Verkeer distribueren met behulp van load balancers, ingangscontrollers of een Web Application Firewall (WAF).
  • Maak veilig verbinding met clusterknooppunten.

Het juiste netwerkmodel kiezen

Richtlijnen voor best practices

Gebruik Azure CNI-netwerken in AKS voor integratie met bestaande virtuele netwerken of on-premises netwerken. Met dit netwerkmodel kunt u resources en besturingselementen in een bedrijfsomgeving beter scheiden.

Virtuele netwerken bieden de basisconnectiviteit voor AKS-knooppunten en klanten voor toegang tot uw toepassingen. Er zijn twee verschillende manieren om AKS-clusters te implementeren in virtuele netwerken:

  • Azure CNI-netwerken: wordt geïmplementeerd in een virtueel netwerk en maakt gebruik van de Azure CNI Kubernetes-invoegtoepassing. Pods ontvangen afzonderlijke IP-adressen die kunnen worden gerouteerd naar andere netwerkservices of on-premises resources.
  • Kubenet-netwerken: Azure beheert de virtuele netwerkresources wanneer het cluster wordt geïmplementeerd en maakt gebruik van de Kubenet Kubernetes-invoegtoepassing.

Azure CNI en kubenet zijn beide geldige opties voor productie-implementaties.

CNI-netwerken

Azure CNI is een leverancierneutraal protocol waarmee de containerruntime aanvragen kan indienen bij een netwerkprovider. Hiermee worden IP-adressen toegewezen aan pods en knooppunten en worden IPAM-functies (IP-adresbeheer) geboden wanneer u verbinding maakt met bestaande virtuele Azure-netwerken. Elke knooppunt- en podresource ontvangt een IP-adres in het virtuele Azure-netwerk. Er is geen extra routering nodig om te communiceren met andere resources of services.

Diagram met twee knooppunten met bruggen die elk verbinden met één Azure-VNet

Met name Azure CNI-netwerken voor productie maken scheiding van controle en beheer van resources mogelijk. Vanuit beveiligingsperspectief wilt u vaak dat verschillende teams deze resources beheren en beveiligen. Met Azure CNI-netwerken maakt u rechtstreeks verbinding met bestaande Azure-resources, on-premises resources of andere services via IP-adressen die aan elke pod zijn toegewezen.

Wanneer u Azure CNI-netwerken gebruikt, bevindt de resource van het virtuele netwerk zich in een afzonderlijke resourcegroep voor het AKS-cluster. Machtigingen voor de AKS-clusteridentiteit delegeren voor toegang tot en beheer van deze resources. De clusteridentiteit die door het AKS-cluster wordt gebruikt, moet ten minste machtigingen voor netwerkbijdrager hebben voor het subnet binnen uw virtuele netwerk.

Als u een aangepaste rol wilt definiëren in plaats van de ingebouwde rol Netwerkbijdrager te gebruiken, zijn de volgende machtigingen vereist:

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

AKS maakt standaard gebruik van een beheerde identiteit voor de clusteridentiteit. U kunt echter in plaats daarvan een service-principal gebruiken.

Wanneer elk knooppunt en elke pod een eigen IP-adres ontvangt, plant u de adresbereiken voor de AKS-subnetten. Houd rekening met de volgende criteria:

  • Het subnet moet groot genoeg zijn om IP-adressen op te geven voor elk knooppunt, elke pod en de netwerkresource die u implementeert.
    • Met zowel kubenet- als Azure CNI-netwerken heeft elk actief knooppunt standaardlimieten voor het aantal pods.
  • Vermijd het gebruik van IP-adresbereiken die overlappen met bestaande netwerkbronnen.
    • Het is nodig om connectiviteit met on-premises of gekoppelde netwerken in Azure toe te staan.
  • Voor het afhandelen van uitschaalgebeurtenissen of clusterupgrades hebt u extra IP-adressen nodig die beschikbaar zijn in het toegewezen subnet.
    • Deze extra adresruimte is vooral belangrijk als u Windows Server-containers gebruikt, omdat deze knooppuntgroepen een upgrade vereisen om de nieuwste beveiligingspatches toe te passen. Zie Een knooppuntgroep upgraden in AKS voor meer informatie over Windows Server-knooppunten.

Zie Azure CNI-netwerken configureren in AKS om het vereiste IP-adres te berekenen.

Wanneer u een cluster maakt met Azure CNI-netwerken, geeft u andere adresbereiken op voor het cluster, zoals het Docker-brugadres, het IP-adres van de DNS-service en het serviceadresbereik. In het algemeen moet u ervoor zorgen dat deze adresbereiken elkaar niet overlappen of netwerken die zijn gekoppeld aan het cluster, met inbegrip van virtuele netwerken, subnetten, on-premises en gekoppelde netwerken.

Zie Azure CNI-netwerken configureren in AKS voor meer informatie over limieten en grootten voor deze adresbereiken.

Kubenet-netwerken

Hoewel kubenet niet vereist dat u de virtuele netwerken configureert voordat u het cluster implementeert, zijn er nadelen voor wachten, zoals:

  • Omdat knooppunten en pods op verschillende IP-subnetten worden geplaatst, routeert door de gebruiker gedefinieerde routering (UDR) en DOORsturen via IP verkeer tussen pods en knooppunten. Deze extra routering kan de netwerkprestaties verminderen.
  • Verbinding maken van bestaande on-premises netwerken of peering naar andere virtuele Azure-netwerken kan complex zijn.

Omdat u het virtuele netwerk en subnetten niet afzonderlijk van het AKS-cluster maakt, is Kubenet ideaal voor de volgende scenario's:

  • Kleine ontwikkel- of testworkloads.
  • Eenvoudige websites met weinig verkeer.
  • Werkbelastingen tillen en verplaatsen naar containers.

Voor productie-implementaties zijn zowel kubenet als Azure CNI geldige opties. Omgevingen waarvoor scheiding van controle en beheer is vereist, kan Azure CNI de voorkeursoptie hebben. Daarnaast is kubenet alleen geschikt voor Linux-omgevingen waarbij het behoud van IP-adresbereik een prioriteit is.

U kunt ook uw eigen IP-adresbereiken en virtuele netwerken configureren met behulp van kubenet. Net als Azure CNI-netwerken mogen deze adresbereiken elkaar niet overlappen of mogen ze geen netwerken overlappen die zijn gekoppeld aan het cluster (virtuele netwerken, subnetten, on-premises en gekoppelde netwerken).

Zie Kubenet-netwerken gebruiken met uw eigen IP-adresbereiken in AKS voor meer informatie over limieten en grootten voor deze adresbereiken.

Inkomend verkeer distribueren

Richtlijnen voor best practices

Als u HTTP- of HTTPS-verkeer naar uw toepassingen wilt distribueren, gebruikt u toegangsbeheerobjectbronnen en -controllers. In vergelijking met een Azure Load Balancer bieden toegangsbeheerobjectcontrollers extra functies en kunnen ze worden beheerd als systeemeigen Kubernetes-resources.

Hoewel een Azure Load Balancer klantverkeer kan distribueren naar toepassingen in uw AKS-cluster, is het beperkt om te begrijpen dat verkeer. Een load balancer-resource werkt op laag 4 en distribueert verkeer op basis van protocol of poorten.

De meeste webtoepassingen die GEBRUIKMAKEN van HTTP of HTTPS, moeten gebruikmaken van kubernetes-toegangsbeheerbronnen en -controllers, die op laag 7 werken. Inkomend verkeer kan worden gedistribueerd op basis van de URL van de toepassing en TLS/SSL-beëindiging verwerken. Inkomend verkeer vermindert ook het aantal IP-adressen dat u beschikbaar maakt en toe wijst.

Met een load balancer heeft elke toepassing doorgaans een openbaar IP-adres nodig dat is toegewezen en toegewezen aan de service in het AKS-cluster. Met een toegangsbeheerobjectresource kan één IP-adres verkeer distribueren naar meerdere toepassingen.

Diagram van inkomend verkeer in een AKS-cluster

Er zijn twee onderdelen voor inkomend verkeer:

  1. Een toegangsbeheerobjectresource
  2. Een ingangscontroller

Toegangsbeheerresource

De toegangsbeheerobjectresource is een YAML-manifest van kind: Ingress. Hiermee definieert u de host, certificaten en regels voor het routeren van verkeer naar services die worden uitgevoerd in uw AKS-cluster.

In het volgende voorbeeld van het YAML-manifest wordt verkeer voor myapp.com gedistribueerd naar een van de twee services, blogservice of storeservice, en wordt de klant doorgestuurd naar de ene service of de andere op basis van de URL die ze openen.

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

Toegangscontroller

Een ingangscontroller is een daemon die wordt uitgevoerd op een AKS-knooppunt en controleert op binnenkomende aanvragen. Verkeer wordt vervolgens gedistribueerd op basis van de regels die zijn gedefinieerd in de toegangsbeheerobjectresource. Hoewel de meest voorkomende ingangscontroller is gebaseerd op NGINX, beperkt AKS u niet tot een specifieke controller. U kunt Contour, HAProxy, Traefik, etc. gebruiken.

Toegangsbeheerobjectcontrollers moeten worden gepland op een Linux-knooppunt. Geef aan dat de resource moet worden uitgevoerd op een Linux-knooppunt met behulp van een knooppuntkiezer in uw YAML-manifest of helm-grafiekimplementatie. Zie Knooppuntkiezers gebruiken om te bepalen waar pods worden gepland in AKS voor meer informatie.

Inkomend verkeer met de invoegtoepassing voor toepassingsroutering

De invoegtoepassing voor toepassingsroutering is de aanbevolen manier om een ingangscontroller in AKS te configureren. De invoegtoepassing voor toepassingsroutering is een volledig beheerde controller voor inkomend verkeer voor Azure Kubernetes Service (AKS) die de volgende functies biedt:

  • Eenvoudige configuratie van beheerde NGINX-ingangscontrollers op basis van kubernetes NGINX-ingangscontroller.

  • Integratie met Azure DNS voor beheer van openbare en privézones.

  • SSL-beëindiging met certificaten die zijn opgeslagen in Azure Key Vault.

Zie Beheerde NGINX-ingangen met de invoegtoepassing voor toepassingsroutering voor meer informatie over de invoegtoepassing voor toepassingsroutering.

Verkeer beveiligen met een Web Application Firewall (WAF)

Richtlijnen voor best practices

Als u binnenkomend verkeer wilt scannen op mogelijke aanvallen, gebruikt u een Web Application Firewall (WAF), zoals Barracuda WAF voor Azure of Azure-toepassing Gateway. Deze geavanceerdere netwerkresources kunnen ook verkeer routeren buiten alleen HTTP- en HTTPS-verbindingen of eenvoudige TLS-beëindiging.

Normaal gesproken is een toegangsbeheerobjectcontroller een Kubernetes-resource in uw AKS-cluster die verkeer naar services en toepassingen distribueert. De controller wordt uitgevoerd als een daemon op een AKS-knooppunt en verbruikt enkele van de resources van het knooppunt, zoals CPU, geheugen en netwerkbandbreedte. In grotere omgevingen kunt u rekening houden met het volgende:

  • Offload een deel van deze verkeersroutering of TLS-beëindiging naar een netwerkresource buiten het AKS-cluster.
  • Scan binnenkomend verkeer op mogelijke aanvallen.

Een WAF (Web Application Firewall) zoals Azure-app Gateway kan verkeer voor uw AKS-cluster beveiligen en distribueren

Voor die extra beveiligingslaag filtert een Web Application Firewall (WAF) het binnenkomende verkeer. Met een set regels kijkt het Open Web Application Security Project (OWASP) naar aanvallen zoals cross-site scripting of cookievergiftiging. Azure-toepassing Gateway (momenteel in preview in AKS) is een WAF die kan worden geïntegreerd met AKS-clusters, waarbij deze beveiligingsfuncties worden vergrendeld voordat het verkeer uw AKS-cluster en toepassingen bereikt.

Aangezien andere oplossingen van derden deze functies ook uitvoeren, kunt u bestaande investeringen of expertise blijven gebruiken in uw favoriete product.

Load balancer- of inkomend verkeersmiddelen worden voortdurend uitgevoerd in uw AKS-cluster en verfijnen de verkeersdistributie. App Gateway kan centraal worden beheerd als een ingangscontroller met een resourcedefinitie. Maak een controller voor inkomend verkeer van Application Gateway om aan de slag te gaan.

Verkeersstroom beheren met netwerkbeleid

Richtlijnen voor best practices

Gebruik netwerkbeleid om verkeer naar pods toe te staan of te weigeren. Standaard is al het verkeer tussen pods binnen een cluster toegestaan. Definieer voor verbeterde beveiliging regels die de communicatie van pods beperken.

Netwerkbeleid is een Kubernetes-functie die beschikbaar is in AKS waarmee u de verkeersstroom tussen pods kunt beheren. U staat verkeer naar de pod toe of weigert op basis van instellingen zoals toegewezen labels, naamruimte of verkeerspoort. Netwerkbeleid is een cloudeigen manier om de verkeersstroom voor pods te beheren. Omdat pods dynamisch worden gemaakt in een AKS-cluster, kunnen vereiste netwerkbeleidsregels automatisch worden toegepast.

Als u netwerkbeleid wilt gebruiken, schakelt u de functie in wanneer u een nieuw AKS-cluster maakt. U kunt geen netwerkbeleid inschakelen voor een bestaand AKS-cluster. Plan vooruit om netwerkbeleid in te schakelen voor de benodigde clusters.

Notitie

Netwerkbeleid mag alleen worden gebruikt voor Linux-knooppunten en pods in AKS.

U maakt een netwerkbeleid als een Kubernetes-resource met behulp van een YAML-manifest. Beleidsregels worden toegepast op gedefinieerde pods, met regels voor inkomend of uitgaand verkeer die de verkeersstroom definiëren.

In het volgende voorbeeld wordt een netwerkbeleid toegepast op pods met de app: back-endlabel toegepast op pods. Met de regel voor inkomend verkeer is alleen verkeer van pods met de app toegestaan: front-endlabel .

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

Zie Verkeer tussen pods beveiligen met behulp van netwerkbeleid in Azure Kubernetes Service (AKS) om aan de slag te gaan met beleid.

Veilig verbinding maken met knooppunten via een bastionhost

Richtlijnen voor best practices

Maak geen externe connectiviteit beschikbaar voor uw AKS-knooppunten. Maak een bastionhost of jumpbox in een virtueel beheernetwerk. Gebruik de bastionhost om verkeer veilig naar uw AKS-cluster te routeren naar externe beheertaken.

U kunt de meeste bewerkingen in AKS voltooien met behulp van de Azure-beheerhulpprogramma's of via de Kubernetes API-server. AKS-knooppunten zijn alleen beschikbaar in een particulier netwerk en zijn niet verbonden met het openbare internet. Als u verbinding wilt maken met knooppunten en onderhoud en ondersteuning wilt bieden, routeert u uw verbindingen via een bastionhost of jumpbox. Controleer of deze host zich in een afzonderlijk, veilig gekoppeld virtueel beheernetwerk bevindt aan het virtuele netwerk van het AKS-cluster.

Verbinding maken naar AKS-knooppunten met behulp van een bastionhost of jump box

U moet ook het beheernetwerk voor de bastionhost beveiligen. Gebruik een Azure ExpressRoute - of VPN-gateway om verbinding te maken met een on-premises netwerk en toegang te beheren met behulp van netwerkbeveiligingsgroepen.

Volgende stappen

Dit artikel is gericht op netwerkconnectiviteit en -beveiliging. Zie Netwerkconcepten voor toepassingen in Azure Kubernetes Service (AKS) voor meer informatie over de basisbeginselen van netwerken in Kubernetes