Freigeben über

Verwenden von Azure Front Door zum Sichern von AKS-Workloads

Azure Front Door
Azure Key Vault
Azure Private Link
Azure Container Registry
Azure Kubernetes Service (AKS)

In diesem Artikel wird beschrieben, wie Sie eine Workload verfügbar machen und schützen, die in Azure Kubernetes Service (AKS) mit Azure Front Door, Azure Web Application Firewall und einem Azure Private Link-Dienst auf sicherere Weise ausgeführt wird. Diese Architektur verwendet den NGINX-Eingangscontroller, um eine Webanwendung verfügbar zu machen. Der NGINX-Eingangscontroller ist für die Verwendung einer privaten IP-Adresse als Front-End-IP-Konfiguration des internen AKS-Load Balancers konfiguriert. Die Bereitstellung bietet TLS-Verschlüsselung (End-to-End Transport Layer Security).

Aufbau

Diagramm, das eine Architektur zeigt, die eine Arbeitsauslastung, die in AKS ausgeführt wird, sicher verfügbar macht und schützt.

Das Grafana-Logo ist eine Marke des entsprechenden Unternehmens. Die Verwendung dieser Marke impliziert keine Empfehlung.

Laden Sie eine Visio-Datei dieser Architektur herunter.

Arbeitsablauf

Das folgende Diagramm zeigt die Schritte für den Nachrichtenfluss während Bereitstellung und Laufzeit.

Diagramm, das die Schritte für den Nachrichtenfluss während der Bereitstellung und Laufzeit zeigt.

Bereitstellungsworkflow

Sie können eine der folgenden Methoden verwenden, um den NGINX-Eingangscontroller bereitzustellen:

Der folgende Workflow entspricht dem vorherigen Diagramm:

  1. Ein Sicherheitstechniker generiert ein Zertifikat für die benutzerdefinierte Domäne, die von der Workload verwendet wird, und speichert es in einem Azure Key Vault. Sie können ein gültiges Zertifikat von einer bekannten Zertifizierungsstelle erhalten.

  2. Ein Plattformtechniker gibt die erforderlichen Informationen in der main.bicepparams Bicep-Parameterdatei an und stellt die Bicep-Module bereit, um die Azure-Ressourcen zu erstellen. Die erforderlichen Informationen beinhalten:

    • Ein Präfix für die Azure-Ressourcen.

    • Der Name und die Ressourcengruppe des vorhandenen Schlüsseltresors, der das TLS-Zertifikat für den Workload-Hostnamen und die benutzerdefinierte Azure Front Door-Domäne enthält.

    • Name des Zertifikats im Key Vault.

    • Name und Ressourcengruppe der DNS-Zone, die zum Auflösen der benutzerdefinierten Azure Front Door-Domäne verwendet wird.

  3. Das Bereitstellungsskript erstellt die folgenden Objekte im AKS-Cluster:

  4. Eine geheime Azure Front Door-Ressource wird verwendet, um das TLS-Zertifikat zu verwalten und zu speichern, das sich im Schlüsseltresor befindet. Dieses Zertifikat wird von der benutzerdefinierten Domäne verwendet, die dem Azure Front Door-Endpunkt zugeordnet ist. Das Azure Front Door-Profil verwendet eine vom Benutzer zugewiesene verwaltete Identität mit der Rollenzuweisung "Key Vault-Administrator" , um das TLS-Zertifikat aus dem Key Vault abzurufen.

Hinweis

Am Ende der Bereitstellung müssen Sie die Verbindung mit dem privaten Endpunkt genehmigen, bevor der Datenverkehr privat an den Ursprung weitergeleitet werden kann. Weitere Informationen finden Sie unter Schützen des Ursprungs mit Private Link in Azure Front Door Premium. Sie können Verbindungen mit privaten Endpunkten mithilfe des Azure-Portals, der Azure CLI oder mithilfe von Azure PowerShell genehmigen. Weitere Informationen finden Sie unter Verwalten einer Verbindung mit einem privaten Endpunkt.

Laufzeit-Workflow

Die folgenden Schritte beschreiben den Nachrichtenfluss für eine Anforderung, die eine externe Clientanwendung während der Laufzeit initiiert. Dieser Workflow entspricht den orangefarbenen Zahlen im vorherigen Diagramm.

  1. Die Clientanwendung verwendet ihre benutzerdefinierte Domäne, um eine Anforderung an die Webanwendung zu senden. Die DNS-Zone, die der benutzerdefinierten Domäne zugeordnet ist, verwendet einen CNAME-Eintrag, um die DNS-Abfrage für die benutzerdefinierte Domäne an den ursprünglichen Hostnamen des Azure Front Door-Endpunkts umzuleiten.

  2. Das Routing des Azure Front Door-Datenverkehrs erfolgt in mehreren Phasen. Zunächst wird die Anforderung an einen der Points of Presence von Azure Front Door gesendet. Dann verwendet Azure Front Door die Konfiguration, um das korrekte Ziel für den Datenverkehr zu ermitteln. Verschiedene Faktoren können den Routingprozess beeinflussen, z. B. das Zwischenspeichern von Azure Front Door, die Webanwendungsfirewall (WAF), Routingregeln, das Regelmodul und die Zwischenspeicherungskonfiguration. Weitere Informationen finden Sie unter Übersicht über die Routingarchitektur.

  3. Azure Front Door leitet die eingehende Anforderung an den privaten Azure-Endpunkt weiter, der mit dem Private Link-Dienst verbunden ist, der den von AKS gehosteten Workload verfügbar macht.

  4. Die Anforderung wird an den Private Link-Dienst gesendet.

  5. Die Anforderung wird an den internen AKS-Load Balancer mit dem Wert kubernetes-internal weitergeleitet.

  6. Die Anforderung wird an einen der Agentknoten gesendet, die einen Pod des verwalteten oder nicht verwalteten NGINX-Eingangscontrollers hosten.

  7. Eines der NGINX-Eingangscontroller-Replikate verarbeitet die Anforderung.

  8. Der NGINX-Eingangscontroller leitet die Anforderung an einen der Workload-Pods weiter.

Komponenten

  • Ein öffentlicher oder privater AKS-Cluster besteht aus den folgenden Knotenpools:

    • Einem Systemknotenpool in einem dedizierten Subnetz Dem Standard-Knotenpool, der nur kritische Systempods und -dienste hostet Die Systemknoten weisen einen Knoten taint auf, sodass Anwendungs pods in diesem Knotenpool nicht geplant werden können.

    • Einem Benutzerknotenpool, der Benutzer-Workloads und Artefakte in einem dedizierten Subnetz hostet

  • Für die Bereitstellung sind rollenbasierte Zugriffssteuerungsrollenzuweisungen (RBAC) erforderlich, die Folgendes umfassen:

    • Eine Grafana Admin-Rollenzuweisung auf Azure Managed Grafana für den Microsoft Entra-Benutzer, dessen objectID im userId-Parameter definiert ist Die Rolle "Grafana-Administrator " gewährt die vollständige Kontrolle über die Instanz. Dieses Steuerelement umfasst das Verwalten von Rollenzuweisungen sowie das Anzeigen, Bearbeiten und Konfigurieren von Datenquellen. Weitere Informationen finden Sie unter Freigabe des Zugriffs auf Azure Managed Grafana.

    • Eine Zuweisung der Rolle Key Vault Administrator in der vorhandenen Key Vault-Ressource, die das TLS-Zertifikat für die benutzerdefinierte verwaltete Identität enthält, die der Key Vault-Anbieter für Secrets Store CSI Driver verwendet Diese Zuweisung ermöglicht den Zugriff auf den CSI-Treiber, damit dieser das Zertifikat aus dem Quell-Key Vault lesen kann.

  • Azure Front Door Premium ist ein globaler Layer-7-Load Balancer und ein modernes Cloud-Content-Bereitstellungsnetzwerk. Sie bietet schnellen, zuverlässigen und verbesserten Sicherheitszugriff zwischen den statischen und dynamischen Webinhalten Ihrer Anwendungen auf der ganzen Welt. Sie können Azure Front Door verwenden, um Ihre Inhalte mithilfe des globalen Microsoft Edge-Netzwerks bereitzustellen. Das Netzwerk verfügt über Hunderte globaler und lokaler Points of Presence, die auf der ganzen Welt verteilt sind. Sie können daher Points of Presence verwenden, die in der Nähe Ihrer Unternehmens- und Verbraucherkunden liegen.

    In dieser Lösung wird Azure Front Door verwendet, um eine von AKS gehostete Beispielwebanwendung über einen Private Link-Dienst und den NGINX-Eingangscontroller verfügbar zu machen. Azure Front Door ist so konfiguriert, dass eine benutzerdefinierte Domäne für den Azure Front Door-Endpunkt verfügbar gemacht wird. Die benutzerdefinierte Domäne ist so konfiguriert, dass das Azure Front Door-Secret verwendet wird, das ein TLS-Zertifikat enthält, das aus dem Key Vault gelesen wird.

  • Azure Web Application Firewall schützt die von AKS gehosteten Anwendungen, die über Azure Front Door zugänglich gemacht werden, gegen typische webbasierte Angriffe, wie etwa Anfälligkeiten gemäß The Open Web Application Security Project (OWASP), SQL Injections und websiteübergreifendes Skripting. Für diese cloudnative und nutzungsbasiert zu bezahlende Technologie ist keine Lizenzierung erforderlich. Azure Web Application Firewall bietet zentralisierten Schutz für Ihre Webanwendungen und schützt Ihre Webdienste vor gängigen Exploits und Sicherheitsrisiken.

  • Eine Azure DNS-Zone wird für die Namensauflösung der benutzerdefinierten Azure Front Door-Domäne verwendet. Sie können Azure DNS verwenden, um Ihre DNS-Domäne zu hosten und die DNS-Einträge zu verwalten.

    • Der CNAME-Eintrag wird verwendet, um ein Alias oder einen Zeiger von einem Domänennamen auf einen anderen zu erstellen. Sie können einen CNAME-Eintrag konfigurieren, um DNS-Abfragen für die benutzerdefinierte Domäne an den ursprünglichen Hostnamen des Azure Front Door-Endpunkts umzuleiten.

    • Der Text (TXT)-Eintrag enthält das Überprüfungstoken für die benutzerdefinierte Domäne. Sie können einen TXT-Eintrag in einer DNS-Zone verwenden, um beliebige Textinformationen zu speichern, die einer Domäne zugeordnet sind.

  • Ein Private Link-Dienst ist so konfiguriert, dass er auf den Load Balancer des AKS-Clusters mit dem Wert kubernetes-internal verweist. Wenn Sie Private Link für Ihren Ursprung in Azure Front Door Premium aktivieren, erstellt Azure Front Door einen privaten Endpunkt aus dem von Azure Front Door verwalteten regionalen privaten Netzwerk. Sie erhalten eine Anforderung für einen privaten Azure Front Door-Endpunkt am Ursprung zur Genehmigung. Weitere Informationen finden Sie unter Schützen des Ursprungs mit Private Link in Azure Front Door Premium.

  • Azure Virtual Network wird verwendet, um ein einzelnes virtuelles Netzwerk mit sechs Subnetzen zu erstellen:

    • SystemSubnet wird für die Agentenknoten des Systemknotenpools verwendet.

    • UserSubnet wird für die Agentenknoten des Benutzerknotenpools verwendet.

    • PodSubnet wird verwendet, um private IP-Adressen dynamisch zu Pods zuzuweisen, wenn der AKS-Cluster für die Verwendung der Azure Content Networking-Schnittstelle mit dynamischer IP-Adresszuweisung konfiguriert ist.

    • ApiServerSubnet verwendet die API Server VNet-Integration, um den API-Serverendpunkt direkt in dieses delegierte Subnetz zu projizieren, in dem der AKS-Cluster bereitgestellt wird.

    • AzureBastionSubnet wird für den Azure Bastion-Host verwendet.

    • VmSubnet wird für den virtuellen Sprungfeldcomputer (VM) verwendet, der eine Verbindung mit dem privaten AKS-Cluster und für die privaten Endpunkte herstellt.

  • Der AKS-Cluster nutzt eine vom Benutzer zugewiesene verwaltete Identität zum Erstellen zusätzlicher Ressourcen (wie Load Balancers und verwaltete Datenträger) in Azure.

  • Azure Virtual Machines wird verwendet, um eine optionale Sprungfeld-VM im VM-Subnetz zu erstellen.

  • Ein Azure Bastion-Host wird im virtuellen AKS-Clusternetzwerk bereitgestellt, um secure Socket Shell-Konnektivität mit den AKS-Agentknoten und VMs bereitzustellen.

  • Ein Azure Storage-Konto wird verwendet, um die Startdiagnoseprotokolle der VMs des Dienstanbieters und des Dienstanwenders zu speichern. Die Startdiagnose ist eine Debugging-Funktion, mit der Sie die Konsolenausgabe und Screenshots anzeigen können, um den VM-Status zu diagnostizieren.

  • Azure Container Registry wird zum Erstellen, Speichern und Verwalten von Containerimages und Artefakten verwendet.

  • Key Vault wird zum Speichern von Secrets, Zertifikaten und Schlüsseln verwendet. Pods können den Key Vault-Anbieter für den Secrets Store CSI-Treiber verwenden, um Secrets, Zertifikate und Schlüssel als Dateien bereitzustellen.

    Weitere Informationen finden Sie unter Verwenden des Key Vault-Anbieters für den CSI-Treiber für den Secrets Store in einem AKS-Cluster und Bereitstellen einer Identität für den Zugriff auf den Key Vault-Anbieter für den CSI-Treiber für den Secrets Store.

    In diesem Projekt enthält eine vorhandene Key Vault-Ressource das TLS-Zertifikat, das das Kubernetes-Eingangsobjekt und die benutzerdefinierte Domäne des Azure Front Door-Endpunkts verwendet.

  • Ein privater Azure-Endpunkt und eine private Azure-DNS-Zone werden für jede der folgenden Ressourcen erstellt:

    • Container Registry
    • Key Vault
    • Ein Speicherkonto

  • Azure-Netzwerksicherheitsgruppen (NSGs) werden verwendet, um eingehenden und ausgehenden Datenverkehr für die Subnetze zu filtern, die VMs und Azure Bastion-Hosts hosten.

  • Ein Azure Monitor-Arbeitsbereich ist eine spezielle Umgebung für die von Monitor erfassten Daten. Jeder Arbeitsbereich verfügt über ein eigenes Datenrepository, eine eigene Konfiguration und eigene Berechtigungen. Azure Monitor Logs-Arbeitsbereiche enthalten Protokolle und Metrikdaten aus mehreren Azure-Ressourcen, während Monitor-Arbeitsbereiche nur Metriken enthalten, die sich auf Prometheus beziehen.

    Sie können den verwalteten Dienst für Prometheus verwenden, um Metriken in großem Umfang zu sammeln und zu analysieren, indem Sie eine mit Prometheus kompatible Überwachungslösung verwenden, die auf Prometheus basiert. Sie können die Prometheus-Abfragesprache (PromQL) nutzen, um die Leistung von überwachter Infrastruktur sowie von überwachten Workloads zu analysieren und entsprechende Benachrichtigungen auszugeben, ohne die zugrunde liegende Infrastruktur betreiben zu müssen.

  • Eine Azure Managed Grafana-Instanz wird verwendet, um die Prometheus-Metriken zu visualisieren, die der vom Bicep-Modul bereitgestellte AKS-Cluster generiert. Sie können Ihren Monitor-Arbeitsbereich mit Azure Managed Grafana verbinden und eine Reihe integrierter und benutzerdefinierter Grafana-Dashboards verwenden, um Prometheus-Metriken zu visualisieren. Grafana Enterprise unterstützt Azure Managed Grafana, das erweiterbare Datenvisualisierungen bereitstellt. Sie können Grafana-Dashboards, die über integrierte hohe Verfügbarkeit verfügen, schnell und einfach bereitstellen. Sie können außerdem Azure-Sicherheitsmaßnahmen verwenden, um den Zugriff auf die Dashboards zu steuern.

  • Ein Azure Monitor Logs-Arbeitsbereich wird verwendet, um die Diagnoseprotokolle und Metriken aus Azure-Ressourcen zu sammeln, darunter:

    • AKS-Cluster
    • Key Vault
    • Azure NSGs
    • Container Registry
    • Speicherkonten

  • Ein Bicep-Bereitstellungsskript wird verwendet, um ein Bash-Skript auszuführen, das die folgenden Objekte im AKS-Cluster erstellt:

Alternativen

Um automatisch einen verwalteten Private Link-Dienst mit dem Lastenausgleich des AKS-Clusters zu erstellen, können Sie das Feature Private Link-Dienst verwenden. Um private Verbindungen bereitzustellen, müssen Sie private Endpunktverbindungen zu Ihrem Dienst erstellen. Sie können Anmerkungen verwenden, um einen Kubernetes-Dienst über einen Private Link-Dienst verfügbar zu machen. Die Architektur in diesem Artikel erstellt manuell einen Private Link-Dienst, um auf den Load Balancer des Azure-Clusters zu verweisen.

Szenariodetails

Dieses Szenario verwendet Azure Front Door Premium, End-to-End-TLS-Verschlüsselung, Azure Web Application Firewall und einen Private Link-Dienst, um einen Workload, der in AKS ausgeführt wird, sicher verfügbar zu machen und zu schützen.

Diese Architektur verwendet die Azure Front Door TLS- und SSL-Offloadfunktion (Secure Sockets Layer), um die TLS-Verbindung zu beenden und den eingehenden Datenverkehr an der Front Door zu entschlüsseln. Der Datenverkehr wird erneut verschlüsselt, bevor er an den Ursprung weitergeleitet wird. Dabei handelt es sich um eine Webanwendung, die in einem AKS-Cluster gehostet wird. HTTPS wird als Weiterleitungsprotokoll in Azure Front Door konfiguriert, wenn Azure Front Door eine Verbindung mit dem vom AKS gehosteten Workload herstellt, der als Ursprung konfiguriert ist. Bei dieser Vorgehensweise wird die End-to-End-TLS-Verschlüsselung für den gesamten Anforderungsprozess vom Client zum Ursprung erzwungen. Weitere Informationen finden Sie unter Schützen des Ursprungs mit Private Link in Azure Front Door Premium.

