Sicherheitskonzepte für Anwendungen und Cluster in Azure Kubernetes Service (AKS)

Die Containersicherheit schützt die gesamte End-to-End-Pipeline, von der Build-Phase bis zu den Anwendungsworkloads, die im Azure Kubernetes Service (AKS) ausgeführt werden.

Die sichere Lieferkette umfasst die Entwicklungsumgebung und das Register.

Kubernetes enthält Sicherheitskomponenten wie Pod-Sicherheitsstandards und Secrets. Azure umfasst Komponenten wie Microsoft Entra ID, Microsoft Defender für Container, Azure Policy, Azure Key Vault, Netzwerksicherheitsgruppen und koordinierte Clusterupgrades. AKS kombiniert diese Sicherheitskomponenten zu folgenden Zwecken:

  • Bereitstellen eines vollständigen Authentifizierungs- und Autorisierungsszenarios
  • Wenden Sie integrierte AKS-Azure Policy an, um Ihre Anwendungen zu schützen.
  • Durchgängige Einblicke vom Build bis in Ihre Anwendung mit Microsoft Defender für Container.
  • Ausführen der neuesten Betriebssystem-Sicherheitsupdates und Kubernetes-Versionen im AKS-Cluster
  • Sicherstellen eines sicheren Pod-Verkehrs und Zugangs zu sensiblen Anmeldeinformationen.

AKS unterstützt zwei Clustermodi: AKS Automatic and AKS Standard. Die Sicherheitskonzepte in diesem Artikel gelten für beide Modi, sofern nicht anders angegeben. AKS Automatic enthält eine gehärtete Sicherheitsbasislinie mit mehreren standardmäßig vorkonfigurierten Steuerelementen, während AKS Standard mehr Konfigurationsflexibilität bietet.

In diesem Artikel werden die wichtigsten Konzepte vorgestellt, mit denen Sie Anwendungen in AKS schützen können.

Von Bedeutung

Ab November 30, 2025 unterstützt Azure Kubernetes Service (AKS) keine Sicherheitsupdates mehr für Azure Linux 2.0. Das Azure Linux 2.0-Knoten-Image wurde am Release 202512.06.0 eingefroren. Ab dem 31. März 2026 werden Knotenimages entfernt, und Sie können Ihre Knotenpools nicht skalieren. Migrieren Sie zu einer unterstützten Azure Linux-Version, indem Sie Ihre Knotenpools zu einer unterstützten Kubernetes-Version aktualisieren oder zu osSku AzureLinux3 migrieren. Weitere Informationen finden Sie im GitHub-Problem „Außerbetriebnahme“ und in der Ankündigung zur Außerbetriebnahme von Azure-Updates. Um über Ankündigungen und Updates auf dem Laufenden zu bleiben, folgen Sie den AKS-Versionshinweisen.

Build-Sicherheit

Buildsicherheit ist der Einstiegspunkt für Ihre sichere Lieferkette. Bevor Images in Bereitstellungsumgebungen überführt werden, führen Sie in CI eine statische Analyse sowie eine Schwachstellen- und Compliance-Bewertung durch.

Verwenden Sie in beiden AKS-Modi risikobasierte Triage, anstatt alle Builds auf Sicherheitsrisiken zu blockieren. Priorisieren Sie die Wartung mithilfe des Lieferantenstatus und des Schweregrads, und wenden Sie Nachfristen für nicht ausnutzbare oder zeitgebundene Ausnahmen an.

AKS Automatic trägt dazu bei, nachgelagerte Konfigurationsabweichungen zu reduzieren, indem Cluster mit einer gehärteten Basiskonfiguration und vorkonfigurierten Sicherheitskontrollen bereitgestellt werden. Dadurch wird die Validierung der Bildqualität und der Richtlinienkonformität zur Build-Zeit noch wichtiger, da vertrauenswürdige Images zuverlässiger in eine sichere Laufzeitbasis überführt werden.

AKS Standard bietet mehr Flexibilität auf Clusterebene, daher sollten Build-Pipelines vor der Bereitstellung explizit die Baseline Ihrer Organisation für Image-Provenienz, Schwachstellen-Schwellenwerte und Policy-Gates durchsetzen.

Registrierungssicherheit

Die Registrierungssicherheit überprüft, ob nur vertrauenswürdige und kompatible Images für die Bereitstellung verfügbar sind und hilft, Drift nach dem Build zu erkennen. Prüfen Sie den Schwachstellenstatus in der Registry kontinuierlich, nicht nur zum Build-Zeitpunkt. Die Registrierungsüberprüfung erfasst neu offenbarte Sicherheitsrisiken und Bilder, die genehmigte Buildpfade umgangen haben. Verwenden Sie die Imagesignierung und -überprüfung, z. B. Notary V2, um sicherzustellen, dass Arbeitslasten aus vertrauenswürdigen Quellen mit nachweisbarer Provenienz bereitgestellt werden.

Bei AKS Automatic, wo mehrere Sicherheitsfunktionen für die Laufzeit vorkonfiguriert sind, bleiben Kontrollen auf Registry-Ebene ein entscheidender vorgelagerter Kontrollpunkt, um die Supply Chain der Laufzeit sauber zu halten. Wenden Sie für AKS Standard dieselben Registry-Steuerelemente an, und stimmen Sie sie auf die Konfiguration der Zulassungssteuerung und Richtlinien Ihres Clusters ab, um die durchgängige Verwendung vertrauenswürdiger Images zu erzwingen.

Clustersicherheit

In AKS sind die Kubernetes-Hauptkomponenten Teil des verwalteten Diensts, der von Microsoft bereitgestellt, verwaltet und gewartet wird. Jeder AKS-Cluster verfügt über eine eigene dedizierte Kubernetes-Steuerungsebene mit nur einem Mandanten, die den API-Server, den Scheduler usw. bereitstellt. Weitere Informationen finden Sie unter Schwachstellenverwaltung für Azure Kubernetes Service.

Standardmäßig verwendet der Kubernetes-API-Server eine öffentliche IP-Adresse und einen vollqualifizierten Domänennamen (FQDN). Sie können den Zugriff auf den API-Serverendpunkt mithilfe von autorisierten IP-Adressbereichen einschränken. Alternativ können Sie einen vollständig privaten Cluster erstellen, um den Zugriff des API-Servers auf Ihr virtuelles Netzwerk einzuschränken.

Für AKS Automatic ist die Integration des API-Servers in ein virtuelles Netzwerk als Teil der standardmäßigen Sicherheitskonfiguration vorkonfiguriert. In AKS Standard ist die gleiche Funktion verfügbar und kann basierend auf Ihrem Netzwerkdesign und Ihren Sicherheitsanforderungen aktiviert werden.

Sie können den Zugriff auf den API-Server mithilfe der rollenbasierten Zugriffssteuerung Kubernetes (Kubernetes RBAC) und Azure RBAC steuern. In AKS Automatic ist Azure RBAC für Kubernetes-Autorisierung vorkonfiguriert. In AKS Standard können Sie das Autorisierungsmodell auswählen und konfigurieren, das am besten zu Ihrer Umgebung passt. Weitere Informationen finden Sie unter Microsoft Entra Integration mit AKS.

Standardeinstellungen für die automatische AKS-Sicherheit

AKS Automatic enthält einen gehärteten Basisplan mit standardmäßig vorkonfigurierten Sicherheitssteuerelementen, einschließlich:

  • Azure RBAC für Kubernetes-Autorisierung
  • Integration des API-Servers in ein virtuelles Netzwerk
  • Workload-Identität und OIDC-Aussteller
  • Bereitstellungsvorkehrungen und grundlegende Pod-Sicherheitsstandards im Erzwingungsmodus
  • Bildreiniger zum Entfernen nicht verwendeter anfälliger Bilder
  • Sicherheitseinschränkungen für verwaltete Systemknotenpools, die Grenzen zwischen Kundenworkloads und von AKS verwalteter Infrastruktur beibehalten

AKS Standard unterstützt diese Funktionen mit größerer Flexibilität bei der Implementierung, erfordert jedoch möglicherweise explizite Aktivierung und Betriebsverwaltung.

Knotensicherheit

AKS-Knoten sind Azure virtuellen Computer (VMs). In AKS Standard verwalten Sie die Konfiguration und Lebenszyklusoptionen des Knotenpools. In AKS Automatic verwaltet AKS Systemknotenpools und Kernsystemkomponenten in Ihrem Auftrag, einschließlich Skalierung und Upgrades, mit Sicherheitseinschränkungen für die verwaltete Systeminfrastruktur.

Linux-Knoten führen optimierte Versionen von Ubuntu oder Azure Linux aus. Windows Server-Knoten führen eine optimierte Windows Server Version mit der containerd Container-Runtime aus.

Wenn ein AKS-Cluster erstellt oder hochskaliert wird, werden die Knoten automatisch mit den neuesten Betriebssystem-Sicherheitsupdates und -konfigurationen bereitgestellt.

Hinweis

AKS-Cluster mit:

  • Kubernetes-Version 1.19 und höher: Linux-Knotenpools verwenden containerd als Containerlaufzeit. Windows Server 2019 und Windows Server 2022 Knotenpools verwenden containerd als Containerlaufzeit. Weitere Informationen finden Sie unter Windows Server-Nodepool hinzufügen mit containerd.
  • Kubernetes, Version 1.19 und früher: Linux-Knotenpools verwenden Docker als Containerlaufzeit.

Weitere Informationen zum Sicherheitsupgradeprozess für Linux- und Windows Workerknoten finden Sie unter Security Patching nodes.

AKS-Cluster, die Azure VMs der Generation 2 ausführen, enthalten Unterstützung für Trusted Launch. Dieses Feature schützt vor erweiterten und persistenten Angriffstechniken, indem Sie Technologien kombinieren, die Sie unabhängig aktivieren können, z. B. sicherer Start und eine virtualisierte Version des vertrauenswürdigen Plattformmoduls (vTPM). Administratoren können AKS-Workerknoten mit überprüften und signierten Bootloadern, Betriebssystem-Kernel und Treibern bereitstellen, um die Integrität der gesamten Startkette des zugrunde liegenden virtuellen Computers sicherzustellen.

Container- und sicherheitsoptimierte Betriebssystemoptionen

Azure Container Linux (ACL) ist ein unveränderliches, containeroptimiertes Betriebssystem für AKS. ACL ist aus dem Flatcar Container Linux-Projekt hervorgegangen und baut auf Flatcars bewährter, containerorientierter, unveränderlicher Architektur auf, ergänzt um Azure Linux-Pakete, Wartung und Plattformintegration. Dies ermöglicht es ACL, eng mit den vorgelagerten Flatcar-Innovationen in Einklang zu bleiben und gleichzeitig die Produktions-, Sicherheits- und Complianceanforderungen Azure zu erfüllen. Weitere Informationen zu Flatcar Container Linux finden Sie in der Flatcar-Dokumentation.

ACL ist allgemein verfügbar (GA) als Betriebssystemoption auf AKS ab AKS v1.34. Sie können ACL-Knotenpools in einem neuen AKS-Cluster bereitstellen, Ihren vorhandenen Clustern ACL-Knotenpools hinzufügen und vorhandene Linux-Knotenpools zu ACL migrieren.

Weitere Informationen zu ACL finden Sie unter Azure Container Linux (ACL) for AKS overview.

Knotenberechtigung

Die Knotenautorisierung ist ein spezieller Autorisierungsmodus, der speziell Kubelet-API-Anforderungen zum Schutz vor Ost-West-Angriffen autorisiert. Die Knotenautorisierung ist standardmäßig auf AKS 1.24+-Clustern aktiviert.

Knotenbereitstellung

Knoten werden auf einem Subnetz eines privaten virtuellen Netzwerks bereitgestellt, ohne dass öffentliche IP-Adressen zugewiesen werden. Zur Problembehandlung und Verwaltung ist SSH standardmäßig aktiviert, und es kann nur über die interne IP-Adresse darauf zugegriffen werden. Die Deaktivierung von SSH erfolgt während der Erstellung von Clustern und Knotenpools. Für einen vorhandenen Cluster oder Knotenpool ist diese Option als Vorschau verfügbar. Weitere Informationen finden Sie unter Verwalten des SSH-Zugriffs.

Knotenspeicher

Um Speicher bereitzustellen, verwenden die Knoten Azure Managed Disks. Bei den meisten VM-Knotengrößen sind Azure Managed Disks Premium-Datenträger, die von leistungsstarken SSDs unterstützt werden. Die auf verwalteten Datenträgern gespeicherten Daten werden automatisch innerhalb der Azure-Plattform verschlüsselt. Um Redundanz zu verbessern, werden Azure Managed Disks innerhalb des Azure Rechenzentrums sicher repliziert.

Feindliche Workloads mit mehreren Mandanten

Derzeit sind Kubernetes-Umgebungen nicht sicher vor einer feindlichen Verwendung mit mehreren Mandanten. Mit zusätzlichen Sicherheitsfeatures wie Pod-Sicherheitsrichtlinien oder Kubernetes RBAC für Knoten können effizient Exploits blockiert werden. Um echte Sicherheit bei der Ausführung feindlicher Workloads mit mehreren Mandanten zu erzielen, vertrauen Sie nur einem Hypervisor. Die Sicherheitsdomäne für Kubernetes wird zum gesamten Cluster und nicht zu einem einzelnen Knoten.

Für diese Art von feindlichen Workloads mit mehreren Mandanten sollten Sie physisch isolierte Cluster verwenden. Weitere Informationen zu Möglichkeiten zur Isolierung von Workloads finden Sie unter Bewährte Methoden für die Isolierung der Cluster in AKS.

Computeisolation

Bestimmte Workloads erfordern möglicherweise aufgrund von Compliance- oder gesetzlichen Anforderungen einen hohen Grad an Isolation von anderen Kundenworkloads. Für diese Workloads bietet Azure Folgendes:

  • Isolierte Kernelcontainer, die als Agent-Knoten in einem AKS-Cluster verwendet werden. Diese Container sind vollständig auf einen bestimmten Hardwaretyp isoliert und von der Azure Host fabric, dem Hostbetriebssystem und dem Hypervisor isoliert. Sie sind einem einzelnen Kunden gewidmet. Wählen Sie beim Erstellen eines AKS-Clusters oder Hinzufügen eines Knotenpools eine der isolierten VM-Größen als Knotengröße aus.
  • Vertrauliche Container (Vorschau), basieren auch auf Kata Confidential Containers, verschlüsseln den Containerspeicher und verhindern, dass Daten während der Berechnung als Klartext, in lesbarem Format gespeichert oder manipuliert werden. Dadurch können Ihre Container von anderen Containergruppen/Pods sowie vom Betriebssystemkernel des VM-Knotens isoliert werden. Vertrauliche Container (Vorschau) verwenden hardwarebasierte Speicherverschlüsselung (SEV-SNP).
  • Pod Sandboxing (Vorschau) bietet eine Isolationsgrenze zwischen der Containeranwendung und den gemeinsam genutzten Kernel- und Computeressourcen (CPU, Speicher und Netzwerk) des Containerhosts.

Netzwerksicherheit

Für Konnektivität und Sicherheit mit lokalen Netzwerken können Sie Ihren AKS-Cluster in vorhandenen Azure virtuellen Netzwerksubnetzen bereitstellen. Diese virtuellen Netzwerke stellen mithilfe von Azure Site-to-Site-VPN oder ExpressRoute eine Verbindung mit Ihrem lokalen Netzwerk her. Definieren Sie Kubernetes-Eingangscontroller mit privaten, internen IP-Adressen, um den Zugriff von Diensten auf die interne Netzwerkverbindung zu beschränken.

In AKS Automatic sind Funktionen für verwaltete virtuelle Netzwerke sowie zentrale Standardvorgaben für ein- und ausgehenden Datenverkehr vorkonfiguriert, um eine sichere Basis bereitzustellen. In AKS Standard sind Netzwerkmodelle und Eingangs-/Eingangssteuerelemente flexibler und sollten basierend auf Ihrer Sicherheitsarchitektur ausgewählt werden.

Azure Netzwerksicherheitsgruppen

Zum Filtern des Datenverkehrsflusses für virtuelle Netzwerke verwendet Azure Regeln für Netzwerksicherheitsgruppen. Diese Regeln bestimmen die Quell- und Ziel-IP-Adressbereiche, Ports und Protokolle, denen der Zugriff auf Ressourcen gewährt oder verweigert wird. Standardregeln werden erstellt, um TLS-Datenverkehr zum Kubernetes-API-Server zu ermöglichen. Sie erstellen Dienste mit Lastenausgleichsmodulen, Portzuordnungen oder Eingangsrouten. AKS ändert automatisch die Netzwerksicherheitsgruppe für den Datenverkehrsfluss.

Wenn Sie Ihr eigenes Subnetz für Ihren AKS-Cluster bereitstellen (unabhängig davon, ob Sie Azure CNI oder Kubenet verwenden), ändern Sie nicht die von AKS verwaltete Netzwerksicherheitsgruppe auf NIC-Ebene. Erstellen Sie stattdessen weitere Netzwerksicherheitsgruppen auf Subnetzebene, um den Datenverkehrsfluss zu ändern. Stellen Sie sicher, dass diese nicht den für die Verwaltung des Clusters erforderlichen Datenverkehr beeinträchtigen, z. B. den Zugriff auf das Lastenausgleichsmodul, die Kommunikation mit der Steuerungsebene oder den ausgehenden Datenverkehr.

Kubernetes-Netzwerkrichtlinie

Zur Einschränkung von Netzwerkdatenverkehr zwischen Pods in Ihrem Cluster bietet AKS Unterstützung für Kubernetes-Netzwerkrichtlinien. Mit Netzwerkrichtlinien können Sie den Zugriff auf bestimmte Netzwerkpfade im Cluster basierend auf Namespaces und Bezeichnungsselektoren zulassen oder verweigern.

Anwendungssicherheit

Um Pods zu schützen, die auf AKS ausgeführt werden, sollten Sie Microsoft Defender für Container in Betracht ziehen, um Cyberangriffe auf Ihre Anwendungen zu erkennen und einzuschränken, die in Ihren Pods ausgeführt werden. Führen Sie kontinuierliche Überprüfungen durch, um Abweichungen im Sicherheitsrisikostatus Ihrer Anwendung zu erkennen, und implementieren Sie einen „blauen/grünen/Canary-“Prozess, um die anfälligen Images zu patchen und zu ersetzen.

In AKS Automatic sind workload identity und OIDC issuer vorkonfiguriert, um den sicheren Workloadzugriff auf Azure Services zu vereinfachen. In AKS Standard sind diese Funktionen verfügbar und können als Teil Ihrer grundlegenden Sicherheitslage aktiviert werden.

Sicherer Containerzugriff auf Ressourcen

Nicht nur Benutzern und Gruppen sollten lediglich die erforderlichen Mindestberechtigungen gewährt werden, auch Container sollten auf die Aktionen und Prozesse beschränkt werden, die unbedingt erforderlich sind. Konfigurieren Sie zur Minimierung des Angriffsrisikos nach Möglichkeit keine Anwendungen und Container, die ausgeweitete Berechtigungen oder Root-Zugriff benötigen. Integrierte Linux-Sicherheitsfeatures wie AppArmor und Seccomp werden als bewährte Methoden empfohlen, um den Containerzugriff auf Ressourcen zu sichern.

Kubernetes-Geheimnisse

Mit einem Kubernetes-Geheimnis fügen Sie sensible Daten wie Anmeldeinformationen oder Schlüssel für den Zugriff in Pods ein.

  1. Erstellen Sie ein Geheimnis mit der Kubernetes-API.
  2. Definieren Sie Ihren Pod oder Ihre Bereitstellung, und fordern Sie ein bestimmtes Geheimnis an.
    • Geheimnisse werden nur für Knoten mit einem geplanten Pod bereitgestellt, der diese erfordert.
    • Das Geheimnis wird in tmpfs gespeichert und nicht auf den Datenträger geschrieben.
  3. Wenn Sie den letzten Pod auf einem Knoten löschen, der ein Secret erfordert, wird das Secret aus tmpfs des Knotens gelöscht.
    • Geheimnisse werden in einem bestimmten Namespace gespeichert und sind nur für Pods im gleichen Namespace zugänglich.

Die Verwendung von Geheimnissen reduziert die vertraulichen Informationen, die im YAML-Manifest für den Pod oder den Dienst definiert werden. Stattdessen fordern Sie im Rahmen Ihres YAML-Manifests das im Kubernetes-API-Server gespeicherte Geheimnis an. Mit diesem Ansatz erhält nur der bestimmte Pod Zugriff auf das Geheimnis.

Hinweis

Die unformatierten geheimen Manifestdateien enthalten die geheimen Daten im Base64-Format. Weitere Informationen finden Sie in der offiziellen Dokumentation. Behandeln Sie diese Dateien wie vertrauliche Informationen, und committen Sie sie niemals in die Quellcodeverwaltung.

Kubernetes-Geheimnisse werden in etcd gespeichert, einem verteilten Schlüssel-Wert-Speicher. AKS ermöglicht die Verschlüsselung ruhender Geheimnisse in etcd mithilfe von kundschaftsgesteuerten Schlüsseln.

Verwandte Inhalte

Die ersten Schritte zum Sichern Ihrer AKS-Cluster sind unter Aktualisieren eines AKS-Clusters beschrieben.

Wenn Sie modusspezifische Standardwerte und betriebliche Verantwortlichkeiten auswerten, lesen Sie What is Azure Kubernetes Service (AKS) Automatic?

Entsprechende bewährte Methoden finden Sie unter Best Practices für Clustersicherheit und Upgrades in Azure Kubernetes Service (AKS) und Best Practices für Podsicherheit in Azure Kubernetes Service (AKS).

Weitere Informationen zu den wesentlichen Konzepten von Kubernetes und AKS finden Sie unter folgenden Themen:

  • Last updated on