Freigeben über

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

  • Artikel

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 Buildumgebung und die Registrierung.

Kubernetes enthält Sicherheitskomponenten wie Podsicherheitsstandards und Geheimnisse. 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 für Container.
  • Ausführen der neuesten Betriebssystem-Sicherheitsupdates und Kubernetes-Versionen im AKS-Cluster
  • Bereitstellen eines sicheren Datenverkehrs zwischen Pods und sicheren Zugriffs auf sensible 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 dedizierten Kubernetes-Master mit einem einzelnen Mandanten, um API-Server, Scheduler usw. bereitzustellen. Weitere Informationen finden Sie unter Sicherheitsrisikoverwaltung 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.
  • Auf Windows Server-Knoten wird eine optimierte Version von Windows Server 2022 mithilfe der Containerruntime containerd ausgeführt.

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

Hinweis

AKS-Cluster mit:

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

Weitere Informationen zum Sicherheitsupgradeprozess für Linux- und Windows-Workerknoten finden Sie unter Security patching nodes (Sicherheitspatches für Knoten).

AKS-Cluster, die Azure-VMs der Generation 2 ausführen, unterstützen den vertrauenswürdigen Start, der vor erweiterten und persistenten Angriffstechniken schützt, indem Technologien kombiniert werden, die unabhängig aktiviert werden können, z. B. sicherer Start und virtualisierte Version des Trusted Platform Module (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.

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 in einem Subnetz des privaten virtuellen Netzwerks ohne öffentliche IP-Adressen bereitgestellt. 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. Mithilfe zusätzlicher Sicherheitsfeatures wie Podsicherheitsrichtlinien oder Kubernetes RBAC für Knoten können Exploits effizient 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 einem bestimmten Hardwaretyp und von der Azure-Host-Fabric, dem Hostbetriebssystem und dem Hypervisor isoliert. Sie sind für einen einzelnen Kunden vorgesehen. 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. Sie helfen dabei, Ihre Container von anderen Containergruppen/Pods sowie vom Betriebssystemkernel des VM-Knotens zu isolieren. 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 Geheimnis erfordert, wird das Geheimnis 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 spezielle 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. Der etcd-Speicher wird vollständig von AKS verwaltet, und Daten werden im Ruhezustand innerhalb der Azure-Plattform verschlüsselt.

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: