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

  • Artikel
  • 7 Minuten Lesedauer

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. Informationen dazu, wie Microsoft Sicherheitsrisiken verwaltet, und Details zum Veröffentlichen von Sicherheitsupdates für verwaltete Pars eines AKS-Clusters finden Sie unter Vulnerability management for Azure Kubernetes Service (AKS) (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 Azure AD-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 Mariner aus.
  • Auf Windows Server-Knoten wird eine optimierte Version von Windows Server 2019 mit containerd oder Docker als Containerruntime 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 für Linux-Knotenpools verwenden containerd als Containerruntime. Die Verwendung von containerd mit Windows Server 2019-Knotenpools befindet sich derzeit in der Vorschau. Weitere Informationen finden Sie unter Hinzufügen eines Windows Server-Knotenpools mit containerd.
  • Ältere Kubernetes-Versionen (vor Version 1.19) für Linux-Knotenpools verwenden Docker als Containerruntime. Für Windows Server 2019-Knotenpools wird Docker als Standardcontainerruntime verwendet.

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

Knotenberechtigung

Die Knotenautorisierung ist ein spezieller Autorisierungsmodus, der speziell API-Anforderungen von Kubelets 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-Adresse bereitgestellt. Zur Problembehandlung und Verwaltung ist SSH standardmäßig aktiviert, und es kann nur über die interne IP-Adresse darauf zugegriffen werden.

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 isolierte VMs zur Verwendung als Agentknoten in einem AKS-Cluster. Diese VMs sind für einen bestimmten Hardwaretyp isoliert und für einen einzelnen Kunden bestimmt.

Wählen Sie beim Erstellen eines AKS-Clusters oder Hinzufügen eines Knotenpools eine der isolierten VM-Größen als Knotengröße aus.

Clusterupgrades

Azure bietet Tools für die Upgradeorchestrierung, um ein Upgrade eines AKS-Clusters und seiner Komponenten durchzuführen, Sicherheit und Compliance zu gewährleisten und auf die neuesten Features zuzugreifen. Diese Upgradeorchestrierung umfasst sowohl die Kubernetes-Master- als auch die Agent-Komponenten.

Um den Upgradevorgang zu starten, geben Sie eine der aufgelisteten, verfügbaren Kubernetes-Versionen an. Azure verwendet dann für jeden AKS-Knoten den sicheren Vorgang des Absperrens und Ausgleichens und führt das Upgrade aus.

Absperren und Ausgleichen

Während des Upgrades werden AKS-Knoten einzeln vom Cluster abgesperrt, damit auf ihnen keine neuen Pods geplant werden. Die Knoten werden dann wie folgt ausgeglichenund aktualisiert:

  1. Ein neuer Knoten wird im Knotenpool bereitgestellt.
    • Dieser Knoten führt das neueste Betriebssystemimage und die neuesten Patches aus.
  2. Einer der bereits vorhandenen Knoten wird für das Upgrade identifiziert.
  3. Pods auf dem identifizierten Knoten werden ordnungsgemäß beendet und auf den anderen Knoten im Knotenpool geplant.
  4. Der geleerte Knoten wird aus dem AKS-Cluster gelöscht.
  5. Die Schritte 1 bis 4 werden wiederholt, bis alle Knoten im Rahmen des Upgradevorgangs erfolgreich ersetzt wurden.

Weitere Informationen finden Sie unter Aktualisieren eines AKS-Clusters.

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

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 Einzelheiten 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 Platform 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: