Freigeben über

Steuern des Zugriffs mithilfe von Microsoft Entra ID und Kubernetes RBAC

  • Artikel

Gilt für: AKS auf Azure Local, Version 23H2

Sie können Azure Kubernetes Service (AKS) für die Verwendung der Microsoft Entra-ID für die Benutzerauthentifizierung konfigurieren. In dieser Konfiguration melden Sie sich mit einem Microsoft Entra-Authentifizierungstoken bei einem Kubernetes-Cluster an. Nach der Authentifizierung können Sie die integrierte rollenbasierte Zugriffssteuerung von Kubernetes (Kubernetes RBAC) verwenden, um den Zugriff auf Namespaces und Clusterressourcen auf Grundlage der Identität oder Gruppenmitgliedschaft eines Benutzers zu verwalten.

In diesem Artikel wird beschrieben, wie Sie den Zugriff mithilfe von Kubernetes RBAC in einem Kubernetes-Cluster basierend auf der Microsoft Entra-Gruppenmitgliedschaft in AKS steuern. Sie erstellen eine Demogruppe und Benutzer in der Microsoft Entra-ID. Anschließend erstellen Sie Rollen und Rollenbindungen im Cluster, um die entsprechenden Berechtigungen zum Erstellen und Anzeigen von Ressourcen zu erteilen.

Voraussetzungen

Bevor Sie Kubernetes RBAC mit Microsoft Entra ID einrichten, müssen Sie über die folgenden Voraussetzungen verfügen:

  • Eine von Azure Arc-Cluster aktivierte AKS. Wenn Sie Ihren Cluster einrichten müssen, lesen Sie die Anweisungen zur Verwendung des Azure-Portal oder der Azure CLI.
  • Azure CLI installiert und konfiguriert. Wenn Sie CLI oder Upgrade installieren müssen, lesen Sie " Installieren von Azure CLI".
  • Azure CLI und die connectedk8s-Erweiterung. Die Azure-Befehlszeilenschnittstelle (Command-Line Interface, CLI) setzt sich aus Befehlen zum Erstellen und Verwalten von Azure-Ressourcen zusammen. Um zu überprüfen, ob Sie über die Azure CLI verfügen, öffnen Sie ein Befehlszeilentool, und geben Sie Folgendes ein: az -v Installieren Sie außerdem die Connectedk8s-Erweiterung , um einen Kanal zu Ihrem Kubernetes-Cluster zu öffnen. Die erforderlichen Installationsanleitungen finden Sie unter Installieren der Azure CLI.
  • Kubectl. Mit dem Befehlszeilentool Kubernetes, Kubectl, können Sie Befehle ausführen, die auf Ihre Kubernetes-Cluster abzielen. Um zu überprüfen, ob Sie kubectl installiert haben, öffnen Sie ein Befehlszeilentool, und geben Sie Folgendes ein: kubectl version --client Stellen Sie sicher, dass Ihre kubectl-Clientversion mindestens v1.24.0 ist. Installationsanweisungen finden Sie unter kubectl.
  • Sie können auf Ihren Kubernetes-Cluster mit den angegebenen Berechtigungen entweder über den direkten Modus oder den Proxymodus zugreifen.
    • Um direkt über den Befehl auf den az aksarc get-credentials Kubernetes-Cluster zuzugreifen, benötigen Sie die Rollenberechtigungen "Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action", die in den Azure Kubernetes Service Arc Cluster-Rollenberechtigungen enthalten sind.
    • Für den Zugriff auf den Kubernetes-Cluster von praktisch überall mit einem Proxymodus mithilfe des az connectedk8s proxy Befehls benötigen Sie die Rollenberechtigung "Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action", die in Azure Arc-fähigen Kubernetes Cluster-Benutzerrollenberechtigung enthalten ist. In der Zwischenzeit müssen Sie überprüfen, ob die Agents und der Computer, die den Onboarding-Prozess ausführen, die Netzwerkanforderungen in Azure Arc-fähigen Kubernetes-Netzwerkanforderungen erfüllen.

Optionale erste Schritte

Wenn Sie noch keine Microsoft Entra-Gruppe haben, die Mitglieder enthält, können Sie eine Gruppe erstellen und einige Mitglieder hinzufügen, damit Sie den Anweisungen in diesem Artikel folgen können.

Um die Arbeit mit Microsoft Entra ID und Kubernetes RBAC zu demonstrieren, können Sie eine Microsoft Entra-Gruppe für Anwendungsentwickler erstellen, die verwendet werden können, um zu zeigen, wie Kubernetes RBAC und Microsoft Entra ID den Zugriff auf Clusterressourcen steuern. In Produktionsumgebungen können Sie vorhandene Benutzer*innen und Gruppen in einem Microsoft Entra-Mandanten nutzen.

Erstellen einer Demogruppe in der Microsoft Entra-ID

Erstellen Sie zunächst die Gruppe in Der Microsoft Entra-ID in Ihrem Mandanten für die Anwendungsentwickler, die den az ad group create Befehl verwenden. Im folgenden Beispiel werden Sie aufgefordert, sich bei Ihrem Azure-Mandanten anzumelden und dann eine Gruppe mit dem Namen "appdev" zu erstellen:

az login
az ad group create --display-name appdev --mail-nickname appdev

Hinzufügen von Benutzern zu Ihrer Gruppe

Wenn die Beispielgruppe in der Microsoft Entra-ID für Anwendungsentwickler erstellt wurde, fügen Sie der appdev Gruppe einen Benutzer hinzu. Sie verwenden dieses Benutzerkonto, um sich beim AKS-Cluster anzumelden und die Kubernetes RBAC-Integration zu testen.

Fügen Sie mithilfe des az ad group member add Befehls einen Benutzer zur appdev-Gruppe hinzu, die im vorherigen Abschnitt erstellt wurde. Wenn Sie Ihre Sitzung beenden, stellen Sie erneut eine Verbindung mit Azure her.az login

$AKSDEV_ID = az ad user create --display-name <name> --password <strongpassword> --user-principal-name <name>@contoso.onmicrosoft.com
az ad group member add --group appdev --member-id $AKSDEV_ID

Erstellen einer benutzerdefinierten Kubernetes RBAC-Rollenbindung für die AKS-Clusterressource für die Microsoft Entra-Gruppe

Konfigurieren Sie den AKS-Cluster, damit Ihre Microsoft Entra-Gruppe auf den Cluster zugreifen kann. Wenn Sie eine Gruppe und Benutzer hinzufügen möchten, lesen Sie "Erstellen von Demogruppen" in der Microsoft Entra-ID.

  1. Verwenden Sie den az aksarc get-credentials Befehl, um die Clusteradministratoranmeldeinformationen abzurufen:

    az aksarc get-credentials --name "$aks_cluster_name" --resource-group "$resource_group_name" --admin

  2. Erstellen Sie einen Namespace im Kubernetes-Cluster mithilfe des kubectl create namespace Befehls. Im folgenden Beispiel wird ein Namespace mit dem Namen dev erstellt:

    kubectl create namespace dev

In Kubernetes werden mit Rollen die zu gewährenden Berechtigungen definiert, und mit RoleBindings (Rollenbindungen) werden sie auf die gewünschten Benutzer bzw. Gruppen angewendet. Diese Zuordnungen können auf einen bestimmten Namespace oder über einen gesamten Cluster angewendet werden. Weitere Informationen finden Sie unter Verwenden der Kubernetes RBAC-Autorisierung.

Erstellen Sie eine Rolle für den Dev-Namespace . Mit dieser Rolle wird Vollzugriff auf den Namespace gewährt. In Produktionsumgebungen möchten Sie möglicherweise differenziertere Berechtigungen für unterschiedliche Benutzer oder Gruppen angeben.

  1. Erstellen Sie eine Datei namens role-dev-namespace.yaml , und kopieren/einfügen Sie das folgende YAML-Manifest:

    kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-full-access
  namespace: dev
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["*"]
  verbs: ["*"]
- apiGroups: ["batch"]
  resources:
  - jobs
  - cronjobs
  verbs: ["*"]

  2. Erstellen Sie die Rolle mithilfe des kubectl apply Befehls, und geben Sie den Dateinamen Ihres YAML-Manifests an:

    kubectl apply -f role-dev-namespace.yaml

  3. Rufen Sie die Ressourcen-ID für die Gruppe appdev ab, indem Sie den Befehl az ad group show verwenden. Diese Gruppe wird im nächsten Schritt als Betreff einer RoleBinding festgelegt:

    az ad group show --group appdev --query objectId -o tsv

    Der az ad group show Befehl gibt den Wert zurück, den Sie als groupObjectId:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  4. Erstellen Sie eine Datei namens rolebinding-dev-namespace.yaml, und kopieren/einfügen Sie das folgende YAML-Manifest. Sie richten die Rollenbindung ein, mit der die Appdev-Gruppe die Rolle für den role-dev-namespace Namespacezugriff verwenden kann. Ersetzen Sie in der letzten Zeile groupObjectId durch die Gruppenobjekt-ID, die vom Befehl az ad group show ausgegeben wurde:

    kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: dev-user-access
  namespace: dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: dev-user-full-access
