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 Active Directory, 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 die integrierten AKS-Azure Policy an, um Ihre Anwendungen zu schützen.
• End-to-End-Einblicke vom Build-Prozess bis hin zu Ihrer 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.

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

Buildsicherheit

Als Einstiegspunkt für die Lieferkette ist es wichtig, eine statische Analyse von Imagebuilds durchzuführen, bevor sie über die Pipeline heraufgestuft werden. Dies schließt die Sicherheitsrisiko- und Konformitätsbewertung ein. Es geht nicht darum, ein Build wegen eines Sicherheitsrisikos zu verwerfen, denn das würde die Entwicklung unterbrechen. Es geht darum, den Anbieterstatus basierend auf Sicherheitsrisiken zu segmentieren, für die von den Entwicklungsteams Maßnahmen ergriffen werden können. Nutzen Sie auch Toleranzperioden, um Entwicklern Zeit zum Beheben identifizierter Probleme zu geben.

Registrierungssicherheit

Durch die Bewertung des Sicherheitsrisikostatus des Images in der Registrierung werden Abweichungen erkannt und auch Images abgefangen, die nicht aus Ihrer Buildumgebung stammen. Verwenden Sie Notary V2, um Signaturen an Ihre Images anzufügen, um sicherzustellen, dass Bereitstellungen von einem vertrauenswürdigen Speicherort stammen.

Clustersicherheit

In AKS sind die Kubernetes-Hauptkomponenten Teil des verwalteten Dienstes, der von Microsoft bereitgestellt, verwaltet und instandgehalten wird. Jeder AKS-Cluster verfügt über seinen eigenen dedizierten Kubernetes-Master mit einem einzelnen Mandanten, um API-Server, Scheduler usw. bereitzustellen. Weitere Informationen finden Sie unter Sicherheitsrisikoverwaltung 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.

Sie können den Zugriff auf den API-Server mithilfe der rollenbasierten Zugriffssteuerung Kubernetes (Kubernetes RBAC) und Azure RBAC steuern. Weitere Informationen finden Sie unter Microsoft Entra Integration mit AKS.

Knotensicherheit

AKS-Knoten sind Azure-virtuelle Computer (VMs), die Sie verwalten und pflegen.

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

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

AKS hat Unterstützung für zwei neue optimierte Linux-Betriebssystemoptionen veröffentlicht. Azure Linux OS Guard (Vorschau) wurde von Microsoft erstellt und für Azure optimiert. OS Guard basiert auf Azure Linux mit spezieller Konfiguration zur Unterstützung von containerisierten Workloads mit Sicherheitsoptimierungen. Flatcar Container Linux für AKS (Vorschau) ist ein CNCF-basiertes, herstellerneutrales containeroptimiertes, unveränderliches Betriebssystem, das am besten für die Ausführung in Multicloud- und lokalen Umgebungen geeignet ist. Diese Betriebssystemoptionen bieten eine höhere Sicherheit im Vergleich zu anderen Linux-Betriebssystemoptionen, z. B.:

• Sowohl Azure Linux OS Guard als auch Flatcar Container Linux für AKS verfügen über ein unveränderliches Betriebssystem, das Sie zur Laufzeit nicht ändern können. Alle Betriebssystem-Binärdateien, Bibliotheken und statische Konfigurationen sind schreibgeschützt, und die Bit-for-Bit-Integrität ist häufig kryptografisch geschützt. Diese speziellen Betriebssysteme werden als eigenständige Bilder geliefert und ohne jegliche Art von Paketverwaltung oder anderen herkömmlichen Mitteln zum Ändern des Betriebssystems geliefert. Benutzerworkloads werden in einer vom Betriebssystem isolierten Sandboxumgebung (Container) ausgeführt.
• Sowohl Azure Linux OS Guard als auch Flatcar Container Linux für AKS verwenden SELinux für obligatorische Access Control.
• Azure Linux OS Guard erzwingt die Aktivierung von FIPS und Trusted Launch und bietet verbesserte Compliance und Schutz vor fortgeschrittenen und beharrlichen Angriffen, indem sicherer Startvorgang und die virtualisierte Version des vertrauenswürdigen Plattformmoduls (vTPM) kombiniert werden.

Bei der Entscheidung zwischen den zu verwendenden containeroptimierten Betriebssystemoptionen empfiehlt AKS Folgendes:

• Verwenden Sie Flatcar Container Linux für AKS (Vorschau), wenn Sie nach einem anbieterneutralen unveränderlichen Betriebssystem mit cloudübergreifender Unterstützung suchen.
• Verwenden Sie Azure Linux OS Guard (Vorschau) wenn Sie nach einem unternehmensbereiten unveränderlichen Betriebssystem suchen, das von Microsoft empfohlen wird.
• Verwenden Sie Ubuntu , wenn Sie nach einem anbieterneutralen, allgemeinen Betriebssystem mit cloudübergreifendem Support suchen.
• Verwenden Sie Azure Linux wenn Sie nach einem unternehmensfähigen, allgemeinen Betriebssystem suchen, das von Microsoft empfohlen wird.

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.

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.

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.

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.

Nächste Schritte

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

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:

• Kubernetes/AKS: Cluster und Workloads
• Kubernetes/AKS: Identität
• Kubernetes/AKS: virtuelle Netzwerke
• Kubernetes/AKS: Speicher
• Kubernetes/AKS Scale