Freigeben über

Best Practices für die Authentifizierung und Autorisierung in Azure Kubernetes Service (AKS)

  • Artikel

Beim Bereitstellen und Verwalten von Clustern in Azure Kubernetes Service (AKS) implementieren Sie Möglichkeiten zum Verwalten des Zugriffs auf Ressourcen und Dienste. Ohne diese Steuerungen kann Folgendes der Fall sein:

  • Konten können Zugriff auf unnötige Ressourcen und Dienste haben.
  • Das Nachverfolgen von Anmeldeinformationen zum Vornehmen von Änderungen kann schwierig sein.

In diesem Artikel wird erläutert, welche empfohlenen Methoden ein Clusteroperator befolgen kann, um den Zugriff und die Identität für AKS-Cluster zu verwalten. Sie lernen Folgendes:

  • Authentifizieren von Benutzer*innen von AKS-Clustern mit Microsoft Entra ID.
  • Steuern des Zugriffs auf Ressourcen mit der rollenbasierten Zugriffssteuerung für Kubernetes (Kubernetes Role-Based Access Control, Kubernetes RBAC)
  • Verwenden von Azure RBAC zur differenzierten Steuerung des Zugriffs auf die AKS-Ressource, die Kubernetes-API im großen Stil und kubeconfig
  • Verwenden Sie eine Workloadidentität, um von Ihren Pods aus auf Azure-Ressourcen zuzugreifen.

Warnung

Die vom Pod verwaltete Open-Source-Microsoft Entra-Identität (Vorschau) im Azure Kubernetes Service wurde zum 24.10.2022 als veraltet markiert.

Wenn Sie die podseitig verwaltete Microsoft Entra-Identität für Ihren AKS-Cluster aktiviert haben oder die Implementierung in Erwägung ziehen, empfehlen wir Ihnen, zunächst den Artikel Übersicht über die Workloadidentität zu lesen, um die Empfehlungen und Optionen zum Einrichten Ihres Clusters für die Verwendung einer Microsoft Entra-Workload-ID (Vorschau) zu verstehen. Diese Authentifizierungsmethode ersetzt verwaltete Podidentitäten (Vorschauversion), die in die nativen Kubernetes-Funktionen integriert werden, um einen Verbund mit externen Identitätsanbietern einzugehen.

Verwenden Sie Microsoft Entra ID

Best Practices-Leitfaden

Stellen Sie AKS-Cluster mit Microsoft Entra-Integration bereit. Durch die Verwendung von Microsoft Entra ID wird die Identitätsverwaltungsebene zentralisiert. Jede Änderung von Benutzerkonto oder Gruppenstatus wird automatisch im Zugriff auf den AKS-Cluster aktualisiert. Beschränken Sie Benutzer oder Gruppen mithilfe von Rollen, Clusterrollen oder Bindungen auf ein Minimum an Berechtigungen.

Die Entwickler und Anwendungsbesitzer des Kubernetes-Clusters benötigen Zugriff auf verschiedene Ressourcen. Kubernetes bietet keine Identitätsverwaltungslösung, mit der Sie die Ressourcen steuern, mit denen Benutzer interagieren können. Stattdessen können Sie Ihren Cluster in eine vorhandene Identitätslösung wie Microsoft Entra ID, eine unternehmensfähige Identitätsverwaltungslösung, integrieren.

Mit in Microsoft Entra integrierten Clustern in AKS erstellen Sie Rollen oder Clusterrollen, die Berechtigungen für den Zugriff auf Ressourcen definieren. Dann binden Sie die Rollen von Microsoft Entra ID aus an Benutzer*innen oder Gruppen. Weitere Informationen zu Kubernetes RBAC finden Sie im nächsten Abschnitt. Microsoft Entra-Integration und das Steuern des Zugriffs auf Ressourcen ist im folgenden Diagramm dargestellt:

Authentifizierung auf Clusterebene für die Microsoft Entra-Integration in AKS

  1. Der bzw. die Entwickler*in authentifiziert sich mit Microsoft Entra ID.
  2. Der Endpunkt für die Microsoft Entra-Tokenausstellung stellt das Zugriffstoken aus.
  3. Entwickler*innen führen eine Aktion mithilfe des Microsoft Entra-Tokens durch, wie etwa kubectl create pod.
  4. Kubernetes überprüft das Token in Microsoft Entra ID und ruft die Gruppenmitgliedschaften des Entwicklers bzw. der Entwicklerin ab.
  5. Kubernetes RBAC und Clusterrichtlinien werden angewendet.
  6. Ob die Anforderung von Entwickler*innen erfolgreich ist, hängt von der vorherigen Überprüfung der Microsoft Entra-Gruppenmitgliedschaft sowie von Kubernetes RBAC und entsprechenden Richtlinien ab.

Wie Sie einen AKS-Cluster erstellen, der Microsoft Entra ID verwendet, erfahren Sie unter Integrieren von Microsoft Entra ID in AKS.

Verwenden der rollenbasierten Zugriffssteuerung für Kubernetes (Kubernetes Role-Based Access Control, Kubernetes RBAC)

Best Practices-Leitfaden

Definieren Sie Benutzer- oder Gruppenberechtigungen für Clusterressourcen mit Kubernetes RBAC. Erstellen von Rollen und Bindungen, die die Mindestberechtigungen zuweisen. Führen Sie die Integration in Microsoft Entra ID durch, um automatisch alle Änderungen von Benutzerstatus oder Gruppenmitgliedschaft zu aktualisieren und den Zugriff auf Clusterressourcen auf dem aktuellen Stand zu halten.

In Kubernetes stellen Sie eine differenzierte Steuerung des Zugriffs auf Clusterressourcen bereit. Sie definieren Berechtigungen auf Clusterebene oder für bestimmte Namespaces. Sie bestimmen, welche Ressourcen mit welchen Berechtigungen verwaltet werden können. Diese Rollen wenden Sie dann auf Benutzer oder Gruppen mit einer Bindung an. Weitere Informationen zu Rollen, Clusterrollen und Bindungen finden Sie unter Zugriffs- und Identitätsoptionen für Azure Kubernetes Service (AKS).

Sie erstellen beispielsweise eine Rolle mit Vollzugriff auf Ressourcen im Namespace mit dem Namen finance-app, wie im folgenden YAML-Beispielmanifest gezeigt:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role
  namespace: finance-app
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

Anschließend erstellen Sie eine Rollenbindung (RoleBinding) und binden Microsoft Entra-Benutzer*innen developer1@contoso.com an die Rollenbindung, wie im folgenden YAML-Manifest gezeigt:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: finance-app-full-access-role-binding
  namespace: finance-app
subjects:
- kind: User
  name: developer1@contoso.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: finance-app-full-access-role
  apiGroup: rbac.authorization.k8s.io

Wenn developer1@contoso.com für den AKS-Cluster authentifiziert wird, verfügt er über vollständige Berechtigungen für Ressourcen im finance-app-Namespace. So trennen Sie logisch den Zugriff auf Ressourcen und steuern ihn. Verwenden Sie Kubernetes RBAC mit der Microsoft Entra ID-Integration.

Informationen zur Verwendung von Microsoft Entra-Gruppen zum Steuern des Zugriffs auf Kubernetes-Ressourcen mithilfe von Kubernetes RBAC finden Sie unter Steuern des Zugriffs auf Clusterressourcen per rollenbasierter Zugriffssteuerung von Kubernetes und mit Microsoft Entra-Identitäten in AKS.

Verwenden von Azure RBAC

Best Practices-Leitfaden

Verwenden Sie Azure RBAC, um die minimal erforderlichen Benutzer- und Gruppenberechtigungen für AKS-Ressourcen in einem oder mehreren Abonnements zu definieren.

Für den vollständigen Betrieb eines AKS-Clusters sind zwei Zugriffsebenen erforderlich:

  • Zugriff auf die AKS-Ressource in Ihrem Azure-Abonnement.

    Diese Zugriffsebene ermöglicht Ihnen Folgendes:

    • Steuern der Skalierung oder des Upgrades Ihres Clusters mithilfe der AKS-APIs
    • Pullen von kubeconfig

    Informationen zum Steuern des Zugriffs auf die AKS-Ressource und die kubeconfig finden Sie unter Beschränken des Zugriffs auf die Clusterkonfigurationsdatei.

  • Zugriff auf die Kubernetes-API.

    Diese Zugriffsebene wird auf eine der folgenden Arten gesteuert:

    • Kubernetes RBAC (herkömmlich) oder
    • Integration von Azure RBAC in AKS für die Kubernetes-Autorisierung

    Informationen zur differenzierten Erteilung von Berechtigungen für die Kubernetes-API mit Azure RBAC finden Sie unter Verwenden von Azure RBAC für die Kubernetes-Autorisierung.

Verwenden verwalteter Podidentitäten

Warnung

Die vom Pod verwaltete Open-Source-Microsoft Entra-Identität (Vorschau) im Azure Kubernetes Service wurde zum 24.10.2022 als veraltet markiert.

Wenn Sie die podseitig verwaltete Microsoft Entra-Identität für Ihren AKS-Cluster aktiviert haben oder die Implementierung in Erwägung ziehen, empfehlen wir Ihnen, zunächst den Artikel Übersicht über die Workloadidentität zu lesen, um die Empfehlungen und Optionen zum Einrichten Ihres Clusters für die Verwendung einer Microsoft Entra-Workload-ID (Vorschau) zu verstehen. Diese Authentifizierungsmethode ersetzt verwaltete Podidentitäten (Vorschauversion), die in die nativen Kubernetes-Funktionen integriert werden, um einen Verbund mit externen Identitätsanbietern einzugehen.

Verwenden Sie keine festen Anmeldeinformationen in Pods oder Containerimages, da sie offengelegt oder missbraucht werden können. Verwenden Sie stattdessen Podidentitäten, um den Zugriff mit Microsoft Entra ID automatisch anzufordern.

Für den Zugriff auf andere Azure-Ressourcen wie Azure Cosmos DB, Key Vault oder Blob Storage benötigt der Pod Anmeldeinformationen für die Authentifizierung. Sie können Anmeldeinformationen für die Authentifizierung mit dem Containerimage definieren oder als Kubernetes-Geheimnis einfügen. In beiden Fällen müssen Sie diese manuell erstellen und zuweisen. In der Regel werden diese Anmeldeinformationen podübergreifend wiederverwendet und nicht regelmäßig rotiert.

Mit podseitig verwalteten Identitäten (Vorschau) für Azure-Ressourcen fordern Sie automatisch den Zugriff auf Dienste über Microsoft Entra ID an. Verwaltete Podidentitäten befinden sich derzeit in der Vorschauphase für AKS. Informationen zu den ersten Schritten finden Sie in der Dokumentation zu Verwenden von podseitig verwalteten Microsoft Entra-Identitäten in Azure Kubernetes Service (Vorschau).

Die podseitig verwaltete Microsoft Entra-Identität (Vorschau) unterstützt zwei Betriebsmodi:

  • Standardmodus: In diesem Modus werden die folgenden zwei Komponenten im AKS-Cluster bereitgestellt:

    • Managed Identity Controller (MIC): Ein Kubernetes-Controller, der über den Kubernetes-API-Server auf Änderungen an Pods, AzureIdentity und AzureIdentityBinding überwacht. Wenn eine relevante Änderung erkannt wird, fügt der MIC nach Bedarf AzureAssignedIdentity hinzu oder löscht sie. Insbesondere bei der Planung eines Pods weist der MIC die verwaltete Identität in Azure der zugrunde liegenden VM-Skalierungsgruppe zu, die während der Erstellungsphase vom Knotenpool verwendet wird. Wenn alle Pods, die die Identität verwenden, gelöscht werden, wird die Identität aus der VM-Skalierungsgruppe des Knotenpools entfernt, es sei denn, die gleiche verwaltete Identität wird von anderen Pods verwendet. Der MIC führt ähnliche Aktionen aus, wenn AzureIdentity oder AzureIdentityBinding erstellt oder gelöscht werden.

    • Node Management Identity (NMI): Dies ist ein Pod, der auf jedem Knoten im AKS-Cluster als DaemonSet ausgeführt wird. NMI fängt Sicherheitstokenanforderungen an den Azure Instance Metadata Service auf jedem Knoten ab. NMI leitet die Anforderungen an sich selbst weiter und überprüft, ob der Pod Zugriff auf die Identität hat, für die er ein Token anfordert. Anschließend wird das Token im Auftrag der Anwendung vom Microsoft Entra-Mandanten abgerufen.

  • Verwalteter Modus: In diesem Modus gibt es nur die NMI. Die Identität muss vom Benutzer manuell zugewiesen und verwaltet werden. Weitere Informationen finden Sie unter Podidentität im verwalteten Modus. Wenn Sie in diesem Modus den Befehl az aks pod-identity add verwenden, um einem Azure Kubernetes Service-Cluster (AKS-Cluster) eine Podidentität hinzuzufügen, werden AzureIdentity und AzureIdentityBinding in dem durch den Parameter --namespace angegebenen Namespace erstellt, während der AKS-Ressourcenanbieter der VM-Skalierungsgruppe jedes Knotenpools im AKS-Cluster die durch den Parameter --identity-resource-id angegebene verwaltete Identität zuweist.

Hinweis

