Verwenden von Azure Firewall zum Schutz eines AKS-Clusters

In diesem Leitfaden wird beschrieben, wie Sie einen privaten Azure Kubernetes Service (AKS) Cluster in einer Hub-Spoke-Netzwerktopologie mithilfe von Terraform und Azure DevOps erstellen. Azure Firewall prüft den Datenverkehr zum und vom AKS-Cluster. Das virtuelle Hub-Netzwerk ist mit einem oder mehreren virtuellen Spoke-Netzwerken verbunden, in denen der Cluster gehostet wird.

Aufbau

Laden Sie eine Visio-Datei dieser Architektur herunter.

Workflow

Der folgende Workflow entspricht dem vorherigen Diagramm:

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).
Azure Application Gateway Web Application Firewall v2 (AppGatewaySubnet).
Azure Bastion (AzureBastionSubnet)

Der AKS-Cluster verwendet eine benutzerdefinierte verwaltete Identität, um andere Ressourcen wie Lastenausgleichsgeräte und verwaltete Datenträger in Azure zu erstellen. Mithilfe von Terraform-Modulen können Sie optional einen AKS-Cluster mit den folgenden Features bereitstellen:

Der AKS-Cluster besteht aus:

Ein Systemknotenpool, der nur kritische System pods und Dienste hostet.
Ein Benutzerknotenpool, der Benutzerarbeitsauslastungen 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 diese VM verwenden, um den Cluster über das Befehlszeilentool Kubernetes zu verwalten. Ein Azure Storage Konto speichert die VM-Startdiagnoseprotokolle.

Ein Azure Bastion-Host bietet Secure Shell-(SSH)-Konnektivität mit erhöhter Sicherheit zur Jumpbox-VM. Azure Container Registry wird verwendet, um Containerimages und Artefakte wie Helm-Diagramme zu erstellen, zu speichern und zu verwalten.

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

Aus diesem Grund enthält die Architektur in diesem Artikel eine Azure Firewall, die eingehenden Datenverkehr mithilfe von DNAT-Regeln (Destination Network Address Translation) und ausgehendem Datenverkehr mit Netzwerk- und Anwendungsregeln steuert. Die Firewall wendet die Quellnetzwerkadressenübersetzung (Source Network Address Translation, SNAT) auf ausgehende Flüsse aus dem Cluster an. Dabei wird die Pod-IP-Adresse durch eine der öffentlichen IP-Adressen der Firewall ersetzt, die dann als Egress-Identität des Clusters für das Allowlisting durch Partner dient. Die Firewall schützt workloads auch mithilfe der bedrohungsintelligenzbasierten Filterung. Azure Firewall und Azure Bastion werden in einem virtuellen Hubnetz bereitgestellt, das per Peering mit dem virtuellen Netzwerk verbunden ist, das den privaten AKS-Cluster beherbergt. Eine Routentabelle und benutzerdefinierte Routen (UDRs) leiten ausgehenden Datenverkehr vom AKS-Cluster zu Azure Firewall.

Hinweis

Es wird dringend empfohlen, Azure Firewall Premium zu verwenden, da es erweiterten Bedrohungsschutz bietet.

Workloads, die auf AKS ausgeführt werden, verwenden Azure Key Vault als geheimer Speicher zum Abrufen von Schlüsseln, Zertifikaten und geheimen Schlüsseln über die Microsoft Entra Workload Identity, Secrets Store CSI Driver oder Dapr. Azure Private Link ermöglicht AKS-Workloads den Zugriff auf Azure Plattform as a Service (PaaS)-Dienste wie Key Vault über einen privaten Endpunkt im virtuellen Netzwerk.

Die Topologie umfasst private Endpunkte und DNS-Zonen (Private Domain Name System) für diese Dienste:

Eine virtuelle Netzwerkverbindung verbindet das virtuelle Netzwerk, in dem der AKS-Cluster mit den zuvor beschriebenen privaten DNS-Zonen gehostet wird.

Ein Log Analytics Arbeitsbereich sammelt die Diagnoseprotokolle und Metriken aus Azure Diensten.

Components

Azure Firewall ist ein cloudeigener, intelligenter Netzwerkfirewall-Sicherheitsdienst, der Bedrohungsschutz für Cloud-Workloads bereitstellt, die in Azure ausgeführt werden. In dieser Architektur bietet Azure Firewall sowohl Ost-West- als auch Nord-Süd-Verkehrskontrollen. Es verwendet DNAT-Regeln, um eingehende Flüsse in privaten Workloads, Netzwerk- und Anwendungsregeln zu veröffentlichen, um ausgehende Flüsse zu filtern, und SNAT, um den Ausgehenden Datenverkehr in seine öffentliche IP-Adresse zu übersetzen. Außerdem werden Workloads durch Die Verwendung von bedrohungsintelligenzbasierter Filterung im virtuellen Hubnetzwerk geschützt.
Azure Container Registry ist ein verwalteter, privater Docker-Registrierungsdienst, der auf Version 2.0 der Open-Source-Docker-Registrierung basiert. In dieser Architektur erstellt, speichert und verwaltet Container Registry Container-Images und Artefakte wie Helm-Charts, die im AKS-Cluster bereitgestellt werden. Es unterstützt georeplikation für Notfallwiederherstellungsszenarien (DR).
AKS ist ein verwalteter Kubernetes-Dienst, der die Kubernetes-Clusterbereitstellung und -verwaltung vereinfacht. In dieser Architektur hostet AKS den privaten Cluster mit System- und Benutzer-Knoten-Pools in einem virtuellen Spoke-Netzwerk.
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 verwalteter PaaS, der Remotedesktop Protocol (RDP) und SSH-Konnektivität mit den VMs in Ihrem virtuellen Netzwerk direkt über das Azure Portal über Transport Layer Security (TLS) bereitstellt. In dieser Architektur bietet Azure Bastion sichereren Zugriff auf die Sprungbox-VM über TLS ü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 Virtual Machines als Host für die Jumpbox, die im virtuellen Netzwerk bereitgestellt wird, in dem sich auch der AKS-Cluster befindet. Systemadministratoren verwenden Virtual Machines, um den privaten Cluster über Kubectl zu verwalten, wenn der direkte Zugriff auf den API-Server eingeschränkt ist.
Azure Virtual Network ist der grundlegende Baustein für private Azure-Netzwerke. Virtual Network ermöglicht es Azure-Ressourcen wie VMs, untereinander sowie mit dem Internet und lokalen Netzwerken in erhöhter Sicherheit zu kommunizieren. In dieser Architektur bietet das virtuelle Netzwerk Netzwerkisolation und Konnektivität mit dem Speichennetz, das den AKS-Cluster und Subnetze für verschiedene Komponenten hostet. Es ist mit dem Hubnetzwerk verbunden, 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 einer Azure VM mehrere NICs hinzufügen, sodass untergeordnete VMs über eigene dedizierte Netzwerkschnittstellengeräte und IP-Adressen verfügen können.
Azure verwaltete Datenträger sind Speichervolumes auf Blockebene, die von Azure auf Azure-VMs verwaltet werden. Ultra Disks, Premium SSDs, Standard-SSDs und Standard-HDDs sind verfügbar. In dieser Architektur bieten verwaltete Datenträger beständigen Speicher für die Jump Box-VM und die AKS-Clusterknoten.
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 Jumpbox-VM.
Private Link 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 dem öffentlichen Internet ausgesetzt zu sein. Sie können sie auch verwenden, um auf azure gehostete Dienste zuzugreifen, die Sie besitzen oder die ein Microsoft-Partner bereitstellt.

Alternatives

Sie können eine Firewall ohne Microsoft aus dem Microsoft Marketplace anstelle von Azure Firewall verwenden. Bei diesem Ansatz müssen Sie die Firewall ordnungsgemäß konfigurieren, um den eingehenden und ausgehenden Datenverkehr aus dem AKS-Cluster zu prüfen und zuzulassen oder zu verweigern.

Details zum Szenario

AKS-Cluster werden in einem verwalteten oder benutzerdefinierten virtuellen Netzwerk bereitgestellt. Der Cluster verfügt weiterhin über ausgehende Abhängigkeiten von Diensten außerhalb dieses Netzwerks. Für Verwaltungs- und Betriebszwecke müssen AKS-Clusterknoten auf bestimmte Ports und vollqualifizierte Domänennamen (FQDNs) zugreifen, die diesen Abhängigkeiten zugeordnet sind. Diese Anforderungen umfassen den Zugriff auf den Kubernetes-API-Server Ihres Clusters, den Zugriff auf Ports für Clusterkomponentendownloads und den Zugriff auf Microsoft Containerregistrierung, um Containerimages abzurufen. Diese ausgehenden Abhängigkeiten werden mit FQDNs definiert und verfügen nicht über statische IP-Adressen, wodurch Verhindert wird, dass ausgehender Datenverkehr mithilfe von Netzwerksicherheitsgruppen (NSGs) gesperrt wird. Daher ermöglichen AKS-Cluster standardmäßig uneingeschränkten ausgehenden Internetzugriff, sodass Knoten und Dienste erforderliche externe Ressourcen erreichen können.

In einer Produktionsumgebung ist es in der Regel jedoch vorzuziehen, den Kubernetes-Cluster vor Datenexfiltration und anderen unerwünschten Netzwerkdatenverkehr zu schützen. Der gesamte eingehende und ausgehende Netzwerkdatenverkehr muss den definierten Sicherheitsregeln entsprechen. Um diese Anforderung zu erfüllen, beschränken Sie den ausgehenden Datenverkehr und lassen Sie dabei weiterhin den Zugriff auf die erforderlichen Ports und Adressen für routinemäßige Clusterwartungsaufgaben, ausgehende Abhängigkeiten und Workloadanforderungen zu.

Eine einfache Lösung ist die Verwendung eines Firewallgeräts, das den ausgehenden Datenverkehr auf der Grundlage von Domänennamen steuern kann. Eine Firewall erstellt 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, um eine differenzierte Datenverkehrskontrolle bereitzustellen. Außerdem ermöglicht es die Zulassungsliste für FQDNs, die mit den ausgehenden Abhängigkeiten eines AKS-Clusters verbunden sind – was mit NSGs nicht möglich ist. Darüber hinaus kann bedrohungsintelligenzbasiertes Filtern auf der Azure Firewall, die in einem gemeinsam genutzten Perimeternetzwerk bereitgestellt wird, den eingehenden Datenverkehr steuern und die Sicherheit erhöhen. 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 in einer Hub-Spoke-Netzwerktopologie erstellen, indem Sie Terraform und Azure DevOps verwenden. Azure Firewall prüft den Datenverkehr zum und vom AKS-Cluster. Der Cluster wird von einem oder mehreren Spoke-Virtualnetzwerken bereitgestellt, die per Peering mit dem Hub-Virtualnetzwerk 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 hochsensible Anwendungen wie die Zahlungsverarbeitung zu sichern. Es unterstützt erweiterte Bedrohungsschutzfunktionen wie schadsoftwarebezogene Bedrohungserkennung und TLS-Inspektion.
Azure Firewall Standard wird für Kunden empfohlen, die Layer-3 bis Layer-7-Firewallfunktionen und autocaling benötigen, die Spitzendatenverkehr bis zu 30 GBit/s unterstützen. 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.

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 den ausgehenden Datenverkehr einschränken möchten, muss eine begrenzte Anzahl an Ports und Adressen weiterhin erreichbar bleiben, damit die Cluster-Wartungsaufgaben ordnungsgemäß funktionieren. Die einfachste Möglichkeit zur Bereitstellung von Sicherheit für den ausgehenden Datenverkehr von einem Kubernetes-Cluster wie AKS besteht darin, eine Softwarefirewall zu verwenden, die ausgehenden Datenverkehr basierend auf Domänennamen steuern kann. Azure Firewall kann ausgehenden HTTP- und HTTPS-Datenverkehr basierend auf den FQDN 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).

