Clusterauthentifizierungskonzepte in Azure Kubernetes Service (AKS)

In diesem Artikel wird beschrieben, wie Azure Kubernetes Service (AKS) Aufrufer für die Kubernetes-API authentifiziert, d. h. wer eine Verbindung mit der Steuerebene herstellen kann. Es behandelt den empfohlenen Microsoft Entra ID-basierten Authentifizierungspfad und das Sperren des Break-Glass-Zugriffs.

Informationen dazu, wie AKS bewertet, was ein authentifizierter Aufrufer tun darf, finden Sie unter Clusterautorisierungskonzepte.

Die anderen Identitätsszenarien in AKS finden Sie unter:

Eine Übersicht über alle vier AKS-Identitätsszenarien finden Sie unter Zugriffs- und Identitätsoptionen für AKS.

Authentifizieren beim Kubernetes-API-Server (Steuerungsebene)

Kubernetes selbst stellt kein Identitätsverzeichnis bereit. Ohne einen externen Identitätsanbieter müssen Sie lokale Anmeldeinformationen pro Cluster verwalten, die nicht skaliert werden und Überwachungslücken entstehen.

Wir empfehlen die Bereitstellung von AKS-Clustern mit der Microsoft Entra ID-Authentifizierung für die Steuerungsebene. Mit dieser Integration überprüft der Cluster eingehende Kubernetes-API-Anforderungen anhand der Microsoft Entra-ID und verwendet die Entra-Identität des Aufrufers für Autorisierungsentscheidungen. Microsoft Entra ID zentralisiert die Identitätsebene – jede Änderung des Benutzer- oder Gruppenstatus wird automatisch im Clusterzugriff widerzuspiegeln – und ermöglicht bedingten Zugriff, mehrstufige Authentifizierung und Privileged Identity Management.

Diagramm, das die Microsoft Entra-Integration mit AKS-Clustern für die Authentifizierung zeigt.

Informationen zum Einrichten finden Sie unter Aktivieren der Microsoft Entra ID-Authentifizierung für die AKS-Steuerungsebene. Beachten Sie Folgendes:

  • Der für die Clusterauthentifizierung konfigurierte Microsoft Entra-Mandant muss dem Mandanten des Abonnements entsprechen, der den AKS-Cluster enthält.
  • Verwenden Sie für nicht interaktive Anmeldungen oder ältere kubectl Versionen das kubelogin Plug-In.

Externe Identitätsanbieter (Vorschau)

Einige Organisationen müssen Clusterbenutzer mit einem anderen OIDC-kompatiblen Identitätsanbieter als microsoft Entra ID authentifizieren, z. B. GitHub, Google Workspace, Okta oder ein selbst gehostetes IdP. AKS unterstützt dies durch strukturierte Authentifizierung, die die JWT-Authentifikatoren des Kubernetes-API-Servers konfiguriert, um von Ihrem externen Anbieter ausgestellte Token zu überprüfen.

Verwenden Sie diese Option nur, wenn Sie eine harte Anforderung haben, die Clusteridentität außerhalb der Microsoft Entra-ID beizubehalten. Bevorzugen Sie andernfalls den Microsoft Entra-ID-Pfad für eine umfassendere Integration mit bedingtem Zugriff, mehrstufiger Authentifizierung und Privileged Identity Management.

Eine Übersicht finden Sie unter AKS-Clusterauthentifizierung für externe Identitätsanbieter. Informationen zum Einrichten finden Sie unter Konfigurieren externer Identitätsanbieter mit strukturierter AKS-Authentifizierung.

Deaktivieren lokaler Konten

Lokale Konten verwenden ein integriertes Clusteradministratorzertifikat, das die Microsoft Entra-ID umgeht. Jeder Anrufer, der diese Anmeldeinformationen auflisten kann, erhält vollständigen Clusteradministratorzugriff, ohne die Entra-ID durchzugehen, wodurch die zentralisierte Überwachung, der bedingte Zugriff und die Privileged Identity Management unterbrochen werden. Deaktivieren Sie in der Produktion lokale Konten, damit alle Zugriffe über die Microsoft Entra-ID fließen.

Um dies über viele Cluster hinweg durchzusetzen, weisen Sie die integrierte Azure-Richtlinie Azure Kubernetes-Dienstcluster sollten lokale Authentifizierungsmethoden deaktiviert haben einem Abonnement- oder Verwaltungsgruppenbereich zu. Die Richtlinie überprüft oder verweigert Cluster, die mit aktivierten lokalen Konten erstellt oder aktualisiert werden. Die vollständige Liste der integrierten AKS-Richtlinien finden Sie in den integrierten Azure-Richtliniendefinitionen für AKS.

Ausführliche Informationen finden Sie unter Verwalten lokaler Konten in AKS.

Authentifizieren bei Clusterknoten

SSH-Zugriffsmodi

Über die Authentifizierung bei der Kubernetes-API hinaus müssen Sie sich möglicherweise auch direkt bei einem Knoten über SSH authentifizieren, um Probleme zu beheben. AKS unterstützt drei SSH-Zugriffsmodi, die Sie pro Cluster- oder Knotenpool festlegen:

  • Deaktiviertes SSH (Vorschau):Blockieren sie den SSH-Zugriff auf Knoten vollständig. Empfohlen für die Produktion, bei der der Zugriff auf Knotenebene nur über kubectl debug oder andere Kubernetes-native Pfade gesteuert wird.
  • Microsoft Entra ID-basiertes SSH (Vorschau):Melden Sie sich mit Microsoft Entra-Identitäten bei Knoten an, ohne SSH-Schlüssel zu verwalten. Dieser Modus ist mit der restlichen Clusterauthentifizierung konsistent: Er erbt bedingten Zugriff und mehrstufige Authentifizierung von Entra-ID, unterstützt just-in-time-Rechteerweiterung über Azure RBAC und Privileged Identity Management und zentralisiert die Überwachung über Entra ID-Anmeldeprotokolle.
  • Lokaler Benutzer-SSH: Herkömmlicher SSH-schlüsselbasierter Zugriff. Verwenden Sie diese Option nur, wenn entra ID-basiertes SSH keine Option ist und Schlüssel regelmäßig gedreht werden.

Informationen zu Setup- und Konfigurationsschritten pro Modus finden Sie unter Verwalten des SSH-Zugriffs auf AKS-Clusterknoten.

Nächste Schritte

  • Last updated on