Der NGINX-Eingangscontroller macht die von AKS gehostete Webanwendung verfügbar. Der NGINX-Eingangscontroller ist für die Verwendung einer privaten IP-Adresse als Front-End-IP-Konfiguration des kubernetes-internal internen Load Balancers konfiguriert. Der NGINX-Eingangscontroller verwendet HTTPS als Transportprotokoll, um die Webanwendung verfügbar zu machen. Weitere Informationen finden Sie unter Erstellen eines Eingangscontrollers mithilfe einer internen IP-Adresse.

Der AKS-Cluster ist für die Verwendung der folgenden Funktionen konfiguriert:

  • Die API-Server-VNet-Integration ermöglicht die Netzwerkkommunikation zwischen dem API-Server und den Clusterknoten. Für dieses Feature ist keine private Verbindung oder Tunnel erforderlich. Der API-Server ist hinter einer internen Load Balancer-VIP im delegierten Subnetz verfügbar. Die Clusterknoten sind für die Verwendung des delegierten Subnetzes konfiguriert. Sie können die INTEGRATION des virtuellen API-Servers verwenden, um sicherzustellen, dass der Netzwerkverkehr zwischen Ihrem API-Server und Den Knotenpools nur im privaten Netzwerk verbleibt. AKS-Cluster mit API-Server-VNet-Integration bieten viele Vorteile. Sie können z. B. den öffentlichen Netzwerkzugriff oder den privaten Clustermodus aktivieren oder deaktivieren, ohne den Cluster erneut bereitzustellen. Weitere Informationen finden Sie unter Erstellen eines AKS-Clusters mit API-Server-VNet-Integration.

  • Azure NAT Gateway verwaltet ausgehende Verbindungen, die von AKS gehostete Workloads initiieren. Weitere Informationen finden Sie unter Erstellen eines verwalteten oder vom Benutzer zugewiesenen NAT Gateways für Ihren AKS-Cluster.

Mögliche Anwendungsfälle

Dieses Szenario bietet eine Lösung zur Erfüllung der Sicherheits- und Complianceanforderungen für eine Webanwendung oder REST-API, die in AKS ausgeführt wird.

Überlegungen

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 beziehen sich nicht speziell auf die Verwendung von Azure Front Door, Azure Web Application Firewall oder eines Private Link-Diensts, um die Sicherheit eines AKS-Clusters zu verbessern. Die Überlegungen zu Sicherheit, Leistung, Verfügbarkeit, Zuverlässigkeit, Speicher und Überwachung sind jedoch wesentliche Anforderungen dieser Lösung.

Zuverlässigkeit

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 Erstellen einer Checkliste zur Überprüfung der Zuverlässigkeit.

Diese Empfehlungen sind für AKS-Lösungen mit einem Mandanten unerlässlich und sind nicht spezifisch für mehrinstanzenfähige AKS-Lösungen, bei denen die Zuverlässigkeitsziele aufgrund der Anzahl der Benutzer und Workloads, die auf dem System basieren, höher sind. Berücksichtigen Sie die folgenden Empfehlungen zum Optimieren der Verfügbarkeit Ihres AKS-Clusters und Ihrer Workloads.

Intraregionale Resilienz

  • Stellen Sie die Knotenpools Ihres AKS-Clusters in allen Verfügbarkeitszonen einer Region bereit.

  • Aktivieren Sie Zonenredundanz in Container Registry für Resilienz und Hochverfügbarkeit innerhalb der jeweiligen Region.

  • Verwenden Sie Topologieverteilungseinschränkungen, um zu steuern, wie Pods in Ihrem AKS-Cluster auf Fehlerdomänen wie Regionen, Verfügbarkeitszonen und Knoten verteilt werden.

  • Verwenden Sie die Standard- oder Premium-Stufe für Ihre Produktions-AKS-Cluster. Zu diesen Stufen gehört das Verfügbarkeits-Feature (SLA), das eine Verfügbarkeit des Kubernetes-API-Serverendpunkts von 99,95 % für Cluster garantiert, die Verfügbarkeitszonen verwenden, und eine Verfügbarkeit von 99,9 % für Cluster, die keine Verfügbarkeitszonen verwenden. Weitere Informationen finden Sie unter Tarife „Free“, „Standard“ und „Premium“ von für die AKS-Clusterverwaltung.

  • Aktivieren Sie Zonenredundanz, wenn Sie Container Registry zum Speichern von Containerimages und Oracle Cloud Infrastructure (OCI)-Artefakten verwenden. Container Registry unterstützt die optionale Zonenredundanz und Georeplikation. Zonenredundanz bietet Resilienz und Hochverfügbarkeit für eine Registrierung oder Replikationsressource (Replikat) in einer bestimmten Region. Bei der Georeplikation werden Registrierungsdaten in einer oder mehreren Azure-Regionen repliziert, um die Verfügbarkeit zu gewährleisten und die Latenz für regionale Vorgänge zu reduzieren.

Notfallwiederherstellung und Geschäftskontinuität

  • Erwägen Sie die Bereitstellung Ihrer Lösung in zwei Regionen. Verwenden Sie die gekoppelte Azure-Region als zweite Region.

  • Stellen Sie sicher, dass Sie für jeden regionalen Failoverprozess in einer Qualitätssicherungsumgebung ein Skript und eine Dokumentation erstellen und ihn regelmäßig testen.

  • Testen Sie Failbackverfahren, um zu überprüfen, ob sie wie erwartet funktionieren.

  • Speichern Sie Ihre Containerimages in Container Registry. Führen Sie die Georeplikation der Registrierung für jede Region durch, in der Sie Ihre AKS-Lösung bereitstellen.

  • Speichern Sie den Dienststatus nach Möglichkeit nicht in einem Container. Speichern Sie den Dienststatus stattdessen in einer Azure-Platform-as-a-Service (PaaS)-Speicherlösung, die die Replikation in mehreren Regionen unterstützt. Diese Vorgehensweise verbessert die Ausfallsicherheit und vereinfacht die Notfallwiederherstellung, da Sie die kritischen Daten jedes Diensts in allen Regionen beibehalten können.

  • Wenn Sie Speicher verwenden, bereiten Sie Ihre Speicher vor und testen Sie sie, um Ihren Speicher aus der primären Region in die Sicherungsregion zu migrieren.

Sicherheit

Sicherheit bietet Sicherheitsmaßnahmen gegen bewusste Angriffe und den Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Sicherheit.

  • Verwenden Sie WAF, um von AKS gehostete Webanwendungen und -dienste zu schützen, 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. Befolgen Sie OWASP-Regeln und Ihre eigenen benutzerdefinierten Regeln. Azure Web Application Firewall (WAF) bietet einen verbesserten zentralisierten Schutz Ihrer Webanwendungen vor häufigen Exploits und Sicherheitsrisiken. Sie können ein Azure WAF mithilfe von Azure Application Gateway, Azure Front Door oder Azure Content Delivery Network bereitstellen.

  • Verwenden Sie Azure DDoS Protection und bewährte Verfahren für das Anwendungsdesign zum Schutz gegen über Workloads verteilte DDoS-Angriffe. Azure schützt seine Infrastruktur und Dienste vor DDoS-Angriffen. Dieser Schutz trägt dazu bei, die Verfügbarkeit von Regionen, Verfügbarkeitszonen und Diensten sicherzustellen. Außerdem sollten Sie die öffentlichen Endpunkte Ihres Workloads vor DDoS-Angriffen auf Ebene 4 und Ebene 7 schützen. Sie können Azure DDOS Protection in allen virtuellen Umkreisnetzwerken aktivieren.

  • Verwenden Sie die Azure Web Application Firewall-Regel für die Ratenbegrenzung für Azure Front Door, um die Anzahl der Anforderungen zu verwalten und zu steuern, die Sie von einer bestimmten Quell-IP-Adresse an Ihre Anwendung innerhalb einer definierten Ratenbegrenzungsdauer zulassen. Verwenden Sie dieses Feature, um Richtlinien zum Einschränken von Raten zu erzwingen und sicherzustellen, dass Sie Ihre Anwendung vor übermäßigem Datenverkehr oder potenziellem Missbrauch schützen. Konfigurieren Sie die Ratenbegrenzungsregel, um optimale Anwendungsleistung und Sicherheit aufrechtzuerhalten und eine differenzierte Kontrolle der Anforderungsgrenzwerte bereitzustellen.

  • Konfigurieren Sie die WAF-Richtlinie, die dem Azure Front Door-Modus zugeordnet ist, im Präventionsmodus. Im Präventionsmodus analysiert die WAF-Richtlinie eingehende Anforderungen und vergleicht sie mit den konfigurierten Regeln. Wenn eine Anforderung mit einer oder mehreren Regeln übereinstimmt, die so festgelegt sind, dass Datenverkehr verweigert wird, wenn sie erfüllt sind, hindert die WAF-Richtlinie den schädlichen Datenverkehr daran, Ihre Webanwendungen zu erreichen. Diese Maßnahme trägt zum Schutz Ihrer Anwendungen vor potenziellen Sicherheitsrisiken und nicht autorisierten Zugriffsversuchen bei. Weitere Informationen finden Sie unter Azure Web Application Firewall in Azure Front Door.

  • Erstellen Sie einen privaten Azure-Endpunkt für jeden PaaS-Dienst, den AKS-Workloads verwenden, wie etwa Key Vault, Azure Service Bus und Azure SQL Database. 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-Backbone-Netzwerk, die Kommunikation wird jedoch nicht über die Azure-Firewall geleitet. Ein privater Endpunkt bietet Sicherheit und Schutz gegen Datenlecks. Weitere Informationen finden Sie unter Was ist der private Link?.

  • Verwenden Sie eine WAF-Richtlinie, um öffentlich zugängliche von AKS gehostete Workloads gegen Angriffe zu schützen, wenn Sie Application Gateway vor dem AKS-Cluster verwenden.

  • Verwenden Sie Kubernetes-Netzwerkrichtlinien , um zu steuern, welche Komponenten miteinander kommunizieren können. Diese Steuerung trennt und hilft bei der Sicherung der Intraservice-Kommunikation. 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. Verwenden Sie Azure-Netzwerkrichtlinien, um die Zugriffssteuerung auf Netzwerkebene zu erzwingen. Verwenden Sie Calico-Netzwerkrichtlinien, um differenzierte Netzwerksegmentierungs- und Sicherheitsrichtlinien in Ihrem AKS-Cluster zu implementieren. Weitere Informationen finden Sie unter Sicherer Datenverkehr zwischen Pods durch Netzwerkrichtlinien in AKS.

  • Machen Sie für Ihre AKS-Knoten keine Remotekonnektivität verfügbar. Erstellen Sie einen Azure Bastion-Host oder Sprungfeld in einem virtuellen Verwaltungsnetzwerk. Leiten Sie den Datenverkehr über den Azure Bastion-Host zu Ihrem AKS-Cluster.

  • Erwägen Sie die Verwendung eines privaten AKS-Clusters in Ihrer Produktionsumgebung. Oder verwenden Sie zumindest autorisierte IP-Adressbereiche in AKS, um den Zugriff auf den API-Server zu sichern. 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.

Kostenoptimierung

Die Kostenoptimierung konzentriert sich auf Möglichkeiten, unnötige Ausgaben zu reduzieren und die betriebliche Effizienz zu verbessern. Weitere Informationen finden Sie unter Erstellen einer Checkliste zur Überprüfung der Kostenoptimierung.

Weitere Informationen finden Sie unter Kostenoptimierung und Optimieren der Kosten in AKS.

Optimaler Betrieb

„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 Erstellen einer Checkliste zur Überprüfung des optimalen Betriebs.

DevOps

  • Verwenden Sie ein Helm-Diagramm in einer kontinuierlichen Integrations- und Endlosbereitstellungspipeline, um Ihre Workloads für AKS bereitzustellen.

  • 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.

  • Verwenden Sie die Containerregistrierung oder eine Nicht-Microsoft-Registrierung, z. B. Harbor oder Docker Hub, um private Containerimages zu speichern, die im Cluster bereitgestellt werden.

  • Testen Sie den Dateneingang und -ausgang Ihrer Workloads in einer separaten Vorproduktionsumgebung, die die Netzwerktopologie und Firewallregeln Ihrer Produktionsumgebung widerspiegelt.

Überwachung

  • Verwenden Sie Container Insights, um den Integritätsstatus des AKS-Clusters und der Workloads zu überwachen.

  • Verwenden Sie den verwalteten Dienst für Prometheus, um im großen Stil Metriken unter Verwendung einer mit Prometheus kompatiblen Überwachungslösung zu erfassen und zu analysieren, die auf dem Prometheus-Projekt der Cloud Native Computing Foundation basiert.

  • Verbinden Sie Ihren verwalteten Dienst für Prometheus mit einer Azure Managed Grafana-Instanz, um ihn als Datenquelle in einem Grafana-Dashboard zu verwenden. Sie haben dann Zugriff auf mehrere vordefinierte Dashboards, die Prometheus-Metriken verwenden, und können auch benutzerdefinierte Dashboards erstellen.

  • Konfigurieren Sie alle PaaS-Dienste (z. B. Container Registry und Key Vault) so, dass sie Diagnoseprotokolle und Metriken in einem Azure Monitor Log-Arbeitsbereich sammeln.

Bereitstellen dieses Szenarios

Den Quellcode für dieses Szenario finden Sie auf GitHub. Diese Open-Source-Lösung wird unter der MIT-Lizenz bereitgestellt.

Voraussetzungen

Bereitstellen in Azure

  1. Klonen Sie das GitHub-Repository „workbench“.

    git clone https://github.com/Azure-Samples/aks-front-door-end-to-end-tls.git

  2. Befolgen Sie die Anweisungen in der Datei README. Für diesen Schritt benötigen Sie Ihre Azure-Abonnementinformationen.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

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

Nächste Schritte