Sie können den Datenverkehr auch steuern und die Sicherheit verbessern, indem Sie bedrohungsintelligenzbasierte Filterung auf einer Azure Firewall, die in einem freigegebenen Umkreisnetzwerk bereitgestellt wird, aktivieren. Diese Filterung kann Warnungen ausgeben und den Datenverkehr zu und von bekannten schädlichen IP-Adressen und Domänen verweigern.

Potenzielle Anwendungsfälle

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

Konfigurieren des AKS-Clusters für den Ausgang über Azure Firewall

Um den AKS-Ausgang durch Azure Firewall zu erzwingen, müssen Sie den Cluster konfigurieren, nicht nur die Firewall und die Routentabelle. Treffen Sie beim Erstellen des Clusters die folgenden Entscheidungen:

Legen Sie den ausgehenden Typ auf userDefinedRouting fest. Mit diesem ausgehenden Typ stellt AKS keinen öffentlichen Standardlastenausgleich für den Ausgang bereit und fügt keine eigenen öffentlichen SNAT-IP-Adressen hinzu. Der gesamte ausgehende Datenverkehr aus den Knoten-Pools folgt der UDR zur privaten IP-Adresse der Azure Firewall, wodurch die Firewall vollständige Visibility über jeden ausgehenden Flow erhält. Weitere Informationen finden Sie unter Konfigurieren von ausgehenden Clustertypen in AKS.
Verwenden Sie das AzureKubernetesService FQDN-Tag für die erforderliche Zulassungsliste für den Ausgang. AKS erfordert ausgehenden Zugriff auf eine lange und häufig aktualisierte Liste von FQDNs für die Kommunikation mit der Steuerungsebene, das Abrufen von Images, Identitätsdienste und andere Plattformdienste. Anstatt diese FQDNs selbst zu verwalten, erstellen Sie eine Azure Firewall Anwendungsregel, die das AzureKubernetesService FQDN-Tag verwendet. Azure Firewall hält dieses Tag mit den von der Plattform erforderlichen Endpunkten aktuell. Kombinieren Sie dieses Tag mit den zielbezogenen Netzwerkregeln für das Netzwerkzeitprotokoll (Network Time Protocol, NTP), den API-Server unter TCP 9000 und UDP 1194 und Containerregistrierungen, die Ihre Workloads verwenden.
Verwenden Sie die Integration des API-Servers in ein virtuelles Netzwerk, um den Datenverkehr des API-Servers im privaten Netzwerk zu halten. Die API-Server-Integration projiziert den API-Serverendpunkt in ein delegiertes Subnetz in Ihrem virtuellen Netzwerk. Knoten-zu-API-Serverdatenverkehr verbleibt im privaten Netzwerk und durchläuft keine Azure Firewall. Dieses Verhalten entfernt die Notwendigkeit der AKS-Tunnel-Netzwerkregeln und reduziert die Anzahl der Ausgänge, die die Firewall überprüfen muss. Kombinieren Sie die Integration des API-Servers in ein virtuelles Netzwerk mit der Einstellung für private Cluster, wenn Sie auch den öffentlichen Netzwerkzugriff auf den API-Server blockieren möchten. Weitere Informationen finden Sie unter Erstellen eines AKS-Clusters mit API-Server-VNet-Integration. Die Integration des API-Servers in ein virtuelles Netzwerk ist die empfohlene Methode für neue private Cluster. Die ältere Implementierung privater Cluster, die Private Link verwendet, wird unterstützt, bringt jedoch DNS- und Tunnelkomplexität mit sich, die durch die Integration in virtuelle Netzwerke beseitigt wird.

Planen von öffentlichen IP-Adressen und SNAT-Kapazität für Azure Firewall

Azure Firewall verwendet SNAT für alle ausgehenden Flüsse. Jede an die Firewall angefügte öffentliche IP-Adresse stellt eine feste Anzahl von SNAT-Ports bereit, etwa 2.496 Ports pro IP-Adresse pro Back-End-Instanz. Ein AKS-Cluster in der Produktion generiert viele parallele ausgehende Flows aus Pods, insbesondere wenn Pods viele kurzlebige Verbindungen zu einer kleinen Anzahl externer Ziele herstellen. Wenn Sie zu wenige öffentliche IP-Adressen bereitstellen, werden die SNAT-Ports erschöpft, und ausgehende Aufrufe schlagen dann zeitweise mit Verbindungszeitüberschreitungen fehl, die schwer zu diagnostizieren sind.

