Best Practices für Netzwerkkonnektivität und Sicherheit in Azure Kubernetes Service (AKS)

Beim Erstellen und Verwalten von Clustern in Azure Kubernetes Service (AKS) stellen Sie die Netzwerkkonnektivität für Ihre Knoten und Anwendungen bereit. Die Netzwerkressourcen umfassen IP-Adressbereiche, Lastenausgleichsmodule und Controller für eingehenden Datenverkehr.

In diesem Artikel zu bewährten Methoden liegt der Schwerpunkt auf der Netzwerkkonnektivität und der Sicherheit für Clusteroperatoren. In diesem Artikel werden folgende Vorgehensweisen behandelt:

Auswählen des geeigneten Netzwerkmodells

Best Practices-Leitfaden

Verwenden Sie Azure CNI-Netzwerke in AKS für die Integration in vorhandene virtuelle oder lokale Netzwerke. Dieses Netzwerkmodell ermöglicht eine stärkere Trennung von Ressourcen und Steuerelementen in einer Unternehmensumgebung.

Virtuelle Netzwerke bieten die grundlegende Konnektivität für AKS-Knoten und Kunden für den Zugriff auf Ihre Anwendungen. Es gibt zwei verschiedene Möglichkeiten, AKS-Cluster in virtuellen Netzwerken bereitzustellen:

• Azure CNI-Netzwerk: Wird in einem virtuellen Netzwerk bereitgestellt und verwendet das Azure CNI-Kubernetes-Plug-In. Pods erhalten einzelne IP-Adressen, die an anderen Netzwerkdienste oder lokale Ressourcen weitergeleitet werden können.
• kubenet-Netzwerk: Azure verwaltet die virtuellen Netzwerkressourcen während der Bereitstellung des Clusters und verwendet das Kubernetes-Plug-In kubenet.

Sowohl Azure CNI als auch kubenet sind für Produktionsbereitstellungen geeignet.

CNI-Netzwerke

Das Azure CNI ist ein herstellerneutrales Protokoll, mit dem die Containerruntime Anforderungen an einen Netzwerkanbieter richten kann. Es weist Pods und Knoten IP-Adressen zu und stellt Features zur IP-Adressverwaltung (IPAM) bereit, wenn Sie die Verbindung zu bestehenden virtuellen Azure-Netzwerken herstellen. Jede Knoten- und Pod-Ressource erhält eine IP-Adresse im virtuellen Azure-Netzwerk. Für die Kommunikation mit anderen Ressourcen oder Diensten ist kein zusätzliches Routing erforderlich.

Ein beachtlicher Vorteil des Azure CNI-Netzwerks besteht darin, dass eine Trennung von Steuerung und Verwaltung von Ressourcen möglich ist. Aus Sicherheitssicht möchten Sie diese Ressourcen oft von verschiedenen Teams verwalten und absichern lassen. Mit Azure CNI-Netzwerken können Sie die Verbindung zu vorhandenen Azure-Ressourcen, lokalen Ressourcen oder anderen Diensten direkt über die jedem Pod zugeordneten IP-Adressen herstellen.

Wenn Sie Azure CNI-Netzwerke verwenden, befindet sich die virtuelle Netzwerkressource in einer vom AKS-Cluster getrennten Ressourcengruppe. Delegieren Sie Berechtigungen für die AKS-Clusteridentität, um auf diese Ressourcen zugreifen und sie verwalten zu können. Die vom AKS-Cluster verwendete Clusteridentität muss mindestens Berechtigungen Netzwerkmitwirkender für das Subnetz in Ihrem virtuellen Netzwerk haben.

Wenn Sie eine benutzerdefinierte Rolle anstelle der integrierten Rolle des Netzwerkmitwirkenden definieren möchten, sind die folgenden Berechtigungen erforderlich:

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

Standardmäßig verwendet AKS eine verwaltete Identität als Clusteridentität. Sie können stattdessen jedoch auch einen Dienstprinzipal verwenden.

• Weitere Informationen zur AKS-Dienstprinzipaldelegierung finden Sie unter Delegieren des Zugriffs auf andere Azure-Ressourcen.
• Weitere Informationen zu verwalteten Identitäten finden Sie unter Verwenden verwalteter Identitäten.

Da jeder Knoten und Pod seine eigene IP-Adresse erhält, planen Sie die Adressbereiche für die AKS-Subnetze. Berücksichtigen Sie folgende Kriterien:

• Das Subnetz muss groß genug sein, um IP-Adressen für alle von Ihnen bereitgestellten Knoten, Pods und Netzwerkressourcen zu bieten.
  • Sowohl beim kubenet- als auch beim Azure CNI-Netzwerk ist die Anzahl der Pods für jeden ausgeführten Knoten standardmäßig begrenzt.
• Vermeiden Sie die Verwendung von IP-Adressbereichen, die sich mit vorhandenen Netzwerkressourcen überschneiden.
  • Dies ist erforderlich, um Konnektivität mit lokalen oder Peernetzwerken in Azure zu ermöglichen.
• Um Aufskalierungsereignisse oder Clusterupgrades verarbeiten zu können, benötigen Sie zusätzliche IP-Adressen, die im zugewiesenen Subnetz zur Verfügung stehen.
  • Dieser zusätzliche Adressraum ist besonders wichtig, wenn Sie Windows Server-Container verwenden, da diese Knotenpools ein Upgrade erfordern, damit die neuesten Sicherheitspatches angewendet werden. Weitere Informationen zu Windows Server-Knoten finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS.

Informationen zum Berechnen der erforderlichen IP-Adresse finden Sie unter Konfigurieren von Azure CNI-Netzwerken in AKS.

Beim Erstellen eines Clusters mit Azure CNI-Netzwerken geben Sie andere Adressbereiche für den Cluster an, z. B. die Docker-Bridgeadresse, die DNS-Dienst-IP und den Dienstadressbereich. Im Allgemeinen sollten Sie sicherstellen, dass sich diese Adressbereiche nicht gegenseitig oder mit Netzwerken überlappen, die dem Cluster zugeordnet sind, einschließlich aller virtuellen Netzwerke, Subnetze, lokaler Netzwerke und Peernetzwerke.

Ausführliche Informationen zu Grenzwerten und zur Größenanpassung für diese Adressbereiche finden Sie unter Konfigurieren von Azure CNI-Netzwerken in AKS.

Kubenet-Netzwerke

Für kubenet ist es zwar nicht erforderlich, dass Sie die virtuellen Netzwerke vor der Bereitstellung des Clusters konfigurieren, allerdings entstehen Nachteile, wenn Sie zu lange warten, beispielsweise:

• Da sich Knoten und Pods in verschiedenen IP-Subnetzen befinden, wird der Datenverkehr zwischen Pods und Knoten über benutzerdefiniertes Routing (UDR) und IP-Weiterleitung abgewickelt. Dieses zusätzliche Routing kann die Netzwerkleistung reduzieren.
• Verbindungen zu bestehenden lokalen Netzwerken oder das Peering mit anderen virtuellen Netzwerken von Azure können komplex sein.

Da Sie das virtuelle Netzwerk und die Subnetze nicht getrennt vom AKS-Cluster erstellen, eignet sich kubenet ideal für folgende Szenarien:

• Kleine Entwicklungs- oder Testworkloads.
• Einfache Websites mit geringem Datenverkehr.
• Heben und Verschieben von Workloads in Container.

Bei Produktionsbereitstellungen sind sowohl kubenet als auch Azure CNI gültige Optionen. Umgebungen, die eine Trennung von Kontrolle und Verwaltung erfordern, können Azure CNI die bevorzugte Option sein. Darüber hinaus eignet sich kubenet für reine Linux-Umgebungen, in denen die Erhaltung des IP-Adressbereichs eine Priorität ist.

Sie können auch Ihre eigenen IP-Adressbereiche und virtuellen Netzwerke mit kubenet konfigurieren. Ähnlich wie beim Azure CNI-Netzwerk dürfen sich diese Adressbereiche nicht gegenseitig oder mit Netzwerken überlappen, die dem Cluster zugeordnet sind (virtuelle Netzwerke, Subnetze, lokale Netzwerke und Peernetzwerke).

Ausführliche Informationen zu Grenzwerten und zur Größenanpassung für diese Adressbereiche finden Sie unter Verwenden von kubenet-Netzwerken mit Ihren eigenen IP-Adressbereichen in AKS.

Verteilen des Eingangsdatenverkehrs

Best Practices-Leitfaden

Um HTTP- oder HTTPS-Datenverkehr an Ihre Anwendungen zu verteilen, verwenden Sie Eingangsressourcen und -controller. Im Vergleich zu einem normalen Azure Load Balancer bieten Eingangscontroller zusätzliche Features und können als native Kubernetes-Ressourcen verwaltet werden.

Ein Azure Load Balancer kann zwar den Kundendatenverkehr auf Anwendungen in Ihrem AKS-Cluster verteilen, aber ist nur begrenzt in der Lage, diesen Datenverkehr zu erkennen. Eine Lastenausgleichsressource wird auf Ebene 4 ausgeführt und verteilt den Datenverkehr basierend auf dem Protokoll oder den Ports.

Die meisten Webanwendungen, die HTTP oder HTTPS verwenden, sollten Kubernetes-Eingangsressourcen und -controller verwenden, die auf Ebene 7 ausgeführt werden. Eingangsdatenverkehr kann den Datenverkehr basierend auf der URL der Anwendung verteilen und die TLS/SSL-Terminierung behandeln. Eingangsdatenverkehr reduziert auch die Anzahl der IP-Adressen, die Sie freigeben und zuordnen.

Bei einem Load Balancer benötigt jede Anwendung typischerweise eine öffentliche IP-Adresse, die dem Dienst im AKS-Cluster zugewiesen und zugeordnet wird. Bei Verwendung einer Eingangsressource kann eine einzige IP-Adresse den Datenverkehr auf mehrere Anwendungen verteilen.

Es gibt zwei Komponenten für den Eingangsdatenverkehr:

1. Eine Eingangsressource
2. Ein Eingangscontroller

Eingangsressource

Die Eingangsressource ist ein YAML-Manifest von kind: Ingress. Sie definiert den Host, die Zertifikate und die Regeln zum Weiterleiten des Datenverkehrs an die Dienste, die in Ihrem AKS-Cluster ausgeführt werden.

Im folgenden YAML-Beispielmanifest wird der Datenverkehr für myapp.com an einen der beiden Dienste blogservice oder storeservice verteilt. Außerdem wird der Kunde basierend auf der URL, auf die er zugreift, an den einen oder den anderen Dienst weitergeleitet.

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

Eingangscontroller

Ein Eingangscontroller ist ein Daemon, der auf einem AKS-Knoten ausgeführt wird und diesen auf eingehende Anforderungen überwacht. Datenverkehr wird dann entsprechend den in der Eingangsressource definierten Regeln verteilt. Während der gängigste Eingangscontroller auf NGINX basiert, beschränkt AKS Sie nicht auf einen bestimmten Controller. Sie können Contour, HAProxy,Traefik usw. verwenden.

Eingangscontroller müssen auf einem Linux-Knoten geplant werden. Geben Sie an, dass die Ressource auf einem Linux-basierten Knoten ausgeführt werden soll, indem Sie einen Knotenselektor in Ihrem YAML-Manifest oder Ihrem bereitgestellten Helm-Diagramm verwenden. Weitere Informationen finden Sie unter Verwenden von Knotenselektoren, um zu steuern, wo Pods in AKS geplant werden.

Eingang mit dem Anwendungsrouting-Add-On

Das Anwendungsrouting-Add-On ist die empfohlene Methode zum Konfigurieren eines Eingangsdatencontrollers in AKS. Das Anwendungsrouting-Add-On ist ein vollständig verwalteter Eingangsdatencontroller für Azure Kubernetes Service (AKS), der die folgenden Funktionen bereitstellt:

• Einfache Konfiguration von verwalteten NGINX-Eingangsdatencontrollern basierend auf NGINX-Eingangsdatencontrollern für Kubernetes

• Integration in Azure DNS für die Verwaltung öffentlicher und privater Zone.

• SSL-Beendigung mit Zertifikaten, die in Azure Key Vault gespeichert sind

Weitere Informationen zum Anwendungsrouting-Add-On finden Sie unter Verwalteter NGINX-Eingang mit dem Anwendungsrouting-Add-On.

Absichern des Datenverkehrs mit einer Web Application Firewall (WAF)

Best Practices-Leitfaden

Verwenden Sie eine Web Application Firewall (WAF) wie Barracuda WAF für Azure oder Azure Application Gateway, um eingehenden Datenverkehr auf mögliche Angriffe zu überprüfen. Diese fortschrittlicheren Netzwerkressourcen können den Datenverkehr auch über reine HTTP- und HTTPS-Verbindungen oder eine einfache TLS-Terminierung hinaus routen.

Normalerweise ist ein Eingangscontroller eine Kubernetes-Ressource in Ihrem AKS-Cluster, die den Datenverkehr auf Dienste und Anwendungen verteilt. Der Controller wird als Daemon auf einem AKS-Knoten ausgeführt und verbraucht einige der Ressourcen des Knotens wie CPU, Speicher und Netzwerkbandbreite. In größeren Umgebungen sollten Sie Folgendes berücksichtigen:

• Sie können einen Teil dieses Datenverkehrsroutings oder der TLS-Terminierung häufig auf eine Netzwerkressource außerhalb des AKS-Clusters auslagern.
• Sie können eingehenden Datenverkehr auf potenzielle Angriffe überprüfen.

Für diese zusätzliche Sicherheitsebene filtert eine Web Application Firewall (WAF) den eingehenden Datenverkehr. Anhand einer Reihe von Regeln überwacht Open Web Application Security Project (OWASP) den Datenverkehr auf Angriffe wie websiteübergreifende Skripts oder Cookie-Poisoning. Azure Application Gateway (derzeit in der Vorschauversion in AKS) ist eine WAF, die in AKS-Cluster integriert wird und diese Sicherheitsfunktionen sperrt, bevor der Datenverkehr Ihren AKS-Cluster und Ihre Anwendungen erreicht.

Da auch andere Lösungen von Drittanbietern diese Funktionen bieten, können Sie bestehende Investitionen in Ihr bevorzugtes Produkt oder vorhandenes Know-how weiterhin nutzen.

Load Balancer oder Eingangsressourcen werden in Ihrem AKS-Cluster weiterhin ausgeführt und optimieren die Verteilung des Datenverkehrs. App Gateway kann zentral als Eingangscontroller mit einer Ressourcendefinition verwaltet werden. Erstellen Sie zunächst einen Application Gateway-Eingangscontroller.

Steuern des Datenverkehrsflusses mit Netzwerkrichtlinien

Best Practices-Leitfaden

Verwenden Sie Netzwerkrichtlinien, um Datenverkehr zu den Pods zuzulassen oder zu verweigern. Standardmäßig ist der gesamte Datenverkehr zwischen den Pods in einem Cluster zulässig. Aus Sicherheitsgründen sollten Sie Regeln definieren, um die Kommunikation zwischen den Pods einzuschränken.

Netzwerkrichtlinien sind ein in AKS verfügbares Kubernetes-Feature, mit dem Sie den Datenverkehrsfluss zwischen Pods steuern können. Anhand von Einstellungen wie zugewiesene Bezeichnungen, Namespace oder Port für den Datenverkehr können Sie Datenverkehr zulassen oder verweigern. Netzwerkrichtlinien sind eine cloudnative Möglichkeit, den Datenverkehrsfluss für Pods zu steuern. Wenn Pods in einem AKS-Cluster dynamisch erstellt werden, können automatisch die erforderlichen Netzwerkrichtlinien angewendet werden.

Um Netzwerkrichtlinien verwenden zu können, aktivieren Sie das Feature beim Erstellen eines neuen AKS-Clusters. Ohne einen vorhandenen AKS-Cluster können Sie keine Netzwerkrichtlinie aktivieren. Planen Sie voraus, um die Netzwerkrichtlinie für die erforderlichen Cluster zu aktivieren.

Sie erstellen eine Netzwerkrichtlinie mit einem YAML-Manifest als Kubernetes-Ressource. Richtlinien werden auf definierte Pods angewendet, wobei Eingangs- oder Ausgangsregeln den Datenverkehrsfluss definieren.

Im folgenden Beispiel wird eine Netzwerkrichtlinie auf Pods mit der zugewiesenen Bezeichnung app: backend angewendet. Die Eingangsregel lässt ausschließlich Datenverkehr von Pods mit der Bezeichnung app: frontend zu.

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

Eine Anleitung für die ersten Schritte mit Richtlinien finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in Azure Kubernetes Service (AKS).

Herstellen einer sicheren Verbindung zu Knoten über einen Bastionhost

Best Practices-Leitfaden

Machen Sie für Ihre AKS-Knoten keine Remotekonnektivität verfügbar. Erstellen Sie einen Bastionhost oder eine Jumpbox in einem virtuellen Verwaltungsnetzwerk. Verwenden Sie den Bastionhost, um den Datenverkehr sicher in Ihren AKS-Cluster für Remoteverwaltungsaufgaben zu routen.

Die meisten Vorgänge in AKS können Sie mit den Azure-Verwaltungstools oder über den Kubernetes API-Server ausführen. AKS-Knoten sind nur in einem privaten Netzwerk verfügbar und sind nicht mit dem öffentlichen Internet verbunden. Um eine Verbindung mit Knoten herzustellen und Wartung und Support bereitzustellen, leiten Sie Ihre Verbindungen über einen Bastionhost oder eine Jumpbox weiter. Stellen Sie sicher, dass sich dieser Host in einem separaten virtuellen Verwaltungsnetzwerk befindet, das sicher per Peering mit dem virtuellen AKS-Clusternetzwerk verbunden ist.

Darüber hinaus sollte das Verwaltungsnetzwerk für den Bastionhost abgesichert sein. Verwenden Sie ein Azure ExpressRoute- oder VPN-Gateway, um sich mit einem lokalen Netzwerk zu verbinden und den Zugriff über Netzwerksicherheitsgruppen zu steuern.

Nächste Schritte

Dieser Artikel konzentriert sich auf Netzwerkkonnektivität und Sicherheit. Weitere Informationen zu Netzwerkgrundlagen in Kubernetes finden Sie unter Netzwerkkonzepte für Anwendungen in Azure Kubernetes Service (AKS).