Aanbevolen procedures voor netwerkconnectiviteit en -beveiliging in Azure Kubernetes Service (AKS)

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

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

Het juiste netwerkmodel kiezen

Richtlijnen voor best practices

Gebruik Azure CNI-overlay voor de meeste scenario's. Als voor workloads directe IP-toegang tot pods vanuit verbonden netwerken is vereist, gebruikt u een plat netwerk met Azure CNI Pod Subnet.

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:

• Overlay-netwerk: Azure CNI Overlay wijst IP-adressen van pods toe vanuit een afzonderlijke pod-CIDR. Verkeer dat het cluster verlaat, wordt omgezet naar het IP-adres van het knooppunt en pods zijn niet rechtstreeks toegankelijk via hun privé-IP-adressen van verbonden netwerken.
• Plat netwerk: Azure CNI Pod Subnet of verouderd Azure CNI-knooppuntsubnet wijst pod-IP-adressen toe vanuit de ruimte van het virtuele netwerk. Pods kunnen worden bereikt door hun privé-IP-adressen vanuit verbonden netwerken.

Zie Podnetwerken voor AKS plannen voor meer informatie over het kiezen van een netwerkmodel.

Overzicht van Azure CNI-netwerken

Azure CNI biedt IP-adresbeheer (IPAM) en connectiviteit voor pods en knooppunten. De IPAM-optie staat los van het netwerkgegevensvlak. U kunt bijvoorbeeld Azure CNI aangedreven door Cilium gebruiken met Azure CNI-overlay of een optie voor plat netwerk.

In het volgende diagram ziet u twee AKS-knooppunten, die elk via een netwerkbrug zijn verbonden met een gedeeld Azure virtueel netwerk.

Met Azure CNI-netwerken kunnen de controle en het beheer van resources worden gescheiden. Vanuit beveiligingsperspectief wilt u vaak dat verschillende teams deze resources beheren en beveiligen. De connectiviteitskenmerken zijn afhankelijk van het netwerkmodel. Overlay-pods initiëren verbindingen met virtuele netwerken en on-premises resources via het IP-adres van het knooppunt. Platte netwerkpods kunnen rechtstreeks communiceren met verbonden resources via hun privé-IP-adressen.

Wanneer u Azure CNI-netwerken gebruikt, bevindt de virtuele netwerkresource 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:

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

• Zie Toegang tot andere Azure-resources voor meer informatie over de delegatie van AKS-service-principals.
• Zie Beheerde identiteiten gebruiken voor meer informatie over beheerde identiteiten.

Adresbereiken plannen op basis van het netwerkmodel. Houd rekening met de volgende criteria:

• Met Azure CNI-overlay kunt u het subnet van het knooppunt voor knooppunten aanpassen en een afzonderlijke privé-CIDR gebruiken voor pods. Elk knooppunt ontvangt een /24 adresruimte van de POD CIDR.
• Met een plat netwerk kunt u de grootte van de subnetten van het virtuele netwerk voor zowel knooppunten als pods aanpassen. Azure CNI Pod Subnet maakt gebruik van afzonderlijke subnetten voor knooppunten en pods, terwijl verouderde Azure CNI-knooppuntsubnet één subnet gebruikt voor beide.
• 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.
• Als u uitschaalgebeurtenissen of clusterupgrades wilt afhandelen, 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 meest recente beveiligingspatches toe te passen. Zie Upgrade a node pool in AKS voor meer informatie over Windows Server knooppunten.

Zie IP-adresplanning voor AKS-clusters om de vereiste IP-adresruimte te berekenen.

Wanneer u een cluster maakt met Azure CNI-netwerken, geeft u andere adresbereiken op voor het cluster, zoals het IP-adresbereik van de DNS-service en het serviceadresbereik. Zorg er in het algemeen voor dat deze adresbereiken elkaar niet overlappen en ook niet met netwerken die aan het cluster zijn gekoppeld, waaronder virtuele netwerken, subnetten, on-premises netwerken en gekoppelde netwerken.

Zie Azure overzicht van CNI-netwerken voor meer informatie over netwerkmodellen, limieten en adresgrootten.

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 ingangscontrollers 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 dat verkeer te begrijpen. 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. Ingress kan verkeer distribueren op basis van de URL van de toepassing en de TLS/SSL-terminatie verwerken. Ingress vermindert ook het aantal IP-adressen dat je blootstelt en toewijst.

Bij gebruik van een load balancer heeft elke toepassing doorgaans een openbaar IP-adres nodig dat is toegewezen en gekoppeld aan de service in het AKS-cluster. Met een ingress-resource kan een enkel IP-adres verkeer naar meerdere toepassingen distribueren.

In het diagram ziet u één openbaar IP-adres dat extern verkeer ontvangt en een ingangscontroller die dat verkeer distribueert naar meerdere services in het AKS-cluster.

Ingress bestaat uit twee componenten: een ingress-resource en een ingress-controller.

Invoerresource

De ingressresource 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 de beheerde NGINX-ingangsklasse van de invoegtoepassing voor toepassingsroutering gebruikt. Het distribueert verkeer voor myapp.com naar een van de twee services, blogservice of storeservice en stuurt de klant 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: 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

Het veld ingressClassName specificeert de ingressklasse en moet overeenkomen met een klasse die is geconfigureerd op een ingress-controller in het cluster. De waarde webapprouting.kubernetes.azure.com selecteert de beheerde NGINX-ingangscontroller die wordt geleverd door de invoegtoepassing voor toepassingsroutering. Vervang deze door de klassenaam voor uw ingangscontroller als u een andere implementatie gebruikt.

Toegangscontroller

Een in het cluster gehoste ingress-controller draait als workload op een AKS-knooppunt en luistert naar binnenkomende aanvragen. Binnenkomend verkeer wordt vervolgens verdeeld op basis van de regels die zijn gedefinieerd in de ingress-resource die aan die controller is gekoppeld. Hoewel de meest voorkomende ingangscontroller is gebaseerd op NGINX, beperkt AKS u niet tot een specifieke controller. U kunt Application Gateway gebruiken voor containers, contour, HAProxy, Traefik en andere.

U moet door het cluster gehoste ingress-controllers inplannen 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.

Ingress met de invoegtoepassing voor toepassingsroutering

De invoegtoepassing voor toepassingsroutering biedt beheerde Ingress-implementaties voor AKS. Voor nieuwe, langdurige implementaties gebruikt u de implementatie van de Gateway-API voor toepassingsroutering wanneer deze ondersteuning biedt voor uw vereisten. Gateway API is de standaard voor de lange termijn voor Kubernetes ingress en Layer 7-verkeersbeheer.

De beheerde NGINX-implementatie biedt de volgende functies:

• Eenvoudige configuratie van beheerde NGINX Ingress-controllers op basis van Kubernetes NGINX Ingress-controller.
• Integratie met Azure DNS voor beheer van openbare en privézones.
• SSL-beëindiging met certificaten die zijn opgeslagen in Azure Key Vault.

Zie Inkomend verkeer configureren met de gateway-API voor toepassingsroutering en beheerde NGINX-ingangen met de invoegtoepassing voor toepassingsroutering voor meer informatie.

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 Web Application Firewall in Application Gateway for Containers. Application Gateway for Containers routeert HTTP-, HTTPS-, gRPC-, WebSocket- en AI-deductieverkeer en ondersteunt TLS-beëindiging.

Een in een cluster gehoste ingangscontroller wordt uitgevoerd als een Kubernetes-workload in uw AKS-cluster en distribueert verkeer naar services en toepassingen. Het verbruikt enkele van de resources van het knooppunt, zoals CPU, geheugen en netwerkbandbreedte. In grotere omgevingen kunt u het volgende overwegen:

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

Het diagram illustreert extern verkeer dat via Azure Application Gateway voor containers wordt doorgegeven. Wanneer WAF-beveiliging is geconfigureerd, filteren WAF-regels aanvragen voordat Application Gateway for Containers verkeer doorstuurt naar services in het AKS-cluster.

Voor die extra beveiligingslaag filtert een Web Application Firewall (WAF) binnenkomend verkeer. Beheerde en aangepaste regels beschermen tegen aanvallen zoals scripts op meerdere sites en SQL-injectie. Application Gateway voor containers is een laag 7-taakverdelings- en verkeersbeheerservice die ondersteuning biedt voor Azure WAF.

WAF-beveiliging is niet ingeschakeld door alleen Application Gateway for Containers te implementeren. U moet een WAF-beleid maken en beide van de volgende configuraties voltooien voordat WAF verkeer inspecteert:

• Maak een Azure-SecurityPolicyonderliggende bron die verwijst naar het WAF-beleid.
• Pas een aangepaste Kubernetes-resource WebApplicationFirewallPolicy toe die verwijst naar hetzelfde WAF-beleid en is gericht op de Gateway of HTTPRoute resource die moet worden beveiligd.

Nadat u beide configuraties hebt voltooid, controleert u de aangepaste resourcestatus en WAF-logboeken voordat u vertrouwt op het beleid voor beveiliging. Zie Azure Web Application Firewall op Application Gateway for Containers voor meer informatie.

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

Load balancer- of ingressbronnen worden voortdurend uitgevoerd in uw AKS-cluster en optimaliseren de verdeling van het verkeer. Azure Application Gateway voor containers kan centraal worden beheerd als een ingangscontroller met een resourcedefinitie. Om aan de slag te gaan, maakt u een Application Gateway for Containers en configureert u vervolgens WAF-beveiliging afzonderlijk.

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 in AKS wilt gebruiken, selecteert u een netwerkbeleidsengine die ondersteuning biedt voor uw knooppuntbesturingssystemen en het netwerkgegevensvlak. U kunt een beleidsengine inschakelen tijdens het maken van een cluster of op een bestaand ondersteund cluster.

Gebruik voor Linux-knooppuntgroepen Azure CNI op basis van Cilium en de ingebouwde handhaving van Cilium-netwerkbeleid. Cilium wordt niet ondersteund voor Windows knooppuntgroepen. Gebruik Calico voor Windows workloads.

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 het label app: backend. Met de regel voor inkomend verkeer is alleen verkeer van pods met het label app: frontend toegestaan.

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.

DNS-resolutie optimaliseren met LocalDNS

Richtlijnen voor best practices

Gebruik LocalDNS om de DNS-prestaties en betrouwbaarheid te verbeteren en de belasting van gecentraliseerde CoreDNS-pods te verminderen. LocalDNS is vooraf geconfigureerd in AKS Automatic. Schakel in AKS Standard LocalDNS per knooppuntgroep in en configureer deze.

LocalDNS implementeert een DNS-proxy als een systemd service op elk knooppunt om DNS-query's lokaal af te handelen. Pods verzenden standaard alle DNS-query's naar gecentraliseerde CoreDNS-pods. Bij het centraliseren van deze query's kan op schaal een knelpunt ontstaan, terwijl lokale resolutie netwerkhops en latentie vermindert.

LocalDNS elimineert ook tabelvermeldingen conntrack voor DNS-verkeer, waardoor tabeluitputting en racevoorwaarden worden voorkomen conntrack die verbroken verbindingen kunnen veroorzaken. Verbindingen van de lokale cache naar CoreDNS worden bijgewerkt naar TCP, waardoor het herverdelen van verbindingen en het sneller opschonen van tracking entries mogelijk wordt.

Voor workloads die een hoge DNS-beschikbaarheid vereisen, ondersteunt LocalDNS het dienen van verouderde en in de cache opgeslagen antwoorden voor een configureerbare periode wanneer de upstream-DNS niet beschikbaar is. Deze best-effort mogelijkheid kan helpen bij het onderhouden van podconnectiviteit en servicebetrouwbaarheid tijdens tijdelijke DNS-storingen, maar het garandeert niet dat er een verlopen record beschikbaar is.

In AKS Standard worden de knooppunten van een bestaande knooppuntgroep opnieuw geïmaged wanneer u LocalDNS inschakelt. Plan de implementatie om rekening te houden met deze onderbreking.

Zie DNS-omzetting in AKS voor meer informatie over localDNS-architectuur en -mogelijkheden. Zie LocalDNS configureren voor configuratie-instructies.

Veilig verbinding maken met knooppunten

Richtlijnen voor best practices

Maak geen externe connectiviteit beschikbaar voor uw AKS-knooppunten. Gebruik voor routineproblemen met Linux-knooppunten kubectl debug via de Kubernetes-API. Wanneer u SSH-toegang nodig hebt, maakt u verbinding via privénetwerken of Azure Bastion.

U kunt de meeste bewerkingen in AKS voltooien met behulp van Azure beheerhulpprogramma's of de Kubernetes-API-server. AKS-knooppunten zijn alleen beschikbaar in een particulier netwerk en zijn niet verbonden met het openbare internet. Gebruik kubectl debug voor Linux-knooppunten om een container met bevoorrechte foutopsporing te starten via de Kubernetes-API. Voor deze aanpak is geen directe SSH-verbinding met het knooppunt vereist.

Als kubernetes-API-toegang niet geschikt is of als u SSH nodig hebt, gebruikt u het privé-IP-adres van het knooppunt vanuit een verbonden netwerk. Azure Bastion kan privéconnectiviteit bieden zonder dat er een openbaar IP-adres op het knooppunt wordt weergegeven. Gebruik voor Windows knooppunten een hostprocescontainer of maak verbinding via een Linux-proxyknooppunt. Azure Bastion is een alternatief als het proxyknooppunt niet beschikbaar is. Zie Verbinding maken met AKS-clusterknooppunten voor onderhoud of probleemoplossing voor meer informatie.

Het diagram toont een virtueel beheernetwerk met een bastionhost die verbindingen routeert via een beveiligde gepeerde verbinding naar het virtuele netwerk van het AKS-cluster.

Als u een bastionhost of jumpbox gebruikt, plaatst u deze in een afzonderlijk, veilig gekoppeld virtueel beheernetwerk. Beveilig het beheernetwerk met behulp van Azure ExpressRoute of een VPN-gateway om verbinding te maken met een on-premises netwerk en de toegang te beheren met netwerkbeveiligingsgroepen.

Volgende stappen

Dit artikel is gericht op netwerkconnectiviteit en -beveiliging. Zie Network-concepten voor toepassingen in Azure Kubernetes Service (AKS)