Die AKS-Anleitung zum Einschränken des Netzwerkdatenverkehrs mit Azure Firewall in AKS empfiehlt mindestens 20 öffentliche IP-Adressen am Front-End für Azure Firewall für Produktionsworkloads, um SNAT-Portausschöpfung zu vermeiden. Behandeln Sie diese Zahl als Ausgangspunkt, keine feste Anforderung. Die genaue Anzahl hängt von der gleichzeitigen Anzahl ausgehender Verbindungen der Workload, der Vielfalt der Ziele und der Verbindungsdauer ab.
Verwenden Sie Azure Firewall NAT-Gatewayintegration oder fügen Sie ein öffentliches IP-Präfix an, um die Verwaltung vieler öffentlicher IP-Adressen zu vereinfachen und den verfügbaren SNAT-Portpool zu erweitern. Das NAT-Gateway erhöht die SNAT-Kapazität erheblich und ist die bevorzugte Option für stark parallelen ausgehenden Datenverkehr.
Überwachen Sie die SNAT-Portauslastung auf Azure Firewall und skalieren Sie öffentliche IP-Adressen auf der Firewall, bevor sie die Sättigung erreichen. Weitere Informationen finden Sie in Azure Firewall überwachen.
Wenn eine kleine Anzahl von Workloads das Ausgehende Flussprofil dominiert (z. B. Protokollversandunternehmen oder Scraper, die auf jedem Knoten ausgeführt werden, aber nur Datenverkehr an einen oder zwei Endpunkte senden), sollten Sie einen dedizierten Ausgangspfad über ein statisches Ausgangsgateway in Betracht ziehen, anstatt Firewall-IP-Adressen zu skalieren, um eine laute Workload zu berücksichtigen.

Vermeiden des asymmetrischen Routings

In dieser Lösung wird Azure Firewall in einem virtuellen Hubnetzwerk bereitgestellt, und der private AKS-Cluster wird in einem virtuellen Speichennetzwerk bereitgestellt. Azure Firewall verwendet Netzwerk- und Anwendungsregelsammlungen, um den Ausgehenden Datenverkehr zu steuern. Konfigurieren Sie in diesem Fall den eingehenden Datenverkehr für jeden öffentlichen Endpunkt, der von einem auf AKS ausgeführten Dienst bereitgestellt wird, so, dass er über eine der öffentlichen IP-Adressen der Azure Firewall 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. Um dieses Problem zu vermeiden, erstellen Sie eine weitere UDR für die öffentliche IP-Adresse der Firewall, wie im folgenden Diagramm dargestellt. Pakete, die zur öffentlichen IP-Adresse der Firewall wechseln, werden über das Internet weitergeleitet. Durch diese Konfiguration wird die Standardroute zur privaten IP-Adresse der Firewall vermieden.

Um den Datenverkehr Ihrer AKS-Workloads an die Azure Firewall im virtuellen Hubnetzwerk weiterzuleiten, müssen Sie:

Erstellen Sie eine Routingtabelle, und ordnen Sie sie jedem Subnetz zu, das die Workerknoten Ihres Clusters hostet.
Erstellen Sie einen UDR, um den Datenverkehr für 0.0.0.0/0 klassenloses domänenübergreifendes Routing (CIDR) an die private IP-Adresse des Azure Firewall weiterzuleiten. Geben Sie als Typ für den nächsten Hop „virtuelle Appliance“ an.

Weitere Informationen finden Sie unter Bereitstellen und Konfigurieren von Azure Firewall mithilfe des Azure-Portals.

Weitere Informationen findest du unter:

Bereitstellung von Workloads auf einem privaten AKS-Cluster mithilfe von Azure DevOps

Wenn Sie Azure DevOps verwenden, können Sie Azure DevOps Microsoft gehostete Agents nicht verwenden, um Ihre Workloads in einem privaten AKS-Cluster bereitzustellen, da sie keinen Zugriff auf den API-Server haben. Um Workloads in Ihrem privaten AKS-Cluster bereitzustellen, müssen Sie einen Azure DevOps selbst gehosteten Agent im selben virtuellen Netzwerk wie Ihr privater AKS-Cluster oder in einem peered virtual network bereitstellen und verwenden. Erstellen Sie im zweiten Fall eine virtuelle Netzwerkverbindung zwischen der privaten DNS-Zone des AKS-Clusters in der Knotenressourcengruppe und dem virtuellen Netzwerk, das den Azure DevOps selbst gehosteten Agent hostt.

Sie können einen einzelnen Windows- oder Linux-Azure DevOps-Agent auf einem virtuellen Computer bereitstellen oder einen Azure VM-Skalierungssatz verwenden. Weitere Informationen finden Sie unter Agents für Virtual Machine Scale Sets. 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 findest du unter:

Wenn die Subnetze, die die Knotenpools Ihres privaten AKS-Clusters hosten, so konfiguriert sind, dass der Ausgehende Datenverkehr über eine Routentabelle und UDR an Azure Firewall weitergeleitet wird, müssen Sie die richtigen Anwendungs- und Netzwerkregeln erstellen. Diese Regeln müssen es dem Agent ermöglichen, auf externe Websites zuzugreifen, um Tools wie Docker, Kubectl, die Azure CLI und Helm auf der Agent-VM herunterzuladen und zu installieren. Weitere Informationen finden Sie unter Ausführen eines selbstgehosteten Agenten in Docker.

Alternativ können Sie einen verwalteten DevOps-Pool im virtuellen Netzwerk konfigurieren, in dem Ihr AKS-Cluster oder ein virtuelles Peernetzwerk gehostet wird. Verwaltete DevOps-Pools helfen Entwicklungsteams, Azure DevOps Agentpools zu erstellen, die auf ihre spezifischen Anforderungen zugeschnitten sind. Sie implementieren bewährte Methoden für die Sicherheit, bieten Optionen zum Ausgleich von Kosten und Leistung, stellen Pfade für häufige Szenarien bereit und reduzieren den Zeitaufwand zum 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, damit CI/CD-Pipelines mit dem Kubernetes-API-Server Ihres privaten AKS-Clusters interagieren können. Mit diesen Agents können die Pipelines auch auf Azure Ressourcen zugreifen, z. B. die Containerregistrierung, die den Zugriff auf öffentliche Netzwerke blockieren und nur Verbindungen über einen privaten Endpunkt zulassen, der im selben virtuellen Netzwerk oder in einem peered-Netzwerk definiert ist. Weitere Informationen finden Sie im Artikel zum Konfigurieren von Managed DevOps Pools-Netzwerken.

Verwenden Sie Azure Firewall vor einem öffentlichen Load Balancer.

In diesem Szenario wird eine in AKS ausgeführte Workload über einen öffentlichen Azure Load Balancer (einen Kubernetes-LoadBalancer-Dienst) in der Knotenressourcengruppe des Clusters bereitgestellt. Azure Firewall befindet sich vor dem Load Balancer und verwendet eine dedizierte öffentliche IP-Adresse sowie eine DNAT-Regel, um eingehenden Datenverkehr an die öffentliche IP-Adresse und den Port des Load Balancers weiterzuleiten. Dieses Muster zentralisiert die Inspektion des eingehenden Datenverkehrs, DNAT und die auf Bedrohungsintelligenz basierende Filterung an der Firewall und ermöglicht es AKS weiterhin, den Load Balancer für den Kubernetes-Dienst zu verwalten. Verwenden Sie diesen Ansatz, wenn die Workload aus dem Internet erreichbar sein muss, aber Sie möchten, dass der gesamte Datenverkehr die Hubfirewall durchläuft, bevor er den Cluster erreicht.

Dieses Diagramm zeigt die Netzwerktopologie des Szenarios.

Hier ist der Nachrichtenfluss:

Eine Anfrage an die von AKS gehostete Webanwendung wird an eine öffentliche IP-Adresse gesendet, die Azure Firewall über eine Konfiguration für öffentliche IP-Adressen bereitstellt. Sowohl die öffentliche IP-Adresse als auch die Konfiguration der öffentlichen IP-Adresse sind diesem Workload zugeordnet.
Eine Azure Firewall-DNAT-Regel ordnet die öffentliche IP-Adresse und den Port der Azure Firewall der öffentlichen IP-Adresse und dem Port zu, die die Workload im öffentlichen Load Balancer des AKS-Clusters in der Knotenressourcengruppe verwendet.
Der Load Balancer leitet die Anfrage an einen Kubernetes-Dienst-Pod weiter, der auf einem Agent-Knoten im AKS-Cluster ausgeführt wird.
Die Antwortnachricht wird über einen UDR an den ursprünglichen Anrufer zurückgesendet. Die Route legt die öffentliche IP-Adresse der Azure Firewall als Adresspräfix und Internet als Typ des nächsten Hops fest.
Alle vom Workload initiierten ausgehenden Aufrufe werden durch die Standard-UDR an die private IP-Adresse der Azure Firewall weitergeleitet. Die Route verwendet 0.0.0.0/0 als Adresspräfix und „virtuelle Appliance“ als Typ für den nächsten Hop.

Verwenden Sie Azure Firewall vor einem internen Load Balancer.

In diesem Szenario wird eine ASP.NET Core-Anwendung als Dienst von einem AKS-Cluster gehostet und von einem Ingress-Controller unterstützt, der von einem internen Load Balancer bereitgestellt wird. Die empfohlenen Ansätze für Ingress in AKS sind die Gateway-API-Implementierung für das Anwendungsrouting oder Application Gateway für Container. Die Gateway-API-Implementierung für das Anwendungsrouting verwendet den Kubernetes Gateway API-Standard mit einer Istio-basierten Kontrollebene zur Verwaltung des clusterinternen Eingangsverkehrs. Das Anwendungsgateway für Container ist ein vollständig verwaltetes Azure-nativen Layer-7-Lastenausgleichsmodul, das auch die Gateway-API unterstützt und erweiterte Datenverkehrsverwaltung, TLS-Beendigung und Mehrwebsitehosting außerhalb des Clusters bereitstellt. Beide Optionen unterstützen die Konfiguration eines internen Lastenausgleichs mit einer privaten IP-Adresse im virtuellen Speichennetzwerk, das den AKS-Cluster hosten soll. Wenn Sie einen Ingress-Controller oder allgemeiner einen LoadBalancer- oder ClusterIP-Dienst mit der service.beta.kubernetes.io/azure-load-balancer-internal: "true"-Annotation im Metadatenabschnitt bereitstellen, wird in der Knotenressourcengruppe ein interner Lastenausgleich namens kubernetes-internal erstellt. Weitere Informationen finden Sie unter Verwenden eines internen Lastenausgleichs mit AKS. Wie im folgenden Diagramm dargestellt, macht Azure Firewall die Testwebanwendung mithilfe einer dedizierten Azure öffentlichen IP-Adresse verfügbar.

Hier ist der Nachrichtenfluss:

Eine Anforderung für die von AKS gehostete Testwebanwendung wird an eine öffentliche IP-Adresse gesendet, die vom Azure Firewall über eine öffentliche IP-Konfiguration verfügbar gemacht wird. Sowohl die öffentliche IP-Adresse als auch die Konfiguration der öffentlichen IP-Adresse sind diesem Workload zugeordnet.
Eine Azure Firewall DNAT-Regel ordnet die öffentliche IP-Adresse und den Port der Azure Firewall der privaten IP-Adresse und dem Port zu, die der ausgewählte Ingress- oder Gateway-Controller im internen Lastenausgleich des AKS-Clusters in der Knotenressourcengruppe verwendet.
Der interne Load-Balancer leitet die Anfrage an einen Kubernetes-Service-Pod weiter, der auf einem Agent-Knoten im AKS-Cluster ausgeführt wird.
Die Antwortnachricht wird über einen UDR an den ursprünglichen Aufrufer zurückgegeben. Die Route verwendet 0.0.0.0/0 als Adresspräfix und „virtuelle Appliance“ als Typ für den nächsten Hop.
Alle vom Workload initiierten ausgehenden Anrufe werden vom UDR an die private IP-Adresse Azure Firewall weitergeleitet.

