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

Die Containersicherheit schützt die gesamte End-to-End-Pipeline vom Build bis zu den Anwendungsworkloads, die in 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 for Containers, Azure Policy, Azure Key Vault, Netzwerksicherheitsgruppen und orchestrierte Clusterupgrades. AKS kombiniert diese Sicherheitskomponenten zu folgenden Zwecken:

• Bereitstellen eines vollständigen Authentifizierungs- und Autorisierungsszenarios
• Anwenden von in AKS integrierten Azure-Richtlinien zum Schutz Ihrer Anwendungen
• End-to-End-Erkenntnis vom Build über Ihre Anwendung mit Microsoft Defender for Containers.
• 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-Masterkomponenten Bestandteil des verwalteten Diensts, der von Microsoft bereitgestellt, verwaltet und gewartet wird. Jeder AKS-Cluster verfügt über seinen eigenen, eigens für einen einzigen Mandanten konzipierten Kubernetes-Master, der den API-Server, Scheduler usw. bereitstellt. Weitere Informationen finden Sie unter Schutz vor Sicherheitsrisiken für Azure Kubernetes Service (AKS).

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.

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

Knotensicherheit

AKS-Knoten sind virtuelle Azure-Computer (VMs), die von Ihnen verwaltet und gewartet werden.

• 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 Containerlaufzeit 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 (Sicherheitspatches für Knoten).

AKS-Cluster, auf denen VMs der Azure Generation 2 ausgeführt werden, umfassen Unterstützung für den vertrauenswürdigen Start. 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) wird 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 die obligatorische Zugriffssteuerung.
• Azure Linux OS Guard erzwingt FIPS - und Trusted Launch-Aktivierung und bietet verbesserten Compliance- und Schutz vor erweiterten und persistenten Angriffen, indem sichere Start- und virtualisierte Version des vertrauenswürdigen Plattformmoduls (vTPM) kombiniert wird.

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 unternehmensfähigen, 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

Die Knoten verwenden Azure Managed Disks, um Speicher bereitzustellen. Bei den meisten VM-Knotengrößen handelt es sich bei Azure Managed Disks um Premium-Datenträger, die von Hochleistungs-SSDs unterstützt werden. Die auf verwalteten Datenträgern gespeicherten Daten werden im Ruhezustand auf der Azure-Plattform automatisch verschlüsselt. Zur Verbesserung der Redundanz werden Azure Managed Disks sicher im Azure-Rechenzentrum 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 abgestimmt und von der Azure-Host-Fabric, dem Host-Betriebssystem und dem Hypervisor getrennt. 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 bei lokalen Netzwerken können Sie Ihren AKS-Cluster in Subnetzen eines vorhandenen virtuellen Azure-Netzwerks bereitstellen. Diese virtuellen Netzwerke stellen über Azure-Site-to-Site-VPN oder ExpressRoute eine Verbindung zurück zu 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 in virtuellen Netzwerken verwendet Azure Netzwerksicherheitsgruppen-Regeln. 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 (egal ob Azure CNI oder Kubenet) bereitstellen, ä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

Verwenden Sie zum Schutz von Pods, die in AKS ausgeführt werden, ggf. Microsoft Defender for Containers, um Cyberangriffe auf Ihre in Pods ausgeführten Anwendungen zu erkennen und einzuschränken. 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 zum [Schützen des Containerzugriffs auf Ressourcen][secure-container-access] empfohlen.

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