Best Practices für Clustersicherheit und Upgrades in Azure Kubernetes Service (AKS)

Gilt für: ✔️ AKS Automatic ✔️ AKS Standard

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.
  • Zugriff von Containern auf Knotenressourcen absichern.
  • Upgraden eines AKS-Clusters auf die neueste Kubernetes-Version
  • Knoten auf dem neuesten Stand halten und Sicherheitspatches automatisch anwenden

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

Sicherheitsverantwortung für den AKS-Clustermodus

AKS unterstützt zwei Clustermodi: AKS Automatic and AKS Standard. Sicherheitsziele sind in beiden Modi identisch, aber die Implementierungsverantwortung unterscheidet sich.

AKS Automatic enthält einen gehärteten Basisplan mit mehr vorkonfigurierten Steuerelementen in unterstützten Konfigurationen. AKS Standard bietet eine umfassendere direkte Konfigurationskontrolle, wodurch die Betreiberverantwortung für die geplante Einrichtung und den laufenden Betrieb erhöht wird.

Area AKS Automatik AKS Standard
Clusterauthentifizierung und Autorisierungsbasislinie Weitere vorkonfigurierte Standardwerte in unterstützten Konfigurationen Häufig von Operatoren explizit konfiguriert
Härtung des API-Servernetzwerks Mehr vorkonfiguriertes Basisverhalten in unterstützten Konfigurationen Explizite Härtungsoptionen von Betreibern
Richtlinien- und Basissicherheitskontrollen Weitere vorkonfigurierte Standardwerte in unterstützten Konfigurationen Explizite Richtlinienaktivierung und Auswahl des Modus
Steuerelemente für die Bildhygiene Basissteuerelemente, die in unterstützten Konfigurationen verfügbar sind Explizite Aktivierung und Verantwortung für den Lebenszyklus
Systemknotenpoolvorgänge Weitere vom Dienst verwaltete Verhaltensweisen Weiteres vom Betreiber verwaltetes Verhalten
Eigentum upgraden Mehr Standardoptionen für verwaltete Upgrades Vom Betreiber ausgewählte Strategie und Rollout-Governance

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.

Dieser Leitfaden gilt für beide Modi. Auch wenn AKS Automatic vorkonfigurierte Sicherheitsstandardeinstellungen bereitstellt, bleiben das Onboarding für den Bedrohungsschutz und die Workflows zur Reaktion auf Warnungen weiterhin in der Verantwortung Ihres Teams.

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.

Microsoft Entra-Integration für AKS-Cluster

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.

In AKS Automatic sind Autorisierung und Sicherheitsbaselines in unterstützten Konfigurationen stärker vorkonfiguriert, sodass sich Betreiber auf Validierung, Governance und Ausnahmebehandlung konzentrieren. In AKS Standard konfigurieren Operatoren diese Steuerelemente häufig direkt und verwalten ihren Lebenszyklusstatus.

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 Benutzer-Namespaces eine Netzwerkrichtlinie hinzu, um den ausgehenden Datenverkehr von Pods zum 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

Stellen Sie in AKS Standard sicher, dass Ihr ausgewähltes Netzwerkmodell und das Richtlinienmodul diesen Richtlinienpfad unterstützen. Wenden Sie in AKS Automatic gleichwertige Egress-Einschränkungen auf Namespaceebene an, sofern diese in Ihrer Clusterkonfiguration unterstützt werden.

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.

Mithilfe von Benutzer-Namespaces verbessern Sie die Host-Isolation und begrenzen die seitliche Bewegung im Falle von Ausbrüchen aus Containern. Diese Verbesserungen sind von Bedeutung, unabhängig davon, ob der Pod als Root ausgeführt wird oder nicht.

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.

Auch wenn AKS Automatic gehärtete Standardwerte bereitstellt, bleiben Sicherheitskontrollen auf Arbeitsauslastungsebene Anwendungs- und Plattformteamverantwortlichkeiten.

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 Release-Zyklus neuer Kubernetes-Funktionen ermöglicht es Ihnen, Kubernetes zu aktualisieren, ohne regelmäßig auf inkompatible Änderungen zu stoßen 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. Um weiterhin im Support zu bleiben, stellen Sie sicher, dass Sie über einen Governance-Prozess verfügen, mit dem notwendige Upgrades geprüft werden können. Weitere Informationen finden Sie unter Unterstützte Kubernetes-Versionen in Azure Kubernetes Service (AKS).

In AKS Automatic ist das Verhalten bei Upgrades in unterstützten Konfigurationen stärker vorkonfiguriert, und die Operatoren sollten sich auf die Überprüfung der Bereitschaft der Workloads und die Release-Governance konzentrieren. In AKS Standard wählen und steuern Operatoren die Upgradestrategie und das Rollout-Timing direkter.

Verwenden Sie den az aks get-upgrades Befehl, wie im folgenden Beispiel gezeigt, um die für Den Cluster verfügbaren Versionen zu überprüfen:

az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table

Anschließend können Sie ihren AKS-Cluster mit dem az aks upgrade Befehl aktualisieren. 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.

Kubernetes könnte APIs als veraltet kennzeichnen (beispielsweise in Version 1.16), auf die Ihre Workloads angewiesen sind. 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.

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

Linux-Knotenupdates verarbeiten

Jeden Abend erhalten Linux-Knoten in AKS Sicherheitspatches über den Updatekanal ihrer Distribution. 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).

In AKS Automatic ist das Updateverhalten der Knoten in unterstützten Konfigurationen stärker vorkonfiguriert. In AKS Standard definieren Operatoren häufig Patch- und Neustartgovernance mit expliziten betriebstechnischen Kontrollen.

Aktualisierungen von Node-Images

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 Knotenimage-Upgrades verwenden, um die von Ihrem Cluster verwendeten Knotenimages zu prüfen und zu aktualisieren. Weitere Informationen zu Upgrades für Knotenimages finden Sie unter Upgrade für AKS-Knotenimages (Azure Kubernetes Service).

Windows Server-Knotenupdates verarbeiten

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.

Verwandte Inhalte

Weitere Informationen zu AKS und zum Sichern Ihres AKS-Clusters finden Sie in den folgenden Artikeln:

  • Last updated on