Bewährte Methoden für Netzwerkkonnektivität und Sicherheit in Azure Kubernetes Service (AKS)

Beim Erstellen und Verwalten von Clustern in Azure Kubernetes Service (AKS) stellen Sie netzwerkkonnektivität für Ihre Knoten und Anwendungen bereit. Die Netzwerkressourcen umfassen IP-Adressbereiche, Load-Balancer und Ingress-Controller.

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-Netzwerk in AKS für die Integration in vorhandene virtuelle Netzwerke 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: Stellt in einem virtuellen Netzwerk bereit und verwendet das Azure CNI Kubernetes-Plug-In. Pods erhalten einzelne IP-Adressen, die an anderen Netzwerkdienste oder lokale Ressourcen weitergeleitet werden können.

Azure CNI ist eine gültige Option für Produktionsbereitstellungen.

CNI-Netzwerke

Azure CNI ist ein anbieterneutrales Protokoll, mit dem die Containerlaufzeit Anforderungen an einen Netzwerkanbieter stellen kann. Er weist Pods und Knoten IP-Adressen zu und stellt IP-Adressverwaltungsfunktionen (IPAM) bereit, während Sie eine Verbindung mit vorhandenen virtuellen Azure-Netzwerken herstellen. Jede Knoten- und Pod-Ressource empfängt eine IP-Adresse im Azure virtuellen Netzwerk. Für die Kommunikation mit anderen Ressourcen oder Diensten ist kein zusätzliches Routing erforderlich.

Insbesondere ermöglicht Azure CNI-Vernetzung für die Produktion die Trennung von Kontrolle und Verwaltung von Ressourcen. Aus Sicherheitssicht möchten Sie diese Ressourcen oft von verschiedenen Teams verwalten und absichern lassen. Mit Azure CNI-Netzwerk stellen Sie eine Verbindung mit vorhandenen Azure Ressourcen, lokalen Ressourcen oder anderen Diensten direkt über ip-Adressen her, die den einzelnen Pods zugewiesen sind.

Wenn Sie Azure CNI-Netzwerk verwenden, befindet sich die virtuelle Netzwerkressource in einer separaten Ressourcengruppe zum AKS-Cluster. 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 jedoch stattdessen auch einen Dienstprinzipal verwenden.

• Weitere Informationen zur AKS-Dienstprinzipaldelegierung finden Sie unter Zugriff auf andere Azure-Ressourcen delegieren.
• 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.
  • Bei Azure CNI-Netzwerkbetrieb verfügt jeder laufende Knoten über Standardgrenzwerte für die Anzahl der Pods.
• Vermeiden Sie die Verwendung von IP-Adressbereichen, die sich mit vorhandenen Netzwerkressourcen überschneiden.
  • Es ist erforderlich, die Konnektivität mit lokalen oder peerierten Netzwerken in Azure zuzulassen.
• Um Skalierungsereignisse oder Clusterupgrades zu behandeln, benötigen Sie zusätzliche IP-Adressen, die im zugewiesenen Subnetz verfügbar sind.
  • Dieser zusätzliche Adressraum ist besonders wichtig, wenn Sie Windows Server Container verwenden, da für diese Knotenpools ein Upgrade erforderlich ist, um die neuesten Sicherheitspatches anzuwenden. Weitere Informationen zu Windows Server Knoten finden Sie unter Upgrade eines Knotenpools in AKS.

Informationen zum Berechnen der erforderlichen IP-Adresse finden Sie unter Configure Azure CNI-Netzwerk in AKS.

Beim Erstellen eines Clusters mit Azure CNI-Netzwerk geben Sie andere Adressbereiche für den Cluster an, z. B. die Docker-Brückenadresse, 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.

Einzelheiten zu Grenzwerten und Größenanpassungen für diese Adressbereiche finden Sie unter Configure Azure CNI-Netzwerk 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 Azure Lastenausgleich bieten Eingangscontroller zusätzliche Features und können als systemeigene Kubernetes-Ressourcen verwaltet werden.

Während ein Azure Load Balancer Kundendatenverkehr an Anwendungen in Ihrem AKS-Cluster verteilen kann, hat er beschränkte Fähigkeiten, diesen Datenverkehr zu verstehen. 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. Ingress kann den Datenverkehr basierend auf der URL der Anwendung verteilen und die TLS/SSL-Terminierung verwalten. Ingress reduziert auch die Anzahl der IP-Adressen, die Sie offenlegen und abbilden.

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 Zugangskomponenten:

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 Ingress-Controller ist ein Daemon, der auf einem AKS-Knoten ausgeführt wird und 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 Anwendungsgateway für Container, Contour, HAProxy, Traefik usw. verwenden.

Ingress-Controller müssen auf einem Linux-Knoten bereitgestellt 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-Addon ist die empfohlene Methode zur Konfiguration eines Ingress-Controllers in AKS. Das Anwendungsrouting-Addon ist ein vollständig verwalteter, Eingangscontroller für Azure Kubernetes Service (AKS), der die folgenden Features bereitstellt:

• Einfache Konfiguration von verwalteten NGINX-Ingress-Controllern basierend auf dem Kubernetes NGINX Ingress-Controller.

• Integration mit Azure DNS für die Verwaltung öffentlicher und privater Zonen.

• 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

Um eingehenden Datenverkehr auf potenzielle Angriffe zu überprüfen, verwenden Sie eine Webanwendungsfirewall (WAF), z. B. Barracuda WAF für Azure oder Azure Application Gateway für Container. 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 auf eine Netzwerkressource außerhalb des AKS-Clusters auslagern.
• Sie können eingehenden Datenverkehr auf potenzielle Angriffe überprüfen.

Eine Webanwendungsfirewall (WAF) wie Azure-Application Gateway kann den Datenverkehr für Ihren AKS-Cluster schützen und verteilen.

Für diese zusätzliche Sicherheitsebene filtert eine Web Application Firewall (WAF) den eingehenden Datenverkehr. Mit einer Reihe von Regeln überwacht das Open Web Application Security Project (OWASP) Bedrohungen wie Cross-Site-Scripting oder Cookie-Poisoning. Azure Application Gateway für Container ist eine WAF, die sich in AKS-Cluster integriert und diese Sicherheitsfeatures verankert, bevor der Datenverkehr Ihre AKS-Cluster und 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 Ingress-Ressourcen werden in Ihrem AKS-Cluster laufend ausgeführt und optimieren die Verteilung des Datenverkehrs. Azure Application Gateway für Container kann zentral als Eingangscontroller mit einer Ressourcendefinition verwaltet werden. Erstellen Sie zunächst ein Anwendungsgateway für Container.

Steuern des Datenverkehrsflusses mit Netzwerkrichtlinien

Best Practices-Leitfaden

Verwenden Sie Netzwerkrichtlinien, um den Datenverkehr für 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 in AKS zu verwenden, kann das Feature entweder während der Clustererstellung oder auf einem vorhandenen AKS-Cluster aktiviert werden. Wenn Sie planen, Netzwerkrichtlinien zu verwenden, stellen Sie sicher, dass das Feature auf Ihrem AKS-Cluster aktiviert ist.

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 Ingressregel erlaubt nur Datenverkehr von Pods mit dem Label app: frontend.

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

Um mit Richtlinien zu beginnen, lesen Sie Sicheren Datenverkehr zwischen Pods mithilfe von Netzwerkrichtlinien in Azure Kubernetes Service (AKS).

Optimieren der DNS-Auflösung mit LocalDNS

Best Practices-Leitfaden

Aktivieren Sie LocalDNS in Ihren AKS-Knotenpools, um die DNS-Leistung, Zuverlässigkeit zu verbessern und die Auslastung von zentralen CoreDNS-Pods zu verringern.

Die DNS-Auflösung ist für die Dienst-zu-Dienst-Kommunikation in Kubernetes von entscheidender Bedeutung. Standardmäßig werden alle DNS-Abfragen von Pods an die zentralen CoreDNS-Pods gesendet, die zu einem Engpass im Großen und Ganzen werden können. AKS bietet LocalDNS, der einen DNS-Proxy als systemd Dienst auf jedem Knoten bereitstellt. Dieser Proxy verarbeitet DNS-Abfragen lokal, wodurch die Netzwerkhüpfungen und die Auflösungslatenz reduziert werden.

LocalDNS beseitigt auch conntrack Tabelleneinträge für DNS-Datenverkehr, wodurch die Tabellenausschöpfung und Race-Konflikte conntrack verhindert werden, die zu verworfenen Verbindungen führen können. Verbindungen vom lokalen Cache zu CoreDNS werden auf TCP aktualisiert, wodurch die Verbindungsrebalancing und eine schnellere Bereinigung von Nachverfolgungseinträgen ermöglicht werden.

Für Workloads, die eine hohe DNS-Verfügbarkeit erfordern, unterstützt LocalDNS die Bereitstellung veralteter zwischengespeicherter Antworten für eine konfigurierbare Dauer, wenn upstream DNS nicht verfügbar ist. Diese Funktion trägt dazu bei, die Zuverlässigkeit der Pod-Konnektivität und des Diensts während vorübergehender DNS-Ausfälle aufrechtzuerhalten.

Weitere Informationen zur LocalDNS-Architektur und -Funktionen finden Sie unter DNS-Auflösung in AKS. Konfigurationsanweisungen finden Sie unter Configure LocalDNS.

Sichere Verbindung zu Knoten über einen Bastion-Host herstellen

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.

Sie können die meisten Vorgänge in AKS mithilfe der 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 eine Verbindung mit einem lokalen Netzwerk herzustellen und den Zugriff mithilfe von Netzwerksicherheitsgruppen zu steuern.

Nächste Schritte

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