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

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 Benutzern von AKS-Clustern mit Azure Active Directory (Azure AD)
  • 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 einer verwalteten Identität zur Authentifizierung von Pods bei anderen Diensten

Verwenden von Azure Active Directory (Azure AD)

Best Practices-Leitfaden

Stellen Sie AKS-Cluster mit Azure AD-Integration bereit. Durch die Verwendung von Azure AD 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 Azure AD, eine unternehmensfähige Identitätsverwaltungslösung, integrieren.

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

Authentifizierung auf Clusterebene für die Azure Active Directory-Integration in AKS

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

Wie Sie einen AKS-Cluster erstellen, der Azure AD verwendet, erfahren Sie unter Integrieren von Azure Active Directory in Azure Kubernetes Service.

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 Azure AD 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 den Azure AD-Benutzer 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 Azure AD-Integration.

Informationen zur Verwendung von Azure AD-Gruppen zum Steuern des Zugriffs auf Kubernetes-Ressourcen mit Kubernetes RBAC finden Sie unter Steuern des Zugriffs auf Clusterressourcen per rollenbasierter Zugriffssteuerung von Kubernetes und mit Azure Active Directory-Identitäten in Azure Kubernetes Service.

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

Best Practices-Leitfaden

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 Azure AD automatisch anzufordern.

Hinweis

Podidentitäten sind nur für die Verwendung mit Linux-Pods und -Containerimages vorgesehen. Die Unterstützung von verwalteten Podidentitäten für Windows-Container ist in Kürze verfügbar.

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 verwalteten Podidentitäten (Vorschauversion) für Azure-Ressourcen fordern Sie automatisch den Zugriff auf Dienste über Azure AD an. Verwaltete Podidentitäten befinden sich derzeit in der Vorschauphase für AKS. Informationen zu den ersten Schritten finden Sie in der Dokumentation unter Verwenden von verwalteten Azure Active Directory-Podidentitäten in Azure Kubernetes Service (Vorschauversion).

Hinweis

Wenn Sie die verwaltete Azure AD-Podidentität für Ihren AKS-Cluster aktiviert haben oder die Implementierung in Erwägung ziehen, empfehlen wir Ihnen, zunächst den Artikel Überblick über die Workloadidentität zu lesen, um unsere Empfehlungen und Optionen zum Einrichten Ihres Clusters für die Verwendung einer Azure AD-Workloadidentität (Vorschauversion) 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.

Die verwaltete Azure AD Open Source-Podidentität (Vorschau) im Azure Kubernetes Service wurde zum 24.10.2022 eingestellt.

Verwaltete Azure Active Directory-Podidentitäten (Vorschauversion) unterstützen 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 Azure Active Directory-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 verwaltete Azure Active Directory-Podidentität mithilfe des AKS-Cluster-Add-Ons zu installieren, wird der verwaltete Modus (managed) verwendet.

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 Azure Active Directory 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 Azure AD an.

  4. Azure AD 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 Azure AD 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 verwalteten Podidentitäten finden Sie unter Verwenden von verwalteten Azure Active Directory-Podidentitäten in Azure Kubernetes Service (Vorschauversion).

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: