Schützen eines AKS-Clusters (Azure Kubernetes Service) mit Azure Firewall

Azure Firewall

Azure Kubernetes Service (AKS)

Azure Private Link

Azure Virtual Network

Azure DevOps

Diese Anleitung beschreibt, wie Sie einen privaten AKS-Cluster in einer Hub-and-Spoke-Netzwerk-Topologie mithilfe von Terraform und Azure DevOps erstellen. Azure Firewall überwacht den Datenverkehr zum und vom Azure Kubernetes Service (AKS)-Cluster. Der Cluster wird von einem oder mehreren Spoke-VNets gehostet, die per Peering mit dem Hub-VNet gekoppelt sind.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Terraform-Module stellen ein neues virtuelles Netzwerk mit vier Subnetzen bereit, die hosten:

Den AKS-Cluster (AksSubnet)
Ein virtueller Sprungkastencomputer (VM) und private Endpunkte (VmSubnet).
Application Gateway WAF2 (AppGatewaySubnet)
Azure Bastion (AzureBastionSubnet)

Der AKS-Cluster nutzt eine benutzerdefinierte verwaltete Identität zum Erstellen zusätzlicher Ressourcen (wie Lastenausgleichsmodule und verwaltete Datenträger) in Azure. Mit den Terraform-Modulen können Sie optional einen AKS-Cluster mit diesen Features bereitstellen:

Der AKS-Cluster besteht aus den folgenden Pools:

Systemknotenpool, der nur kritische Systempods und -dienste hostet
Benutzerknotenpool, der Benutzerworkloads und -artefakte hostet

Eine VM wird im virtuellen Netzwerk bereitgestellt, in dem der AKS-Cluster gehostet wird. Wenn Sie AKS als privaten Cluster bereitstellen, können Systemadministratoren mithilfe dieser VM den Cluster über das Kubernetes-Befehlszeilentool verwalten. Die Startdiagnoseprotokolle der VM werden in einem Azure Storage-Konto gespeichert.

Ein Azure Bastion-Host bietet eine verbesserte Sicherheits-SSH-Konnektivität mit dem Sprungfeld-VM über Secure Sockets Layer (SSL). Azure Container Registry dient zum Erstellen, Speichern und Verwalten von Containerimages und Artefakten (wie Helm-Diagrammen).

AKS bietet keine integrierte Lösung zum Sichern von Eingangs- und Ausgangsdatenverkehr zwischen dem Cluster und externen Netzwerken.

Aus diesem Grund enthält die in diesem Artikel vorgestellte Architektur eine Azure-Firewall , die eingehenden und ausgehenden Datenverkehr mithilfe von DNAT-Regeln (Destination Network Address Translation), Netzwerkregeln und Anwendungsregeln steuert. Die Firewall schützt workloads auch mithilfe der bedrohungsintelligenzbasierten Filterung. Azure Firewall und Azure Bastion werden in einem virtuellen Hubnetzwerk (Hub-VNet) bereitgestellt, das mittels Peering mit dem virtuellen Netzwerk verbunden ist, das den privaten AKS-Cluster hostet. Eine Routentabelle und benutzerdefinierte Routen leiten direkten ausgehenden Datenverkehr vom AKS-Cluster an die Azure-Firewall.

Hinweis

Wir empfehlen nachdrücklich, die Premium SKU von Azure Firewall zu verwenden, da sie erweiterten Schutz vor Bedrohungen bietet.

Ein Schlüsseltresor wird von Workloads, die in AKS ausgeführt werden, als Geheimnisspeicher verwendet, um Schlüssel, Zertifikate und Geheimnisse über die Microsoft Entra Workload ID, den Secrets Store CSI-Treiber oder Dapr abzurufen. Azure Private Link ermöglicht AKS-Workloads den Zugriff auf Azure-Plattform as a Service(PaaS)-Dienste wie Azure Key Vault über einen privaten Endpunkt im virtuellen Netzwerk.

Die Topologie umfasst private Endpunkte und DNS-Zonen für diese Dienste:

Zwischen dem virtuellen Netzwerk, das den AKS-Cluster hostet, und den zuvor beschriebenen privaten Domain Name System (DNS)-Zonen besteht eine virtuelle Netzwerkverbindung.

Ein Log Analytics-Arbeitsbereich dient zum Sammeln von Diagnoseprotokollen und Metriken von Azure-Diensten.

Komponenten

Azure Firewall ist ein cloudnativer, intelligenter Sicherheitsdienst mit Netzwerkfirewall, der Bedrohungsschutz für in Azure ausgeführte Cloudworkloads bietet. In dieser Architektur bietet die Azure Firewall sowohl Ost-West- als auch Nord-Süd-Datenverkehrsüberprüfungen. Sie steuert eingehenden und ausgehenden Datenverkehr mithilfe von DNAT-Regeln, Netzwerkregeln und Anwendungsregeln und schützt Workloads mithilfe der auf Bedrohungserkennung basierenden Filterung im virtuellen Hubnetzwerk.
Azure Container Registry ist ein verwalteter, privater Docker-Registrierungsdienst, der auf Version 2.0 der Open-Source-Docker-Registrierung basiert. In dieser Architektur wird die Containerregistrierung verwendet, um Containerimages und Artefakte wie Helm-Diagramme zu erstellen, zu speichern und zu verwalten, die im AKS-Cluster bereitgestellt werden, wobei die Georeplikation für Notfallwiederherstellungsszenarien unterstützt wird.
AKS ist ein verwalteter Kubernetes-Dienst, der die Kubernetes-Clusterbereitstellung und -verwaltung vereinfacht. In dieser Architektur hosten AKS den privaten Cluster mit System- und Benutzerknotenpools in einem virtuellen Speichennetzwerk.
Key Vault ist ein cloudbasierter Dienst, der den Zugriff auf geheime Schlüssel wie API-Schlüssel, Kennwörter, Zertifikate und kryptografische Schlüssel mit verbesserter Sicherheit speichert und steuert. In dieser Architektur dient Key Vault als geheimer Speicher für Arbeitslasten, die auf AKS ausgeführt werden.
Azure Bastion ist ein vollständig verwaltetes PaaS, das Remotedesktopprotokoll (RDP) und Secure Shell (SSH)-Konnektivität mit den virtuellen Computern (VMs) in Ihrem virtuellen Netzwerk bereitstellt, direkt über das Azure-Portal über TLS. In dieser Architektur bietet Azure Bastion sichereren Zugriff auf die Sprungbox-VM über SSL über das Azure-Portal, wodurch die Notwendigkeit beseitigt wird, virtuelle Computer direkt im öffentlichen Internet verfügbar zu machen.
Azure Virtual Machines ist ein Computedienst, der on-demand, skalierbare Computerressourcen bereitstellt, die Ihnen die Flexibilität der Virtualisierung bieten. In dieser Architektur dient virtuelle Computer als Sprungfeldhost, der im virtuellen Netzwerk bereitgestellt wird, das den AKS-Cluster hosten. Systemadministratoren können den privaten Cluster über Kubectl verwalten, wenn der direkte Zugriff auf den API-Server eingeschränkt ist.
Azure Virtual Network ist der grundlegende Baustein für private Azure-Netzwerke. Virtuelles Netzwerk ermöglicht Azure-Ressourcen wie VMs die Kommunikation mit einander, dem Internet und lokalen Netzwerken mit verbesserter Sicherheit. In dieser Architektur bietet virtuelles Netzwerk Netzwerk Netzwerkisolation und Konnektivität mit dem Speichennetzwerk, das den AKS-Cluster und Subnetze für verschiedene Komponenten hostet. Es wird mit dem Hubnetzwerk peered, das Azure Firewall und Azure Bastion enthält.
Virtuelle Netzwerkschnittstellen sind Netzwerkkomponenten, mit denen Azure-VMs mit dem Internet, Azure und lokalen Ressourcen kommunizieren können. In dieser Architektur bieten Netzwerkschnittstellen Konnektivität für die Knoten "Jump box VM" und "AKS". Sie können mehrere Netzwerkschnittstellenkarten zu einer Azure-VM hinzufügen, sodass untergeordnete VMs über ihre eigenen dedizierten Netzwerkschnittstellengeräte und IP-Adressen verfügen können.
Verwaltete Azure-Datenträger sind Speichervolumes auf Blockebene, die von Azure auf Azure-VMs verwaltet werden. Ultra-, Premium-SSD- und Standard-SSD-Datenträger sowie Standard-Festplattenlaufwerke (HDDs) sind verfügbar. In dieser Architektur bieten verwaltete Datenträger beständigen Speicher für die Knoten "Jump box VM" und "AKS Cluster".
Azure Blob Storage ist eine Objektspeicherlösung für die Cloud. Blob Storage ist für die Speicherung großer Mengen unstrukturierter Daten optimiert. In dieser Architektur speichert Blob Storage die Startdiagnoseprotokolle der Vm des Sprungfelds.
Private Verknüpfung ist ein Netzwerkdienst, mit dem Sie über einen privaten Endpunkt in Ihrem virtuellen Netzwerk auf Azure PaaS-Dienste zugreifen können. In dieser Architektur bietet Private Link sichere Konnektivität zu Diensten wie Blob Storage, Containerregistrierung und Key Vault. Dadurch wird sichergestellt, dass der Datenverkehr auf dem Azure-Backbone bleibt, ohne dass das öffentliche Internet ausgesetzt ist. Sie können sie auch verwenden, um auf azure gehostete Dienste zuzugreifen, die Sie besitzen oder die ein Microsoft-Partner bereitstellt.

Alternativen

Sie können anstelle von Azure Firewall eine Firewall eines Drittanbieters aus Azure Marketplace verwenden. In diesem Fall sind Sie dafür verantwortlich, die Firewall so zu konfigurieren, dass sie den ein- und ausgehenden Datenverkehr des AKS-Clusters prüft und zulässt bzw. verweigert.

Szenariodetails

AKS-Cluster werden in einem virtuellen Netzwerk bereitgestellt, das verwaltet oder benutzerdefiniert sein kann. Unabhängig davon weist der Cluster ausgehende Abhängigkeiten von Diensten außerhalb des virtuellen Netzwerks auf. Zu Verwaltungs- und Betriebszwecken müssen AKS-Clusterknoten auf bestimmte Ports und vollqualifizierte Domänennamen (Fully Qualified Domain Names, FQDNs) zugreifen, die diesen ausgehenden Abhängigkeiten zugeordnet sind. Dies umfasst den Zugriff auf den Kubernetes-API-Server Ihres eigenen Clusters, das Herunterladen und Installieren von Clusterkomponenten sowie das Pullen von Containerimages aus Microsoft Container Registry. Diese ausgehenden Abhängigkeiten werden mit FQDNs definiert und verfügen nicht über statische Adressen, wodurch es unmöglich ist, ausgehenden Datenverkehr mithilfe von Netzwerksicherheitsgruppen zu sperren. AKS-Cluster verfügen daher standardmäßig über uneingeschränkten ausgehenden Internetzugriff, damit Knoten und Dienste bei Bedarf auf externe Ressourcen zugreifen können.

In einer Produktionsumgebung ist es jedoch in der Regel wünschenswert, den Kubernetes-Cluster vor Datenexfiltration und anderen unerwünschten Netzwerkdatenverkehr zu schützen. Der gesamte Netzwerkdatenverkehr (ein- und ausgehend) sollte auf der Grundlage von Sicherheitsregeln gesteuert werden. Um dies zu erreichen, muss der ausgehende Datenverkehr eingeschränkt werden, wobei der Zugriff auf erforderliche Ports und Adressen für routinemäßige Clusterwartungsaufgaben, ausgehende Abhängigkeiten und Workloadanforderungen weiterhin möglich sein muss.

Eine einfache Lösung ist die Verwendung eines Firewallgeräts, das den ausgehenden Datenverkehr auf der Grundlage von Domänennamen steuern kann. Eine Firewall schafft eine Barriere zwischen einem vertrauenswürdigen Netzwerk und dem Internet. Verwenden Sie Azure Firewall, um ausgehenden Datenverkehr basierend auf dem FQDN, Protokoll und Port des Ziels einzuschränken und eine präzise Steuerung des ausgehenden Datenverkehrs zu ermöglichen. Es ermöglicht außerdem die Zulassungsauflistung für FQDNs, die den ausgehenden Abhängigkeiten eines AKS-Clusters zugeordnet sind, was mit Netzwerksicherheitsgruppen nicht möglich ist. Außerdem kann die auf Threat Intelligence basierende Filterung in einer Azure Firewall-Instanz in einem gemeinsam genutzten Umkreisnetzwerk eingehenden Datenverkehr steuern und die Sicherheit verbessern. Diese Filterung kann Warnungen generieren und Datenverkehr zu und von bekannten schädlichen IP-Adressen und Domänen verweigern.

Sie können einen privaten AKS-Cluster mithilfe von Terraform und Azure DevOps in einer Hub-and-Spoke-Netzwerktopologie bereitstellen. Azure Firewall überwacht den Datenverkehr zum und vom Azure Kubernetes Service (AKS)-Cluster. Der Cluster wird von einem oder mehreren Spoke-VNets gehostet, die per Peering mit dem Hub-VNet gekoppelt sind.

Azure Firewall unterstützt drei verschiedene SKUs, um eine Vielzahl von Anwendungsfällen und Präferenzen von Kunden zu erfüllen:

Azure Firewall Premium wird empfohlen, um höchst vertrauliche Anwendungen wie die Zahlungsverarbeitung zu schützen. Der Dienst unterstützt erweiterte Bedrohungsschutzfunktionen wie Überprüfung auf Schadsoftware und TLS-Überprüfung.
Azure Firewall Standard wird für Kunden empfohlen, die nach einer Firewall für Schicht 3 bis Schicht 7 suchen und die Möglichkeit automatischer Skalierung benötigen, um zu Spitzenzeiten anfallenden Datenverkehr von bis zu 30 GBit/s zu verarbeiten. Der Dienst unterstützt Unternehmensfeatures wie Threat Intelligence, DNS-Proxy, benutzerdefiniertes DNS und Webkategorien.
Azure Firewall Basic wird für Kunden mit Durchsatzanforderungen von weniger als 250 MBit/s empfohlen.

In der folgenden Tabelle sind die Features der drei Azure Firewall-SKUs aufgeführt. Weitere Informationen finden Sie unter Azure Firewall – Preise.

Screenshot: Features der drei SKUs für Azure Firewall

Standardmäßig haben AKS-Cluster uneingeschränkten ausgehenden Internetzugriff. Diese Ebene des Netzwerkzugriffs ermöglicht, dass im AKS-Cluster betriebene Knoten und Dienste bei Bedarf auf externe Ressourcen zugreifen können. Wenn Sie ausgehenden Datenverkehr einschränken möchten, muss eine begrenzte Anzahl von Ports und Adressen zugänglich bleiben, um Wartungsaufgaben für einen fehlerfreien Clusterbetrieb ausführen zu können. Die einfachste Möglichkeit, den ausgehenden Datenverkehr eines Kubernetes-Clusters wie AKS abzusichern, ist die Verwendung einer Softwarefirewall, die ausgehenden Datenverkehr anhand von Domänennamen steuern kann. Azure Firewall kann ausgehenden HTTP- und HTTPS-Datenverkehr basierend auf dem FQDN (vollqualifizierten Domänennamen) des Ziels beschränken. Darüber hinaus können Sie auch Firewall- und Sicherheitsregeln konfigurieren, um diese erforderlichen Ports und Adressen zuzulassen. Weitere Informationen finden Sie unter Steuern des ausgehenden Datenverkehrs für Clusterknoten in Azure Kubernetes Service (AKS).

Ebenso können Sie eingehenden Datenverkehr steuern und die Sicherheit verbessern, indem Sie eine auf Threat Intelligence basierende Filterung in einer Azure Firewall-Instanz aktivieren, die in einem gemeinsam genutzten Umkreisnetzwerk bereitgestellt wird. Diese Filterung kann Warnungen ausgeben und den Datenverkehr zu und von bekannten schädlichen IP-Adressen und Domänen verweigern.

Mögliche Anwendungsfälle

Dieses Szenario befasst sich mit der Notwendigkeit, die Sicherheit des ein- und ausgehenden Datenverkehrs zu und von einem Kubernetes-Cluster zu verbessern.

Vermeiden des asymmetrischen Routings

In dieser Lösung wird Azure Firewall in einem Hub-VNet bereitgestellt. Der private AKS-Cluster wird in einem Spoke-VNet bereitgestellt. Azure Firewall steuert den ausgehenden Datenverkehr mithilfe von Netzwerk- und Anwendungsregelsammlungen. In dieser Situation müssen Sie den eingehenden Datenverkehr zu jedem öffentlichen Endpunkt, der von einem in AKS ausgeführten Dienst verfügbar gemacht wird, so konfigurieren, dass er über eine der von Azure Firewall verwendeten öffentlichen IP-Adressen in das System gelangt.

Pakete kommen an der öffentlichen IP-Adresse der Firewall an, kehren aber über die private IP-Adresse mithilfe der Standardroute zur Firewall zurück. Das ist ein Problem. Um es zu vermeiden, erstellen Sie eine weitere benutzerdefinierte Route für die öffentliche IP-Adresse der Firewall, wie in der folgenden Abbildung gezeigt. Pakete, die an die öffentliche IP-Adresse der Firewall gesendet werden, werden über das Internet geroutet. Durch diese Konfiguration wird die Standardroute zur privaten IP-Adresse der Firewall vermieden.

Um den Datenverkehr Ihrer AKS-Workloads an die Azure-Firewall im Hub-VNet zu leiten, müssen Sie folgende Schritte ausführen:

Erstellen Sie eine Routingtabelle, und ordnen Sie sie jedem Subnetz zu, das die Workerknoten Ihres Clusters hostet.
Erstellen Sie eine benutzerdefinierte Route, um den Datenverkehr für 0.0.0.0/0 CIDR an die private IP-Adresse der Azure-Firewall weiterzuleiten. Geben Sie unter Typ des nächsten Hops die Option Virtuelles Gerät an.

Weitere Informationen finden Sie im Tutorial: Bereitstellen und Konfigurieren von Azure Firewall über das Azure-Portal.

Weitere Informationen finden Sie unter:

Bereitstellen von Workloads auf einem privaten AKS-Cluster bei Verwendung von Azure DevOps

Wenn Sie Azure DevOps verwenden, können Sie von Microsoft gehostete Azure DevOps-Agents nicht verwenden, um Ihre Workloads in einem privaten AKS-Cluster bereitzustellen. Sie haben keinen Zugriff auf ihren API-Server. Um Workloads in Ihrem privaten AKS-Cluster bereitzustellen, müssen Sie in Azure DevOps einen selbstgehosteten Agent im VNet Ihres privaten AKS-Clusters oder in einem virtuellen Netzwerk mit Peering bereitstellen und verwenden. Im letzteren Fall müssen Sie eine VNet-Verbindung zwischen der privaten DNS-Zone des AKS-Clusters in der Knotenressourcengruppe und dem VNet erstellen, das den selbstgehosteten Agent für Azure DevOps hostet.

Sie können einen einzelnen Azure DevOps-Agent für Windows oder Linux auf einer VM bereitstellen oder eine VM-Skalierungsgruppe verwenden. Weitere Informationen finden Sie unter Azure Virtual Machine Scale Sets-Agents. Alternativ können Sie in Azure Pipelines einen selbstgehosteten Agent einrichten, der in einem Windows Server Core-Container (für Windows-Hosts) oder einem Ubuntu-Container (für Linux-Hosts) mit Docker ausgeführt wird. Stellen Sie ihn als Pod mit einem oder mehreren Replikaten in Ihrem privaten AKS-Cluster bereit. Weitere Informationen finden Sie unter:

Wenn die Subnetze, die die Knotenpools Ihres privaten AKS-Clusters hosten, so konfiguriert sind, dass sie den ausgehenden Datenverkehr über eine Routingtabelle und eine benutzerdefinierte Route an eine Azure-Firewall weiterleiten, stellen Sie sicher, dass Sie die richtigen Anwendungs- und Netzwerkregeln erstellen. Diese Regeln müssen dem Agent Zugriff auf externe Websites zum Herunterladen und Installieren von Tools wie Docker, Kubectl, Azure CLI und Helm auf der Agent-VM ermöglichen. Weitere Informationen finden Sie unter Ausführen eines selbstgehosteten Agenten in Docker.

Alternativ können Sie einen verwalteten DevOps-Pool (Managed DevOps Pool, MDP) im virtuellen Netzwerk, das Ihren AKS-Cluster hostet, oder in einem virtuellen Netzwerk mit Peering konfigurieren. Der Managed DevOps Pools-Dienst ermöglicht es Entwicklungsteams, Azure DevOps-Agent-Pools zu erstellen, die auf ihre spezifischen Anforderungen zugeschnitten sind. Der Dienst implementiert bewährte Methoden für die Sicherheit, bietet Optionen zum Erreichen eines ausgewogenen Verhältnisses zwischen Kosten und Leistung, stellt Pfade für gängige Szenarien bereit und reduziert den Zeitaufwand für das Erstellen und Verwalten von benutzerdefinierten Pools erheblich. Weitere Informationen finden Sie unter Übersicht über die Architektur von Microsoft Managed DevOps Pools.

Sie können Agents aus einem verwalteten DevOps-Pool in Ihrem virtuellen Netzwerk hinzufügen, sodass Continuous Integration und Continuous Delivery (CI/CD)-Pipelines mit dem Kubernetes-API-Server Ihres privaten AKS-Clusters interagieren und auf Azure-Ressourcen (z. B. Azure Container Registry) zugreifen können, für die der öffentliche Netzwerkzugriff deaktiviert ist und die nur über einen privaten Endpunkt erreicht werden können, der im selben virtuellen Netzwerk oder in einem Netzwerk mit Peering definiert ist. Weitere Informationen finden Sie im Artikel zum Konfigurieren von Managed DevOps Pools-Netzwerken.

Verwenden von Azure Firewall vor einer öffentlichen Load Balancer Standard-Instanz

Ressourcendefinitionen in den Terraform-Modulen verwenden das Lebenszyklusmetaargument , um Aktionen anzupassen, wenn Azure-Ressourcen außerhalb des Terraform-Steuerelements geändert werden. Das Argument ignore_changes wird verwendet, um Terraform anzuweisen, Aktualisierungen bestimmter Ressourceneigenschaften, wie z. B. Tags, zu ignorieren. Die Ressourcendefinition der Azure Firewall-Richtlinien enthält den Block „lifecycle“, um zu verhindern, dass Terraform die Ressource aktualisiert, wenn eine Regelsammlung oder eine einzelne Regel erstellt, aktualisiert oder gelöscht wird. Ebenso enthält die Azure-Routentabelle den Block „lifecycle“, um zu verhindern, dass Terraform die Ressource aktualisiert, wenn eine benutzerdefinierte Route erstellt, gelöscht oder aktualisiert wird. Damit können Sie die DNAT-, Anwendungs- und Netzwerkregeln einer Azure Firewall-Richtlinie und die benutzerdefinierten Routen einer Azure Routing-Tabelle außerhalb der Kontrolle von Terraform verwalten.

Dieses Diagramm zeigt die Netzwerktopologie des Beispiels:

Hier ist der Nachrichtenfluss:

Eine Anforderung für die von AKS gehostete Webanwendung wird an eine öffentliche IP-Adresse gesendet, die von Azure Firewall über die Konfiguration einer öffentlichen IP-Adresse verfügbar gemacht wird. Sowohl die öffentliche IP-Adresse als auch ihre Konfiguration sind dediziert für diese Workload gedacht.
Eine DNAT-Regel für Azure Firewall übersetzt die öffentliche IP-Adresse und den Port für Azure Firewall in die öffentliche IP-Adresse und den Port, die von der Workload im öffentlichen Load Balancer Standard von Kubernetes des AKS-Clusters in der Knotenressourcengruppe verwendet werden.
Der Lastenausgleich sendet die Anforderung an einen der Kubernetes-Dienstpods, der auf einem der Agent-Knoten des AKS-Clusters ausgeführt wird.
Die Antwortnachricht wird über eine benutzerdefinierte Route an den ursprünglichen Aufrufer zurückgesendet. Die öffentliche IP-Adresse von Azure Firewall ist das Adresspräfix, und Internet ist Typ des nächsten Hops.
Jeder von der Workload ausgelöste ausgehende Aufruf wird über die benutzerdefinierte Standardroute an die private IP-Adresse der Azure-Firewall geroutet. 0.0.0.0/0 ist das Adresspräfix, und Virtuelles Gerät ist Typ des nächsten Hops.

Verwenden von Azure Firewall vor einer internen Load Balancer Standard-Instanz

In diesem Szenario wird eine ASP.NET Core-Anwendung als Dienst von einem AKS-Cluster gehostet und von einem NGINX-Eingangscontroller bereitgestellt. Der NGINX-Eingangsdatencontroller wird über einen internen Lastenausgleich mit privater IP-Adresse im Spoke-VNet verfügbar gemacht, das den AKS-Cluster hostet. Weitere Informationen finden Sie unter Erstellen eines Eingangsdatencontrollers für ein internes virtuellen Netzwerk in AKS. Wenn Sie einen NGINX-Eingangsdatencontroller oder allgemeiner einen LoadBalancer- oder ClusterIP-Dienst mit der Anmerkung service.beta.kubernetes.io/azure-load-balancer-internal: "true" im Abschnitt mit den Metadaten bereitstellen, wird ein interner Standardlastenausgleich namens kubernetes-internal unter der Knotenressourcengruppe erstellt. Weitere Informationen finden Sie unter Verwenden eines internen Lastenausgleichs mit AKS. Wie im folgenden Diagramm dargestellt, wird die Testwebanwendung von der Azure-Firewall mit einer dedizierten öffentlichen Azure-IP verfügbar gemacht.

Hier ist der Nachrichtenfluss:

Eine Anforderung für die von AKS gehostete Testwebanwendung wird an eine öffentliche IP-Adresse gesendet, die von der Azure-Firewall über die Konfiguration einer öffentlichen IP-Adresse verfügbar gemacht wird. Sowohl die öffentliche IP-Adresse als auch ihre Konfiguration sind dediziert für diese Workload gedacht.
Eine DNAT-Regel für Azure Firewall übersetzt die öffentliche IP-Adresse und den Port von Azure Firewall in die private IP-Adresse und den Port, die vom NGINX-Eingangsdatencontroller in der internen Load Balancer Standard-Instanz des AKS-Clusters in der Knotenressourcengruppe verwendet werden.
Die Anforderung wird vom internen Lastenausgleich an einen der Kubernetes-Dienstpods gesendet, der auf einem der Agent-Knoten des AKS-Clusters ausgeführt wird.
Die Antwortnachricht wird über eine benutzerdefinierte Route an den ursprünglichen Aufrufer zurückgesendet. 0.0.0.0/0 ist das Adresspräfix, und Virtuelles Gerät ist Typ des nächsten Hops.
Jeder von der Workload ausgelöste ausgehende Aufruf wird über benutzerdefinierte Route zur privaten IP-Adresse geroutet.

Überlegungen

Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.

Einige der folgenden Überlegungen sind allgemeine Empfehlungen, die nicht spezifisch für den Einsatz von Azure Firewall zur Verbesserung des Schutzes eines AKS-Clusters sind. Wir sind der Ansicht, dass es sich dabei um wesentliche Voraussetzungen für diese Lösung handelt. Dies gilt für die Bereiche Sicherheit, Leistung, Verfügbarkeit und Zuverlässigkeit, Speicherung, Service Mesh und Überwachung.

Sicherheit

Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.

Die Azure-Plattform bietet verbesserten Schutz vor verschiedenen Bedrohungen wie Netzwerkangriffen und verteilten Denial-of-Service-Angriffen (DDoS). Sie sollten Web Application Firewall (WAF) einrichten, um Schutz für alle in AKS gehosteten Webanwendungen und -dienste zu bieten, die einen öffentlichen HTTPS-Endpunkt verfügbar machen. Sie müssen Schutz vor allgemeinen Bedrohungen wie Einschleusung von SQL-Befehlen, Cross-Site Scripting und anderen Webexploits bieten. Arbeiten Sie dazu mit OWASP- (Open Web Application Security Project) und benutzerdefinierten Regeln. Azure Web Application Firewall (WAF) bietet einen verbesserten zentralisierten Schutz Ihrer Webanwendungen vor häufigen Exploits und Sicherheitsrisiken. Sie können Azure WAF mit Azure Application Gateway, Azure Front Door, und Azure Content Delivery Network bereitstellen.

DDoS-Angriffe gehören zu den größten Verfügbarkeits- und Sicherheitsbedenken gegenüber Organisationen, die ihre Anwendungen in die Cloud verschieben. Ein DDoS-Angriff hat das Ziel, die Ressourcen einer Anwendung zu verbrauchen, damit sie für berechtigte Benutzer nicht mehr verfügbar ist. Jeder Endpunkt, der öffentlich über das Internet erreichbar ist, kann Ziel von DDoS-Angriffen werden. Für alle Objekte in Azure wird Schutz durch Azure DDoS-Infrastrukturschutz ohne Aufpreis geboten. Die Dimension und Kapazität des weltweit bereitgestellten Azure-Netzwerks bietet einen verbesserten Schutz gegen gängige Angriffe auf Netzwerkebene durch eine ständige Überwachung des Datenverkehrs und Gegenmaßnahmen in Echtzeit. DDoS Infrastructure Protection erfordert keine Konfiguration oder Anwendungsänderungen durch Benutzer*innen. Alle Azure-Dienste einschließlich PaaS-Dienste wie Azure DNS sind dadurch geschützt.

Azure DDoS-Netzwerkschutz, kombiniert mit bewährten Methoden für den Anwendungsentwurf, bietet erweiterte Features zur DDoS-Risikominderung, um besser vor DDoS-Angriffen zu schützen. Sie sollten Azure DDOS-Netzwerkschutz in allen virtuellen Umkreisnetzwerken aktivieren.

Es folgen einige zusätzliche Sicherheitsüberlegungen:

Erstellen Sie einen privaten Endpunkt für jeden PaaS-Dienst, der von AKS-Workloads wie Azure Key Vault, Azure Service Bus und Azure SQL-Datenbank genutzt wird. Dadurch wird der Datenverkehr zwischen den Anwendungen und diesen Diensten nicht über das öffentliche Internet verfügbar gemacht. Datenverkehr zwischen dem virtuellen Netzwerk des AKS-Clusters und einer Instanz eines PaaS-Diensts über einen privaten Endpunkt läuft über das Microsoft-Backbonenetzwerk, aber die Kommunikation wird nicht durch die Azure-Firewall geleitet. Dieser Mechanismus bietet mehr Sicherheit und besseren Schutz vor Datenlecks. Weitere Informationen finden Sie unter Was ist Azure Private Link?.
Wenn Sie Application Gateway vor dem AKS-Cluster einsetzen, nutzen Sie eine Web Application Firewall-Richtlinie, um öffentlich zugängliche Workloads, die in AKS betrieben werden, vor Angriffen zu schützen.
Mit Netzwerkrichtlinien können Sie die dienstinterne Kommunikation abtrennen und absichern, indem Sie festlegen, welche Komponenten miteinander kommunizieren dürfen. Standardmäßig können alle Pods in einem Kubernetes-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Zur Verbesserung der Sicherheit können Sie mithilfe von Azure- oder Calico-Netzwerkrichtlinien Regeln definieren, mit denen der Datenverkehrsfluss zwischen verschiedenen Microservices gesteuert wird. Weitere Informationen finden Sie unter Netzwerkrichtlinie.
Machen Sie für Ihre AKS-Knoten keine Remotekonnektivität verfügbar. Erstellen Sie einen Bastionhost oder eine Jumpbox in einem virtuellen Verwaltungsnetzwerk. Leiten Sie den Datenverkehr über den Bastionhost in Ihren AKS-Cluster.
Erwägen Sie die Verwendung eines privaten AKS-Clusters in Ihrer Produktionsumgebung oder zumindest sicheren Zugriff auf den API-Server mithilfe autorisierter IP-Adressbereiche in AKS. Wenn Sie autorisierte IP-Adressbereiche in einem öffentlichen Cluster verwenden, lassen Sie alle ausgehenden IP-Adressen in der Netzwerkregelsammlung für Azure Firewall zu. Clusterinterne Vorgänge nutzen den Kubernetes-API-Server.
Wenn Sie DNS-Proxy in Azure Firewall aktivieren, kann Azure Firewall DNS-Abfragen von einem oder mehreren virtuellen Netzwerken verarbeiten und an einen von Ihnen gewählten DNS-Server weiterleiten. Diese Funktion ist für eine zuverlässige FQDN-Filterung in Netzwerkregeln unerlässlich. Sie können den DNS-Proxy in den Einstellungen von Azure Firewall und Firewall-Richtlinien aktivieren. Weitere Informationen zu DNS-Proxyprotokollen finden Sie unter Azure Firewall-Protokoll und -Metriken.
Wenn Sie Azure Firewall vor Application Gateway einsetzen, können Sie Ihre Kubernetes-Eingangsressource so konfigurieren, dass Workloads über HTTPS verfügbar gemacht werden, und für jeden Mandanten eine eigene Unterdomäne und ein digitales Zertifikat verwenden. Der Application Gateway Ingress Controller (AGIC) konfiguriert automatisch den Anwendungsgatewaylistener für die SSL-Beendigung.
Sie können Azure Firewall vor einem Dienstproxy wie dem NGINX-Eingangsdatencontroller einsetzen. Dieser Controller stellt für Kubernetes-Dienste Reverseproxys, konfigurierbares Datenverkehrsrouting und TLS-Abschluss bereit. Mithilfe von Ressourcen für eingehende Kubernetes-Daten werden Eingangsregeln und Routen für einzelne Kubernetes-Dienste konfiguriert. Durch Verwendung eines Eingangsdatencontrollers und von Eingangsregeln kann eine einzelne IP-Adresse zum Weiterleiten von Datenverkehr an mehrere Dienste in einem Kubernetes-Cluster genutzt werden. Sie können die TLS-Zertifikate mithilfe einer anerkannten Zertifizierungsstelle generieren. Alternativ können Sie mithilfe von Let's Encrypt automatisch TLS-Zertifikate mit einer dynamischen oder statischen öffentlichen IP-Adresse generieren lassen. Weitere Informationen finden Sie unter Erstellen eines HTTPS-Eingangsdatencontrollers und Verwenden Ihrer eigenen TLS-Zertifikate in AKS.
Eine sorgfältige Koordination zwischen dem Azure Firewall-Operator und den Cluster- und Workloadteams ist sowohl für die anfängliche Bereitstellung des Clusters als auch im laufenden Betrieb erforderlich, sobald sich die Anforderungen an Workload und Cluster ändern. Dies gilt insbesondere, wenn Sie die Authentifizierungsmechanismen wie OAuth 2.0 und OpenID Connect konfigurieren, die von Workloads zur Authentifizierung ihrer Clients verwendet werden.
Beachten Sie die folgenden Leitlinien, um die in diesem Artikel beschriebene Umgebung abzusichern:

Verfügbarkeit und Zuverlässigkeit

Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.

Die Überlegungen zu Verfügbarkeit und Zuverlässigkeit sind nicht spezifisch für Mehrinstanzenfähigkeit in AKS. Wir sind der Ansicht, dass es sich dabei um wesentliche Voraussetzungen für diese Lösung handelt. Erwägen Sie die folgenden Methoden zum Optimieren der Verfügbarkeit Ihres AKS-Clusters und Ihrer Workloads.

Intraregionale Resilienz

Während der Bereitstellung können Sie Azure Firewall für mehrere Verfügbarkeitszonen konfigurieren, um die Verfügbarkeit zu erhöhen. Prozentuale Angaben zur Betriebszeit finden Sie in der SLA für Azure Firewall. Sie können Azure Firewall auch einer bestimmten Zone zuordnen, um eine gewisse Nähe zu gewährleisten. Allerdings wirkt sich diese Konfiguration auf die SLA aus. Bei einer Firewall, die in einer Verfügbarkeitszone bereitgestellt wird sowie bei Datenübertragungen zwischen Verfügbarkeitszonen fallen keine Gebühren an.
Erwägen Sie, die Knotenpools Ihres AKS-Clusters in allen Verfügbarkeitszonen einer Region bereitzustellen. Setzen Sie Azure Load Balancer Standard oder Application Gateway vor den Knotenpools ein. Diese Topologie bietet bessere Resilienz, wenn es zu einem Ausfall eines einzelnen Rechenzentrums kommt. Die Clusterknoten werden auf mehrere Rechenzentren, d. h. drei separate Verfügbarkeitszonen innerhalb einer Region, verteilt.
Aktivieren Sie Zonenredundanz in Container Registry für Resilienz und Hochverfügbarkeit innerhalb der jeweiligen Region.
Nutzen Sie Topologieverteilungseinschränkungen für Pods, um zu steuern, wie Pods in Ihrem AKS-Cluster auf Fehlerdomänen wie Regionen, Verfügbarkeitszonen und Knoten verteilt werden.
Ziehen Sie die Verwendung der Betriebszeit-SLA für AKS-Cluster in Erwägung, die unternehmenskritische Workloads hosten. Eine SLA für Betriebszeit ist ein optionales Feature, das eine finanziell abgesicherte, höhere SLA für einen Cluster ermöglicht. Die SLA für Betriebszeit garantiert eine Verfügbarkeit von 99,95 % des Kubernetes-API-Serverendpunkts für Cluster mit Verfügbarkeitszonen. Sie eignet sich auch für Cluster ohne Verfügbarkeitszonen, aber dann ist das SLA-Ziel niedriger. Details zur SLA finden Sie unter SLA zur Betriebszeit. AKS verwendet Masterknotenreplikate über Update- und Fehlerdomänen hinweg, um sicherzustellen, dass die SLA-Anforderungen erfüllt werden.

Notfallwiederherstellung und Geschäftskontinuität

Ziehen Sie die Bereitstellung Ihrer Lösung in mindestens zwei gekoppelten Azure-Regionen innerhalb einer Geografie in Erwägung. Nutzen Sie einen globalen Lastenausgleich wie Azure Traffic Manager oder Azure Front Door mit einer Aktiv/Aktiv- oder Aktiv/Passiv-Routingmethode, um Geschäftskontinuität und Notfallwiederherstellung sicherzustellen.
Azure Firewall ist ein regionaler Dienst. Wenn Sie Ihre Lösung in zwei oder mehr Regionen bereitstellen, müssen Sie in jeder Region eine Azure-Firewall einrichten. Sie können eine globale Azure Firewall-Richtlinie mit von der Organisation vorgegebenen Regeln erstellen, die für alle regionalen Hubs gelten sollen. Diese Richtlinie kann als übergeordnete Richtlinie für regionale Azure-Richtlinien fungieren. Richtlinien, die mit nicht leeren übergeordneten Richtlinien erstellt werden, erben alle Regelsammlungen der übergeordneten Richtlinie. Netzwerkregelsammlungen, die von einer übergeordneten Richtlinie geerbt wurden, haben stets Vorrang vor Netzwerkregelsammlungen, die als Teil Ihrer neuen Richtlinie definiert werden. Gleiches gilt für Anwendungsregelsammlungen. Allerdings werden Netzwerkregelsammlungen unabhängig von der Vererbung stets vor Anwendungsregelsammlungen verarbeitet. Weitere Informationen zu Standard- und Premium-Richtlinien finden Sie unter Übersicht über Azure Firewall Manager-Richtlinien.
Stellen Sie sicher, dass Sie jeden regionalen Failoverprozess in einer Qualitätssicherungsumgebung ein Skript und eine Dokumentation erstellen und ihn regelmäßig testen. Auf diese Weise lassen sich unvorhersehbare Probleme vermeiden, wenn ein zentraler Dienst von einem Ausfall in der primären Region betroffen ist. Bei diesen Tests wird auch geprüft, ob der Ansatz für die Notfallwiederherstellung RPO/RTO-Ziele erfüllt, in Verbindung mit etwaigen manuellen Prozessen und Eingriffen, die für ein Failover erforderlich sind.
Testen Sie unbedingt die Failbackverfahren, um zu überprüfen, ob sie wie erwartet funktionieren.
Speichern Sie Ihre Containerimages in Container Registry. Führen Sie für jede AKS-Region eine Georeplikation der Registrierung durch. Weitere Informationen finden Sie unter Georeplikation in Azure Container Registry.
Vermeiden Sie nach Möglichkeit das Speichern des Dienststatus im Container. Verwenden Sie stattdessen eine Azure-PaaS-Lösung, die die Replikation in mehreren Regionen unterstützt.
Wenn Sie Azure Storage verwenden, sollten Sie einen Prozess für die Migration Ihres Speichers aus der primären Region in die Sicherungsregion vorbereiten und testen.

Optimaler Betrieb

Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.

DevOps

Stellen Sie Ihre Workloads in AKS bereit, indem Sie ein Helm-Diagramm in einer CI/CD-Pipeline (Continuous Integration and Continuous Delivery) verwenden. Nutzen Sie ein DevOps-System wie GitHub Actions oder Azure DevOps. Weitere Informationen finden Sie unter Erstellen und Bereitstellen in Azure Kubernetes Service.
Um eine Anwendung ordnungsgemäß zu testen, bevor Sie sie Benutzern zur Verfügung stellen, verwenden Sie im Rahmen der Lebenszyklusverwaltung Ihrer Anwendung A/B-Tests und Canary-Bereitstellungen. Es gibt mehrere Methoden, mit denen Sie den Datenverkehr auf verschiedene Versionen desselben Diensts aufteilen können. Alternativ können Sie für die Aufteilung des Datenverkehrs die Funktionen verwenden, die von einer Service Mesh-Implementierung bereitgestellt werden. Weitere Informationen finden Sie unter Linkerd Traffic Split und Istio Traffic Management.
Verwenden Sie Azure Container Registry oder eine andere Containerregistrierung (wie Docker Hub), um die privaten Docker-Images zu speichern, die im Cluster bereitgestellt werden. AKS kann die Authentifizierung per Azure Container Registry mit seiner eigenen Microsoft Entra-Identität durchführen.
Testen Sie den Dateneingang und -ausgang Ihrer Workloads in einer separaten Vorproduktionsumgebung, die die Netzwerktopologie und Firewallregeln Ihrer Produktionsumgebung widerspiegelt. Eine gestaffelte Rolloutstrategie hilft Ihnen, eventuelle Netzwerk- oder Sicherheitsprobleme zu erkennen, ehe ein neues Feature oder eine neue Netzwerkregel in die Produktionsumgebung übergeht.

Überwachung

Azure Firewall und Azure Monitor sind vollständig integriert, um den von der Firewall verarbeiteten ein- und ausgehenden Datenverkehr zu protokollieren. Weitere Informationen finden Sie unter Threat Intelligence-gestütztes Filtern für Azure Firewall.

Die folgenden Überlegungen zur Überwachung sind nicht spezifisch für die Mehrinstanzenfähigkeit in AKS, aber wir sind der Ansicht, dass sie wesentliche Voraussetzungen für diese Lösung sind.

Verwenden Sie Container Insights, um den Integritätsstatus des AKS-Clusters und der Workloads zu überwachen.
Konfigurieren Sie alle PaaS-Dienste (z. B. Container Registry und Key Vault) so, dass Diagnoseprotokolle und Metriken gesammelt werden.

Kostenoptimierung

Die Kosten der resultierenden Architektur hängen von den folgenden Konfigurationsdetails ab:

Dienstebenen
Skalierbarkeit (die Anzahl von Instanzen, die von Diensten dynamisch zugeordnet werden, um einen bestimmten Bedarf zu unterstützen)
Automatisierungsskripts
Ihrer Notfallwiederherstellungsebene

Nachdem Sie diese Konfigurationsdetails geprüft haben, schätzen Sie Ihre Kosten mit dem Azure-Preisrechner. Weitere Optionen zur Kostenoptimierung finden Sie im Microsoft Azure Well-Architected Framework unter Grundsätze der Kostenoptimierung.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

Paolo Salvadori | Principal Service Engineer

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Freigeben über