Considerations

Diese Überlegungen bilden die Säulen des Azure Well-Architected Framework, einer Reihe von Leitprinzipien, die Sie zur Verbesserung der Qualität eines Workloads verwenden können. Weitere Informationen finden Sie unter Well-Architected Framework.

Einige der folgenden Überlegungen sind allgemeine Empfehlungen und nicht Azure Firewall spezifische Anleitungen zum Schutz eines AKS-Clusters. Wir betrachten diese Elemente als wesentliche Anforderungen der Lösung. Dieser Leitfaden gilt für Sicherheits-, Leistungs-, Verfügbarkeits- und Zuverlässigkeitsaspekte, Speicher, Dienstgitter und Überwachung.

Reliability

Zuverlässigkeit trägt dazu bei, dass Ihre Anwendung die Verpflichtungen erfüllen kann, die Sie für Ihre Kunden vornehmen. Weitere Informationen finden Sie unter Prüfliste zur Entwurfsüberprüfung für Zuverlässigkeit.

Erwägen Sie die folgenden Methoden zum Optimieren der Verfügbarkeit Ihres AKS-Clusters und Ihrer Workloads.

Intraregion resilienz

Während der Bereitstellung können Sie Azure Firewall konfigurieren, um mehrere Verfügbarkeitszonen für eine höhere Verfügbarkeit zu umfassen. Informationen zu Verfügbarkeitsprozentsätzen finden Sie im Azure Firewall ServiceLevel Agreement (SLA) in SLAs für Microsoft Onlinedienste. Sie können Azure Firewall auch einer bestimmten Zone für die Näherung zuordnen. Diese Konfiguration wirkt sich jedoch auf die SLA aus. Es gelten keine zusätzlichen Kosten für eine Firewall, die in einer Verfügbarkeitszone bereitgestellt wird, einschließlich Datenübertragungen zwischen Verfügbarkeitszonen.
Erwägen Sie, die Knotenpools Ihres AKS-Clusters in allen Verfügbarkeitszonen einer Region bereitzustellen. Verwenden Sie ein Azure Lastenausgleichsmodul oder Anwendungsgateway vor den Knotenpools. 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 der Containerregistrierung für intraregionweite Resilienz und hohe Verfügbarkeit.
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.
Erwägen Sie die Verwendung der Standard- oder Premium-Preisstufe für AKS-Cluster, die unternehmenskritische Workloads hosten. Diese Tarifstufen umfassen ein finanziell abgesichertes SLA für die Cluster-Verfügbarkeit. Die Standardebene garantiert 99.95% Verfügbarkeit des Kubernetes-API-Serverendpunkts für Cluster, die Verfügbarkeitszonen verwenden, oder 99,9% für Cluster, die keine Verfügbarkeitszonen verwenden. Die Premium-Stufe bietet die gleichen SLA-Garantien mit zusätzlicher langfristiger Unterstützung (LTS) für Kubernetes-Versionen. Weitere Informationen finden Sie unter AKS-Preisniveaus. AKS verwendet Steuerelementebenenreplikate über Update- und Fehlerdomänen hinweg, um sicherzustellen, dass SLA-Anforderungen erfüllt sind.
Erwägen Sie die Verwendung der automatischen AKS-SKU für neue Cluster, die von einer vollständig verwalteten Knotenverwaltung mit integrierten bewährten Methoden für Zuverlässigkeit, Sicherheit und Leistung profitieren. AKS Automatic verwendet standardmäßig das Standard-Preisniveau.

Geschäftskontinuität und Katastrophenwiederherstellung

Erwägen Sie die Bereitstellung Ihrer Lösung in mindestens zwei gekoppelten Azure-Regionen innerhalb einer Geografie. Verwenden Sie ein globales Lastenausgleichsmodul wie Azure Traffic Manager oder Azure Front Door mit einer aktiven oder passiven Routingmethode, um Geschäftskontinuität und Notfallwiederherstellung (BC/DR) zu gewährleisten.
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. Sie können diese Richtlinie als übergeordnete Richtlinie für regionale Azure-Richtlinien verwenden. Richtlinien, die mit nicht leeren übergeordneten Richtlinien erstellt werden, erben alle Regelsammlungen der übergeordneten Richtlinie. Netzwerkregelsammlungen, die von einer übergeordneten Richtlinie geerbt wurden, haben immer Priorität vor Netzwerkregelsammlungen, die als Teil einer 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 Azure Firewall Manager Richtlinienübersicht.
Definieren, dokumentieren und testen Sie Ihren regionalen Failover-Prozess regelmäßig in einer QA-Umgebung. Diese Tests helfen Ihnen, unvorhersehbare Probleme zu vermeiden, wenn sich ein Ausfall auf einen Kerndienst in der primären Region auswirkt. Diese Tests überprüfen außerdem, ob Ihr DR-Ansatz RPO- und RTO-Ziele erfüllt, zusammen mit manuellen Schritten oder Operatorinterventionen, die während eines Failovers erforderlich sind.
Testen Sie Fail-Back-Prozeduren, 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 der Containerregistrierung.
Wenn ein regionales Replikat beeinträchtigt wird, leitet Container Registry Pulls automatisch über ihren globalen Endpunkt (<registry>.azurecr.io) an ein funktionsfähiges Replikat um. Dieses Failover erfolgt intern innerhalb von Minuten und erfordert keine AKS-side- oder DNS-Konfigurationsänderungen.
Vermeiden Sie nach Möglichkeit das Speichern des Dienststatus im Container. Verwenden Sie stattdessen eine Azure PaaS, die die Replikation mehrerer Regionen unterstützt.
Wenn Sie Speicher verwenden, bereiten Sie einen Prozess für die Migration Ihres Speichers aus der primären Region in die Sicherungsregion vor, und testen Sie diesen.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Entwurfsprüfliste für die Sicherheit.

Die Azure-Plattform bietet Schutz vor verschiedenen Bedrohungen wie Netzwerkangriffen und DDoS-Angriffen. Verwenden Sie eine Webanwendungsfirewall (WAF), um alle von AKS gehosteten Webanwendungen und Dienste zu schützen, die einen öffentlichen HTTPS-Endpunkt verfügbar machen. Sie müssen sich gegen häufige Bedrohungen wie SQL-Injection, Cross-Site-Scripting und andere Web-Angriffe schützen. Verwenden Sie open Web Application Security Project (OWASP)-Regeln und benutzerdefinierte Regeln für diesen Zweck. Azure Web Application Firewall bietet zentralen Schutz für Ihre Webanwendungen vor gängigen Exploits und Sicherheitsrisiken. Sie können Azure Web Application Firewall 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 versucht, die Ressourcen einer Anwendung zu erschöpfen, wodurch die Anwendung für legitime Benutzer nicht verfügbar ist. DDoS-Angriffe können auf jeden Endpunkt abzielen, der öffentlich über das Internet erreichbar ist. Für alle Objekte in Azure wird Schutz durch Azure DDoS-Infrastrukturschutz ohne Aufpreis geboten. Die Größe und Kapazität des weltweit bereitgestellten Azure-Netzwerks bieten Schutz vor häufigen Angriffen auf der Netzwerkschicht durch kontinuierliche Überwachung des Datenverkehrs und Abwehrmaß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. Aktivieren Sie den DDoS-Netzwerkschutz in virtuellen Umkreisnetzwerken.

Weitere Sicherheitsaspekte sind:

Erstellen Sie einen privaten Endpunkt für jeden PaaS-Dienst, den AKS-Workloads verwenden, z. B. Key Vault, Azure Service Bus und Azure SQL-Datenbank. Der Datenverkehr zwischen den Anwendungen und diesen Diensten wird nicht für das öffentliche Internet verfügbar gemacht. Der Datenverkehr zwischen dem virtuellen AKS-Clusternetzwerk und einer Instanz eines PaaS-Diensts über einen privaten Endpunkt bewegt das Microsoft Backbone-Netzwerk, die Kommunikation wird jedoch nicht über Azure Firewall geleitet. Dieser Mechanismus bietet mehr Sicherheit und besseren Schutz vor Datenlecks. Weitere Informationen finden Sie unter Private Link.
Wenn Sie das Anwendungsgateway vor dem AKS-Cluster verwenden, verwenden Sie eine Web Application Firewall-Richtlinie, um öffentlich zugängliche Workloads zu schützen, die auf AKS ausgeführt werden, vor Angriffen.
Verwenden Sie Netzwerkrichtlinien, um die Intraservice-Kommunikation zu trennen und zu schützen. Steuern, welche Komponenten miteinander kommunizieren können. Standardmäßig können alle Pods in einem Kubernetes-Cluster Datenverkehr ohne Einschränkungen senden und empfangen. Verwenden Sie Azure CNI Powered by Cilium, um Netzwerkrichtlinien zu erzwingen. Calico wird auch unterstützt, wenn Sie es für die Kompatibilität mit vorhandenen Tools benötigen. Weitere Informationen finden Sie unter Netzwerkrichtlinien in AKS.
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.
Sie können Azure Firewall vor einem GATEWAY-API-basierten Eingangscontroller verwenden, um Workloads über HTTPS verfügbar zu machen und für jede Anwendung eine separate Unterdomäne und ein separates Zertifikat zu verwenden. Die empfohlenen verwalteten Ingress-Lösungen für AKS sind Application Gateway for Containers und die Gateway-API-Implementierung für das Anwendungsrouting. Application Gateway for Containers ist ein vollständig verwalteter, systemeigener Azure Layer-7-Load Balancer außerhalb des Clusters, der die Kubernetes Gateway API und Multisitehosting unterstützt. Die Implementierung der Gateway-API für das Anwendungsrouting verwendet eine Istio-basierte Kontrollebene, um die Datenverkehrsweiterleitung im Cluster über Kubernetes-Ressourcen Gateway und HTTPRoute bereitzustellen. Verwenden Sie AGIC nicht für neue Bereitstellungen.
Sie können Azure Firewall vor einem GATEWAY-API-basierten Eingangscontroller verwenden, um Workloads über HTTPS verfügbar zu machen und für jede Anwendung eine separate Unterdomäne und ein separates Zertifikat zu verwenden. Die empfohlenen verwalteten Ingress-Lösungen für AKS sind Application Gateway for Containers und die Gateway-API-Implementierung für das Anwendungsrouting. Application Gateway für Container ist ein vollständig verwalteter, systemeigener Layer-7-Lastenausgleichsdienst von Azure außerhalb des Clusters, der die Kubernetes Gateway API und Multisitehosting unterstützt. Die Implementierung der Gateway API für Anwendungsrouting verwendet eine Istio-basierte Kontrollebene, um das Routing des Datenverkehrs innerhalb des Clusters über Kubernetes-Ressourcen Gateway und HTTPRoute zu ermöglichen. Verwenden Sie AGIC nicht für neue Bereitstellungen.
Konfigurieren Sie die TLS-Beendigung am ausgewählten Eingangspunkt. Informationen zu TLS mit Anwendungsgateway für Container finden Sie unter TLS-Richtlinie mit Anwendungsgateway für Container. Informationen zu TLS mit Anwendungsrouting finden Sie unter Secure ingress by using the application routing Gateway API implementation. Alternativ können Sie den Zertifikat-Manager verwenden, um TLS-Zertifikate automatisch mit Let's Encrypt zu generieren.
Eine enge Abstimmung zwischen dem Azure-Firewall-Betreiber sowie den Cluster- und Workload-Teams ist für die erstmalige Bereitstellung des Clusters und für den laufenden Betrieb erforderlich, wenn sich die Anforderungen an Workloads und den Cluster weiterentwickeln. Diese Koordination ist besonders wichtig, wenn Sie die Authentifizierungsmechanismen wie OAuth 2.0 und OpenID Connect konfigurieren, die Workloads zum Authentifizieren ihrer Clients verwenden.
Verwenden Sie die folgenden Richtlinien, um die in diesem Artikel beschriebene Umgebung zu schützen:

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Design Review-Checkliste für die Kostenoptimierung.

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

Dienstebenen
Skalierbarkeit (die Anzahl der Instanzen, die Dienste dynamisch zuordnen, um eine bestimmte Anforderung zu unterstützen)
Automatisierungsskripts
Ihre DR-Stufe

Nachdem Sie diese Konfigurationsdetails geprüft haben, schätzen Sie Ihre Kosten mit dem Azure-Preisrechner.

Betriebliche Effizienz

Operational Excellence deckt die Betriebsprozesse ab, mit denen eine Anwendung bereitgestellt und in der Produktion ausgeführt wird. Weitere Informationen finden Sie in der Prüfliste für das Design Review von Operational Excellence.

DevOps

Stellen Sie Ihre Workloads mithilfe eines Helm-Charts in einer CI/CD-Pipeline in AKS bereit. Nutzen Sie ein DevOps-System wie GitHub Actions oder Azure DevOps. Weitere Informationen finden Sie unter Erstellen und Bereitstellen im AKS.
Testen Sie eine Anwendung gründlich, bevor Sie sie Nutzern zur Verfügung stellen, indem Sie A/B-Tests und Canary-Bereitstellungen im Rahmen Ihres Anwendungslebenszyklusmanagements einsetzen. Sie können mehrere Techniken verwenden, um den Datenverkehr auf verschiedene Versionen desselben Diensts aufzuteilen. Alternativ können Sie die Datenverkehrsteilungsfunktionen verwenden, die eine Dienstgitterimplementierung bereitstellt. Weitere Informationen finden Sie unter Istio Traffic Management.
Verwenden Sie Azure Container Registry oder eine andere Containerregistrierung (z. B. Docker Hub), um die privaten Docker-Images zu speichern, die im Cluster bereitgestellt werden. AKS kann sich mit Azure Container Registry mithilfe seiner Microsoft Entra Identität authentifizieren.
Testen Sie den Dateneingang und -ausgang Ihrer Workloads in einer separaten Vorproduktionsumgebung, die die Netzwerktopologie und Firewallregeln Ihrer Produktionsumgebung widerspiegelt. Mit einer mehrstufigen Rolloutstrategie können Sie Netzwerk- oder Sicherheitsprobleme erkennen, bevor Sie ein neues Feature oder eine neue Netzwerkregel in die Produktion freigeben.
Legen Sie fest, welche Azure Firewall- und Routingressourcen von Ihrer Infrastructure-as-Code-Pipeline (IaC) verwaltet werden und welche Ressourcen Netzwerk- oder Sicherheitsoperatoren außerhalb der Pipeline verwalten. Wenn Sie Terraform verwenden, können Sie das Metaargument des Lebenszyklus mit ignore_changes auf den Ressourcen Azure Firewall Policy und Azure Route Table verwenden. Mit dieser Konfiguration kann Terraform die Ressourcen erstellen und verwalten, während DNAT-, Anwendungs- und Netzwerkregeln in der Firewallrichtlinie sowie UDRs in der Routingtabelle außerhalb von Terraform verwaltet werden können, ohne beim nächsten Apply rückgängig gemacht zu werden. Die Terraform-Beispielmodule für dieses Szenario verwenden dieses Muster.

Überwachung

Azure Firewall ist vollständig in Azure Monitor integriert, um eingehenden und ausgehenden Datenverkehr zu protokollieren, den die Firewall verarbeitet. Weitere Informationen finden Sie unter Threat Intelligence-gestütztes Filtern für Azure Firewall.

Aktivieren Sie Azure Firewall strukturierte Protokolle für detaillierte, schemabasierte Protokollierung, die die Abfrage und Analyse vereinfacht. Strukturierte Protokolle bieten Einblicke in Datenverkehrsmuster, Regeltreffer, Bedrohungserkennungsaktionen und IDPS-Signale (Intrusion Detection and Prevention System) in einem Format, das in Azure Monitor Log Analytics-, Microsoft Sentinel- und nicht Microsoft SIEM-Tools integriert ist.
Verwenden Sie die Kubernetes-Überwachung in Azure Monitor, 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.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben es ursprünglich geschrieben.

Hauptautor:

Paolo Salvadori | Principal Service Engineer

Andere Mitwirkende:

Sam Cogan | Senior Cloud Solution Architect

Um nicht öffentliche LinkedIn-Profile zu sehen, melden Sie sich bei LinkedIn an.

Nächster Schritt

Well-Architected Framework-Diensthandbuch für AKS

Feedback

War diese Seite hilfreich?

Last updated on 2026-06-23