subjects:
- kind: Group
  namespace: dev
  name: groupObjectId

    Tipp

    Wenn Sie das RoleBinding für einen einzelnen Benutzer erstellen möchten, geben Sie den Benutzerprinzipalnamen (USER Principal Name, UPN) im Beispiel an kind: User und ersetzen groupObjectId sie.

  5. Erstellen Sie die RoleBinding mithilfe des kubectl apply Befehls, und geben Sie den Dateinamen Ihres YAML-Manifests an:

    kubectl apply -f rolebinding-dev-namespace.yaml

    rolebinding.rbac.authorization.k8s.io/dev-user-access created

Verwenden von integrierten Kubernetes RBAC-Rollen für Ihre AKS-Clusterressource

Kubernetes bietet auch integrierte benutzerbezogene Rollen. Diese integrierten Rollen umfassen:

  • Superbenutzerrollen (cluster-admin)
  • Rollen, denen die clusterweite Verwendung von ClusterRoleBindings gewährt werden soll
  • Rollen, die in bestimmten Namespaces mit RoleBindings (Administrator, Bearbeitung, Ansicht) gewährt werden sollen

Weitere Informationen zu integrierten Kubernetes-RBAC-Rollen finden Sie unter Kubernetes RBAC-Benutzerrollen.

Benutzerbezogene Rollen

Standard-ClusterRole Standard-ClusterRoleBinding Beschreibung
cluster-admin Gruppe „system:masters“ Ermöglicht den Superbenutzerzugriff, um jede Aktion für jede Ressource auszuführen. Bei Verwendung in einem ClusterRoleBinding bietet diese Rolle die vollständige Kontrolle über jede Ressource im Cluster und in allen Namespaces. Bei Verwendung in RoleBinding wird über diese Rolle Vollzugriff auf jede Ressource im Namespace der Rollenbindung gewährt, einschließlich des Namespace selbst.
admin Keine Ermöglicht den Administratorzugriff, der in einem Namespace mithilfe einer Rollenbindung gewährt werden soll. Wenn sie in einer Rollenbindung verwendet wird, ermöglicht lese-/schreibzugriff auf die meisten Ressourcen in einem Namespace, einschließlich der Funktion zum Erstellen von Rollen und Rollenbindungen innerhalb des Namespaces. Diese Rolle lässt keinen Schreibzugriff auf das Ressourcenkontingent oder den Namespace selbst zu. Diese Rolle lässt auch keinen Schreibzugriff auf Endpunkte in Clustern zu, die mit Kubernetes v1.22+ erstellt wurden. Weitere Informationen finden Sie unter Write Access für Endpunkte.
edit Keine Ermöglicht Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace. Diese Rolle lässt das Anzeigen oder Ändern von Rollen oder Rollenbindungen nicht zu. Diese Rolle ermöglicht jedoch den Zugriff auf geheime Schlüssel und das Ausführen von Pods als beliebiges ServiceAccount im Namespace, sodass sie verwendet werden kann, um die API-Zugriffsebenen eines beliebigen ServiceAccounts im Namespace zu erhalten. Diese Rolle lässt auch keinen Schreibzugriff auf Endpunkte in Clustern zu, die mit Kubernetes v1.22+ erstellt wurden. Weitere Informationen finden Sie unter Write Access für Endpunkte.
view Keine Ermöglicht schreibgeschützten Zugriff, um die meisten Objekte in einem Namespace anzuzeigen. Es ist nicht möglich, Rollen oder Rollenbindungen anzuzeigen. Diese Rolle lässt das Anzeigen von geheimen Schlüsseln nicht zu, da das Lesen des Inhalts von geheimen Schlüsseln den Zugriff auf ServiceAccount-Anmeldeinformationen im Namespace ermöglicht, was den API-Zugriff als ein beliebiges ServiceAccount im Namespace (eine Form der Berechtigungseskalation) zulässt.

Verwenden einer integrierten Kubernetes-RBAC-Rolle mit Microsoft Entra ID

Führen Sie die folgenden Schritte aus, um eine integrierte Kubernetes-RBAC-Rolle mit Microsoft Entra ID zu verwenden:

  1. Wenden Sie die integrierte Kubernetes-RBAC-Rolle auf Ihre Microsoft Entra-Gruppe view an:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --group=<Azure AD group object ID>

  2. Wenden Sie die integrierte Kubernetes-RBAC-Rolle auf jeden Ihrer Microsoft Entra-Benutzer view an:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

Zugreifen auf den Kubernetes-Cluster

Sie können jetzt mit den angegebenen Berechtigungen auf Ihren Kubernetes-Cluster zugreifen, indem Sie entweder den direkten Modus oder den Proxymodus verwenden.

Zugreifen auf Ihren Cluster mit Kubectl (direkter Modus)

Um mit den angegebenen Berechtigungen auf den Kubernetes-Cluster zuzugreifen, benötigt der Kubernetes-Operator die Microsoft Entra kubeconfig, die Sie mit dem az aksarc get-credentials Befehl abrufen können. Dieser Befehl bietet Zugriff auf den admin-basierten Kubeconfig sowie eine benutzerbasierte Kubeconfig. Die admin-basierte Kubeconfig-Datei enthält geheime Schlüssel und sollte regelmäßig sicher gespeichert und gedreht werden. Andererseits enthält die benutzerbasierte Microsoft Entra ID kubeconfig keine geheimen Schlüssel und kann an Benutzer verteilt werden, die von ihren Clientcomputern eine Verbindung herstellen.

Um diesen Azure CLI-Befehl auszuführen, benötigen Sie den Microsoft.HybridContainerService/provisionedClusterInstances/listUserKubeconfig/action, der in den Azure Kubernetes Service Arc Cluster-Rollenberechtigungen enthalten ist:

az aksarc get-credentials -g $resource_group_name -n $aks_cluster_name --file <file-name>

Jetzt können Sie kubectl verwenden, um Ihren Cluster zu verwalten. Beispielsweise können Sie die Knoten in Ihrem Cluster mit kubectl get nodes auflisten. Wenn Sie sie zum ersten Mal ausführen, müssen Sie sich anmelden, wie im folgenden Beispiel gezeigt:

kubectl get nodes

Zugreifen auf Ihren Cluster über ein Clientgerät (Proxymodus)

Um von überall aus mit einem Befehl az connectedk8s proxy auf den Kubernetes-Cluster zuzugreifen, benötigen Sie die Rollenberechtigung "Microsoft.Kubernetes/connectedClusters/listClusterUserCredential/action", die in der Azure Arc-fähigen Kubernetes Cluster-Benutzerrollenberechtigung enthalten ist.

Führen Sie die folgenden Schritte auf einem anderen Clientgerät aus:

  1. Melden Sie sich mit der Microsoft Entra-Authentifizierung an.

  2. Rufen Sie die Clusterverbindung kubeconfig ab, die für die Kommunikation mit dem Cluster von überall aus erforderlich ist (von selbst außerhalb der Firewall, die den Cluster umgibt):

    az connectedk8s proxy -n $aks_cluster_name -g $resource_group_name

    Hinweis

    Dieser Befehl öffnet den Proxy und blockiert die aktuelle Shell.

  3. Verwenden Sie kubectl in einer anderen Shell-Sitzung, um Anforderungen an den Cluster zu senden:

    kubectl get pods -A

Nun sollte eine Antwort aus dem Cluster mit der Liste aller Pods im default-Namespace angezeigt werden.

Weitere Informationen finden Sie unter Zugreifen auf Ihren Cluster von einem Clientgerät

Erstellen und Anzeigen von Clusterressourcen außerhalb des zugewiesenen Namespaces

Um zu versuchen, Pods außerhalb des Dev-Namespaces anzuzeigen, verwenden Sie den kubectl get pods Befehl mit der --all-namespaces Kennzeichnung:

kubectl get pods --all-namespaces

Die Gruppenmitgliedschaft des Benutzers verfügt nicht über eine Kubernetes-Rolle, die diese Aktion zulässt. Ohne die Berechtigung generiert der Befehl einen Fehler:

Error from server (Forbidden): pods is forbidden: User cannot list resource "pods" in API group "" at the cluster scope

Nächste Schritte