Wenn Sie sich stattdessen entscheiden, die podseitig verwaltete Microsoft Entra-Identität mithilfe des AKS-Cluster-Add-Ons zu installieren, verwendet das Setup den verwalteten Modus (managed).

Der managed Modus bietet folgende Vorteile gegenüber dem standard Modus:

  • Die Identitätszuweisung für die VM-Skalierungsgruppe eines Knotenpools kann 40 bis 60 Sekunden dauern. Bei Cron-Aufträgen (CronJobs) oder Anwendungen, die Zugriff auf die Identität benötigen und die Zuweisungsverzögerung nicht tolerieren können, empfiehlt es sich, den verwalteten Modus (managed) zu verwenden, da die Identität der VM-Skalierungsgruppe des Knotenpools vorab zugewiesen wird. Dies kann entweder manuell oder mit dem Befehl az aks pod-identity add erfolgen.
  • Im standard Modus erfordert der MIC Schreibberechtigungen für die vom AKS-Cluster verwendete VM-Skalierungsgruppe und die Berechtigung Managed Identity Operator für die vom Benutzer zugewiesenen verwalteten Identitäten. Bei der Ausführung im managed mode sind die Rollenzuweisungen nicht erforderlich, da es keinen MIC gibt.

Anstatt Anmeldeinformationen für Pods manuell zu definieren, fordern verwaltete Podidentitäten ein Zugriffstoken in Echtzeit an, das sie nur für den Zugriff auf die ihnen zugewiesenen Ressourcen verwenden. In AKS gibt es zwei Komponenten, die die Vorgänge bearbeiten, damit Pods verwaltete Identitäten verwenden können:

  • Der Node Management Identity-Server (NMI) ist ein Pod, der auf jedem Knoten im AKS-Cluster als DaemonSet ausgeführt wird. Der NMI-Server überwacht Podanforderungen an Azure-Dienste.
  • Der Azure-Ressourcenanbieter fragt den Kubernetes-API-Server ab und sucht nach einer Azure-Identitätszuordnung, die einem Pod entspricht.

Wenn Pods ein Sicherheitstoken von Microsoft Entra ID für den Zugriff auf eine Azure-Ressource anfordern, wird der Datenverkehr anhand von Netzwerkregeln an den NMI-Server umgeleitet.

  1. Der NMI-Server erfüllt folgende Aufgaben:

    • Er identifiziert Pods, die Zugriff auf Azure-Ressourcen anfordern, anhand ihrer Remoteadresse.
    • Abfragen des Azure-Ressourcenanbieters

  2. Der Azure-Ressourcenanbieter sucht im AKS-Cluster nach Azure-Identitätszuordnungen.

  3. Der NMI-Server fordert basierend auf der Identitätszuordnung des Pods ein Zugriffstoken von Microsoft Entra ID an.

  4. Microsoft Entra ID bietet Zugriff auf den NMI-Server, der an den Pod zurückgegeben wird.

    • Dieses Zugriffstoken kann dann vom Pod verwendet werden, um Zugriff auf Ressourcen in Azure anzufordern.

Im folgenden Beispiel erstellt ein Entwickler einen Pod, der eine verwaltete Identität verwendet, um Zugriff auf Azure SQL-Datenbank anzufordern:

Mit Podidentitäten kann ein Pod automatisch Zugriff auf andere Ressourcen anfordern.

  1. Der Clusteroperator erstellt ein Dienstkonto, um Identitäten zuzuordnen, wenn Pods Zugriff auf Ressourcen anfordern.
  2. Der NMI-Server wird bereitgestellt, um alle Podanforderungen zusammen mit dem Azure-Ressourcenanbieter für Zugriffstoken an Microsoft Entra ID weiterzuleiten.
  3. Ein Entwickler stellt einen Pod mit einer verwalteten Identität bereit, die ein Zugriffstoken über den NMI-Server anfordert.
  4. Das Token wird an den Pod zurückgegeben und für den Zugriff auf Azure SQL-Datenbank verwendet.

Informationen zur Verwendung von podseitig verwalteten Identitäten finden Sie unter Verwenden von podseitig verwalteten Microsoft Entra-Identitäten in Azure Kubernetes Service (Vorschau).

Nächste Schritte

Dieser Best Practices-Artikel konzentriert sich auf Authentifizierung und Autorisierung für Ihre Cluster und Ressourcen. Um einige dieser Best Practices zu implementieren, lesen Sie folgende Artikel:

Weitere Informationen zu Clustervorgängen in AKS finden Sie in den folgenden Best Practices: