Best Practices für Clustersicherheit und Upgrades in Azure Kubernetes Service (AKS)
Beim Verwalten von Clustern in Azure Kubernetes Service (AKS) ist die Sicherheit Ihrer Workloads und Daten ein wichtiger Faktor. Wenn Sie Cluster mit mehreren Mandanten und logischer Isolierung verwenden, muss der Zugriff auf Ressourcen und Workloads besonders geschützt werden. Wenden Sie die neuesten Sicherheitsupdates für Kubernetes und das Knotenbetriebssystem an, um das Angriffsrisiko zu minimieren.
In diesem Artikel wird erläutert, wie AKS-Cluster gesichert werden. Folgendes wird vermittelt:
- Verwenden Sie Microsoft Entra ID und rollenbasierte Zugriffssteuerung in Kubernetes (Role-Based Access Control, RBAC) zum Schutz des API-Serverzugriffs.
- Schützen des Containerzugriffs auf Knotenressourcen
- Upgraden eines AKS-Clusters auf die neueste Kubernetes-Version
- Aktualisieren von Knoten und automatisches Anwenden von Sicherheitspatches
Weitere Informationen finden Sie unter Best Practices für Containerimageverwaltung und Sicherheit in Azure Kubernetes Service (AKS) und Best Practices für Podsicherheit in Azure Kubernetes Service (AKS).
Aktivieren des Bedrohungsschutzes
Best Practices-Leitfaden
Sie können Defender für Container aktivieren, um Ihre Container zu schützen. Defender für Container kann Clusterkonfigurationen bewerten und Sicherheitsempfehlungen bereitstellen, Sicherheitsüberprüfungen ausführen und Echtzeitschutz sowie Warnungen für Kubernetes-Knoten und -Cluster bereitstellen.
Sicherer Zugriff auf API-Server und Clusterknoten
Best Practices-Leitfaden
Eine der wichtigsten Maßnahmen zum Schutz Ihres Clusters ist der Schutz des Zugriffs auf den Kubernetes-API-Server. Um den Zugriff auf den API-Server zu steuern, integrieren Sie Kubernetes RBAC mit Microsoft Entra ID. Dadurch können Sie AKS auf die gleiche Weise schützen wie den Zugriff auf Ihre Azure-Abonnements.
Der Kubernetes API-Server stellt einen einzelnen Verbindungspunkt zur Verfügung, der für Aktionsanforderungen innerhalb eines Clusters zuständig ist. Beschränken Sie den Zugriff, und gewähren Sie so wenige Berechtigungen wie möglich, um den Zugriff auf den API-Server zu schützen und zu überwachen. Diese Vorgehensweise ist nicht Kubernetes-spezifisch, aber besonders wichtig, wenn Ihr AKS-Cluster für die Verwendung mit mehreren Mandanten logisch isoliert ist.
Microsoft Entra ID bietet eine Lösung zur Identitätsverwaltung für Unternehmen, die in AKS-Cluster integriert werden kann. Da von Kubernetes keine Identitätsverwaltungslösung bereitgestellt wird, ist es möglicherweise schwierig, den Zugriff auf den API-Server präzise einzuschränken. Wenn Sie in AKS Cluster verwenden, die in Microsoft Entra integriert sind, authentifizieren Sie Benutzer*innen auf dem API-Server anhand von bestehenden Benutzer- und Gruppenkonten.
Mit Kubernetes RBAC und Microsoft Entra ID-Integration können Sie den API-Server schützen und die erforderlichen Mindestberechtigungen für einen bereichsbezogenen Ressourcensatz (z. B. einen einzelnen Namespace) gewähren. Sie können verschiedenen Microsoft Entra-Benutzer*innen oder -Gruppen unterschiedliche Kubernetes-Rollen zuweisen. Mit präzisen Berechtigungen können Sie den Zugriff auf den API-Server beschränken und ein eindeutiges Überwachungsprotokoll mit den durchgeführten Aktionen bereitstellen.
Es empfiehlt sich, Zugriff auf Dateien und Ordner nicht einzelnen Identitäten, sondern Gruppen zu gewähren. Verwenden Sie also beispielsweise anstelle einzelner Benutzer*innen eine Microsoft Entra ID-Gruppenmitgliedschaft, um Benutzer*innen an Kubernetes-Rollen zu binden. In diesem Fall ändern sich die Zugriffsberechtigungen eines Benutzers im AKS-Cluster automatisch, wenn sich die Gruppenmitgliedschaft des Benutzers ändert.
Nehmen wir nun an, Sie binden den einzelnen Benutzer direkt an eine Rolle, und sein Tätigkeitsbereich ändert sich. Die Microsoft Entra-Gruppenmitgliedschaften werden zwar aktualisiert, die Berechtigungen für den AKS-Cluster bleiben jedoch unverändert. In diesem Szenario hätte der Benutzer letzten Endes mehr Berechtigungen als er benötigt.
Weitere Informationen zu Microsoft Entra-Integration, Kubernetes RBAC und Azure RBAC finden Sie unter Best Practices bei Autorisierung und Authentifizierung für AKS.
Einschränken des Zugriffs auf die Instanzmetadaten-API
Best Practices-Leitfaden
Fügen Sie in allen Benutzernamespaces eine Netzwerkrichtlinie hinzu, um ausgehende Pod-Daten an den Metadatenendpunkt zu blockieren.
Hinweis
Um die Netzwerkrichtlinie zu implementieren, fügen Sie das Attribut --network-policy azure beim Erstellen des AKS-Clusters ein. Erstellen Sie mit dem folgenden Befehl den Cluster: az aks create -g myResourceGroup -n myManagedCluster --network-plugin azure --network-policy azure --generate-ssh-keys
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: restrict-instance-metadata
spec:
podSelector:
matchLabels: {}
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.10.0.0/0#example
except:
- 169.254.169.254/32
Sicherer Containerzugriff auf Ressourcen
Best Practices-Leitfaden
Begrenzen Sie den Zugriff auf Aktionen, die von Containern ausgeführt werden können. Gewähren Sie möglichst wenige Berechtigungen, und vermeiden Sie die Verwendung von Root-Zugriff oder Rechteausweitung.
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.
Wenn Sie die Steuerungsmöglichkeiten für Containeraktionen noch feiner abstimmen möchten, können Sie dazu auch integrierte Linux-Sicherheitsfeatures wie AppArmor und seccomp verwenden. Weitere Informationen finden Sie unter Sicherer Containerzugriff auf Ressourcen.
Regelmäßiges Update auf die neueste Version von Kubernetes
Best Practices-Leitfaden
Upgraden Sie regelmäßig die Kubernetes-Version in Ihrem AKS-Cluster, um alle neuen Features und Fehlerbehebungen zu erhalten.
Kubernetes veröffentlicht neue Features viel schneller als herkömmliche Infrastrukturplattformen. Kubernetes-Updates umfassen Folgendes:
- Neue Funktionen
- Fehler- oder Sicherheitskorrekturen
Neue Features durchlaufen normalerweise eine Alpha- und eine Beta-Phase, bevor sie als stabil eingestuft werden. Wenn sie stabil sind, werden sie allgemein verfügbar gemacht und für den Einsatz in der Produktion empfohlen. Der Releasezyklus für neue Kubernetes-Features ermöglicht es Ihnen, Kubernetes zu aktualisieren, ohne ständige auf Breaking Changes zu treffen oder Ihre Bereitstellungen und Vorlagen anpassen zu müssen.
AKS unterstützt drei Nebenversionen von Kubernetes. Wenn eine neue Patchnebenversion veröffentlicht wird, laufen die älteste Nebenversion und die unterstützten Patchreleases aus. Kleinere Kubernetes-Updates werden regelmäßig durchgeführt. Sorgen Sie für einen Governance-Prozess mit regelmäßiger Überprüfung auf erforderliche Upgrades, um weiterhin Support zu erhalten. Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen in Azure Kubernetes Service (AKS).
Wenn Sie überprüfen möchten, welche Versionen für Ihren Cluster verfügbar sind, verwenden Sie den Befehl az aks get-upgrades wie im folgenden Beispiel zu sehen:
az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Anschließend können Sie Ihren AKS-Cluster mithilfe des Befehls az aks upgrade upgraden. Der Upgradeprozess umfasst die folgenden sicheren Schritte:
- Er sperrt die Knoten sicher nacheinander ab und gleicht sie aus.
- Er plant Pods für die verbleibenden Knoten.
- Er stellt einen neuen Knoten mit der neuesten Betriebssystem- und Kubernetes-Version bereit.
Wichtig
Testen Sie neue Nebenversionen in einer Entwicklertestumgebung, und vergewissern Sie sich, dass Ihre Workload mit der neuen Kubernetes-Version weiterhin fehlerfrei funktioniert.
Es kann vorkommen, dass von Ihren Workloads genutzte APIs von Kubernetes eingestellt werden (wie in Version 1.16). Wenn Sie neue Versionen in der Produktion einsetzen, sollten Sie in Erwägung ziehen, mehrere Knotenpools für separate Versionen zu verwenden und einzelne Pools nacheinander zu aktualisieren, um das Rollout des Updates progressiv auf einem Cluster auszuführen. Wenn Sie mehrere Cluster ausführen, aktualisieren Sie jeweils einen Cluster, um Auswirkung oder Änderungen progressiv zu überwachen.
az aks upgrade --resource-group myResourceGroup --name myAKSCluster --kubernetes-version KUBERNETES_VERSION
Weitere Informationen zu Upgrades in AKS finden Sie unter Unterstützte Kubernetes-Versionen in Azure Kubernetes Service (AKS) und Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS).
Verarbeiten von Linux-Knotenupdates
Jeden Abend werden über die Updateverteilungskanäle Sicherheitspatches für Linux-Knoten in AKS zur Verfügung gestellt. Dieses Verhalten wird im Rahmen der Bereitstellung von Knoten in einem AKS-Cluster automatisch konfiguriert. Neustarts werden für Knoten nicht automatisch ausgeführt, wenn ein Sicherheitspatch oder Kernelupdate es erfordern würde, um Störungen und eventuelle negative Einflüsse auf ausgeführte Workloads zu minimieren. Weitere Informationen zum Umgang mit Knotenneustarts finden Sie im Artikel Anwenden von Sicherheits- und Kernelupdates auf Linux-Knoten in Azure Kubernetes Service (AKS).
Upgrades für Knotenimages
Unbeaufsichtigte Upgrades wenden Updates auf das Betriebssystem des Linux-Knotens an, aber das Image, das zum Erstellen von Knoten für Ihren Cluster verwendet wird, bleibt unverändert. Wenn Ihrem Cluster ein neuer Linux-Knoten hinzugefügt wird, wird das ursprüngliche Image zum Erstellen des Knotens verwendet. Dieser neue Knoten empfängt alle Sicherheits- und Kernelupdates, die während der automatischen Überprüfung jede Nacht verfügbar sind, bleibt jedoch ungepatcht, bis alle Überprüfungen und Neustarts abgeschlossen sind. Sie können das Knotenimageupgrade verwenden, um nach Knotenimages zu suchen und diese zu aktualisieren, die von Ihrem Cluster verwendet werden. Weitere Informationen zu Upgrades für Knotenimages finden Sie unter Upgrade für AKS-Knotenimages (Azure Kubernetes Service).
Verarbeiten von Windows Server-Knotenupdates
Führen Sie für Windows Server-Knoten regelmäßig ein Knotenimageupgrade durch, um die Pods sicher abzusperren und zu leeren und aktualisierte Knoten bereitzustellen.
Azure Kubernetes Service