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 dient zur Überprüfung des Datenverkehrs zum und vom Azure Kubernetes Service-Cluster (AKS). 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.

Workflow

Terraform-Module dienen zur Bereitstellung eines neuen virtuellen Netzwerks mit vier Subnetzen, die Folgendes hosten:

Den AKS-Cluster (AksSubnet)
Eine Jumpbox-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 verbesserte SSH-Sicherheitskonnektivität mit der Jumpbox-VM über SSL. Azure Container Registry dient zum Erstellen, Speichern und Verwalten von Containerimages und Artefakten (wie Helm-Diagrammen).

Zur Architektur gehört eine Azure-Firewall, die zur Steuerung des ein- und ausgehenden Datenverkehrs mithilfe von DNAT-, Netzwerk- und Anwendungsregeln dient. Sie trägt auch zum Schutz von Workloads bei, indem eine auf Threat Intelligence basierende Filterung zum Einsatz kommt. Azure Firewall und Azure Bastion werden in einem Hub-VNet bereitgestellt, das mittels Peering mit dem virtuellen Netzwerk gekoppelt ist, das den privaten AKS-Cluster hostet. Eine Routingtabelle und benutzerdefinierte Routen werden verwendet, um den ausgehenden Datenverkehr aus dem privaten AKS-Cluster an die Azure-Firewall weiterzuleiten.

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. Mit Azure Private Link können AKS-Workloads über einen privaten Endpunkt im virtuellen Netzwerk auf Azure-PaaS-Dienste wie Azure Key Vault zugreifen.

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

Azure Blob Storage-Konto
Containerregistrierung
Key Vault
Den API-Server des Kubernetes-Clusters

Es gibt eine virtuelle Netzwerkverbindung zwischen den Hub-and-Spoke-VNets, die den AKS-Cluster hosten, und den zuvor beschriebenen privaten DNS-Zonen.

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. Es ist eine vollständig zustandsbehaftete Firewall-as-a-Service mit integrierter Hochverfügbarkeit und uneingeschränkter Cloudskalierbarkeit. Sie ermöglicht die Untersuchung von Ost-West- und Nord-Süd-Datenverkehr.
Azure Container Registry ist ein verwalteter, privater Docker-Registrierungsdienst, der auf Version 2.0 der Open-Source-Docker-Registrierung basiert. Sie können Azure-Containerregistrierungen mit Ihren vorhandenen Pipelines für die Containerentwicklung und -bereitstellung verwenden, oder Azure Container Registry-Aufgaben nutzen, um Containerimages in Azure zu erstellen.
Azure Kubernetes Services vereinfacht die Bereitstellung eines Managed Kubernetes-Clusters in Azure, indem der betriebliche Aufwand in Azure ausgelagert wird. Azure übernimmt als gehosteter Kubernetes-Dienst wichtige Aufgaben, z. B. Systemüberwachung und -wartung. Da Kubernetes-Master von Azure verwaltet werden, müssen Sie sich nur um die Verwaltung und Wartung der Agent-Knoten kümmern.
In Azure Key Vault werden Geheimnisse wie API-Schlüssel, Kennwörter, Zertifikate und kryptografische Schlüssel mit verbesserter Sicherheit gespeichert und der Zugriff darauf gesteuert. Dank Key Vault können Sie öffentliche und private TLS-/SSL-Zertifikate (Transport Layer Security/Secure Sockets Layer) für die Verwendung mit Azure und Ihren internen verbundenen Ressourcen mühelos bereitstellen und verwalten.
Azure Bastion ist ein vollständig verwalteter PaaS-Dienst (Platform as a Service), den Sie in Ihrem virtuellen Netzwerk bereitstellen können. Azure Bastion bietet über Remotedesktopprotokoll (RDP) und Secure Shell (SSH) ein jetzt noch sicherere nahtlose Konnektivität mit den VMs in Ihrem virtuellen Netzwerk, und zwar direkt im Azure-Portal mittels TLS.
Azure Virtual Machines bietet bedarfsgesteuerte, skalierbare Computingressourcen mit der Flexibilität der Virtualisierung.
Azure Virtual Network ist der grundlegende Baustein für private Azure-Netzwerke. Dank Microsoft Azure Virtual Network können Azure-Ressourcen (wie VMs) nun sicherer untereinander sowie mit dem Internet und mit lokalen Netzwerken kommunizieren. Eine Azure Virtual Network-Instanz ähnelt einem herkömmlichen lokalen Netzwerk, bietet aber die Vorteile der Azure-Infrastruktur wie Skalierbarkeit, Verfügbarkeit und Isolation.
Virtuelle Netzwerkschnittstellen ermöglichen Azure-VMs die Kommunikation mit dem Internet, Azure und lokalen Ressourcen. 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.
Azure Managed Disks bietet Speichervolumes auf Blockebene, die Azure auf Azure-VMs verwaltet. Ultra-, Premium-SSD- und Standard-SSD-Datenträger sowie Standard-Festplattenlaufwerke (HDDs) sind verfügbar.
Azure Blob Storage ist eine Objektspeicherlösung für die Cloud. Blob Storage ist für die Speicherung großer Mengen unstrukturierter Daten optimiert.
Private Link ermöglicht Ihnen den Zugriff auf Azure PaaS-Dienste (z. B. Blob Storage und Key Vault) über einen privaten Endpunkt in Ihrem virtuellen Netzwerk. Sie können damit auch auf von Azure gehostete Dienste zugreifen, die Sie selbst besitzen oder die von einem Microsoft-Partner bereitgestellt werden.

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

In einer Produktionsumgebung sollte die Kommunikation mit einem Kubernetes-Cluster durch eine Firewall geschützt werden, die den ein- und ausgehenden Netzwerkdatenverkehr auf Grundlage festgelegter Sicherheitsregeln überwacht und steuert. Eine Firewall errichtet normalerweise eine Barriere zwischen einem vertrauenswürdigen Netzwerk und einem nicht vertrauenswürdigen Netzwerk wie dem Internet.

Sie können einen privaten AKS-Cluster mithilfe von Terraform und Azure DevOps in einer Hub-and-Spoke-Netzwerktopologie bereitstellen. Azure Firewall dient zur Überprüfung des Datenverkehrs zum und vom Azure Kubernetes Service-Cluster (AKS). 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 that shows features of the three Azure Firewall SKUs

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 treffen an der öffentlichen IP-Adresse der Firewall ein, kehren aber über die private IP-Adresse (unter Verwendung 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 in einem privaten AKS-Cluster bei Verwendung von Azure DevOps

Wenn Sie Azure DevOps verwenden, beachten Sie, dass Sie in Azure DevOps keine von Microsoft gehostete Agents nutzen können, 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 Agents in Docker und Erstellen und Bereitstellen von Azure DevOps-Pipeline-Agents in AKS.

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

Ressourcendefinitionen in den Terraform-Modulen verwenden das Meta-Argument lifecycle, um Aktionen anzupassen, wenn Azure-Ressourcen außerhalb der Kontrolle von Terraform 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.

Das zu diesem Artikel gehörende Beispiel enthält eine Azure DevOps-CD-Pipeline, die zeigt, wie Sie eine Workload in einem privaten AKS-Cluster bereitstellen, indem Sie eine Azure DevOps-Pipeline verwenden, die in einem selbstgehosteten Agent ausgeführt wird. In diesem Beispiel wird redmine, die Webanwendung für Projektmanagement von Bitnami, mithilfe eines öffentlichen Helm-Diagramms bereitgestellt. 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.

Weitere Informationen finden Sie unter Verwenden von Azure Firewall vor der öffentlichen Load Balancer Standard-Instanz des AKS-Clusters.

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

In dem Beispiel zu diesem Artikel wird eine ASP.NET Core-Anwendung als Dienst von einem AKS-Cluster gehostet und von einem NGINX-Eingangscontroller nach außen verfügbar gemacht. 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 gezeigt, wird die Testwebanwendung von der Azure-Firewall über eine dedizierte öffentliche Azure-IP-Adresse 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.

Weitere Informationen finden Sie unter Verwenden von Azure Firewall vor einer internen Load Balancer Standard-Instanz.

Ü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 Bedrohungen hinsichtlich Verfügbarkeit und Sicherheit für Organisationen, die ihre Anwendungen in die Cloud verlagern. 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.
Ziehen Sie die Nutzung eines privaten AKS-Clusters in Ihrer Produktionsumgebung oder zumindest einen sicheren Zugriff auf den API-Server in Erwägung, indem Sie autorisierte IP-Adressbereiche in AKS einsetzen. 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-Eingangsdatencontroller (AGIC) konfiguriert den Azure Application Gateway-Listener automatisch für den SSL-Abschluss (Secure Sockets Layer).
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. Für eine in einer Verfügbarkeitszone bereitgestellte Firewall fallen keine zusätzlichen Kosten an. Es fallen jedoch zusätzliche Kosten für ein- und ausgehende Datenübertragungen an, die mit Verfügbarkeitszonen verbunden sind. Weitere Informationen finden Sie unter Preisübersicht Bandbreite.
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.

Bereitstellen dieses Szenarios

Den Quellcode für dieses Szenario finden Sie auf GitHub. Es handelt sich hierbei um eine Open-Source-Lösung, die zusammen mit einer MIT-Lizenz bereitgestellt wird.

Voraussetzungen

Für Onlinebereitstellungen benötigen Sie ein Azure-Konto. Sollten Sie keins besitzen, erstellen Sie ein kostenloses Azure-Konto, bevor Sie beginnen. Sie müssen diese Anforderungen erfüllen, ehe Sie Terraform-Module mithilfe von Azure DevOps bereitstellen können:

Speichern Sie die Terraform-Statusdatei in einem Azure-Speicherkonto. Weitere Informationen über die Verwendung eines Speicherkontos zum Speichern von Terraform-Status, zu Statussperren und zur Verschlüsselung ruhender Daten finden Sie unter Speichern des Terraform-Status in Azure Storage.
Erstellen Sie ein Azure DevOps-Projekt. Weitere Informationen finden Sie unter Erstellen eines Projekts in Azure DevOps.
Erstellen Sie eine Azure DevOps-Dienstverbindung mit Ihrem Azure-Abonnement. Sie können die Dienstprinzipalauthentifizierung (Service Principal Authentication, SPA) oder eine verwaltete Azure-Dienstidentität verwenden, wenn Sie die Dienstverbindung erstellen. Stellen Sie in jedem Fall sicher, dass dem Dienstprinzipal oder der verwalteten Identität, die von Azure DevOps verwendet wird, um sich mit Ihrem Azure-Abonnement zu verbinden, die Rolle „Besitzer“ für das gesamte Abonnement zugewiesen ist.

Bereitstellen in Azure

Halten Sie die Informationen zu Ihrem Azure-Abonnement bereit.

Klonen Sie das GitHub-Repository „workbench“:

git clone https://github.com/Azure-Samples/private-aks-cluster-terraform-devops.git

Befolgen Sie die Anweisungen in der Datei README.md.

Beitragende

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

Hauptautor:

Paolo Salvatori | Principal Service Engineer

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

Nächste Schritte

Prüfen Sie die Empfehlungen und bewährten Methoden für AKS im Microsoft Azure Well-Architected Framework:

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