Freigeben über

Steuern des Zugriffs mithilfe von Microsoft Entra ID und Kubernetes RBAC

  • Artikel

Gilt für: AKS auf Azure Stack HCI 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.

  • Sie benötigen die Azure CLI installiert und konfiguriert. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI.

  • Installieren Sie die neueste Version der aksarc Erweiterungen und connectedk8s Azure CLI:

    az extension add --name aksarc
az extension add --name connectedk8s

    Wenn Sie die Erweiterung bereits installiert haben, aktualisieren Sie die aksarc Erweiterung auf die neueste Version:

    az extension update --name aksarc
az extension update --name connectedk8s

  • Kubectl. Mit dem Befehlszeilentool Kubernetes, Kubectl, können Sie Befehle für Ihre Kubernetes-Cluster ausführen. Um zu überprüfen, ob Sie Kubectl installiert haben, öffnen Sie eine Eingabeaufforderung, 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.

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 "sample-aksarccluster" --resource-group "sample-rg" --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>

Arbeiten mit Clusterressourcen mithilfe von Microsoft Entra-Identitäten

Testen Sie nun die erwarteten Berechtigungen, wenn Sie Ressourcen in einem Kubernetes-Cluster erstellen und verwalten. In diesen Beispielen planen Sie Pods im zugewiesenen Namespace des Benutzers und zeigen sie an. Anschließend versuchen Sie, Pods außerhalb des zugewiesenen Namespaces zu planen und anzuzeigen.

  1. Melden Sie sich mit dem $AKSDEV_ID Benutzerkonto bei Azure an, das Sie als Eingabe an den az ad group member add Befehl übergeben haben. Führen Sie den az connectedk8s proxy Befehl aus, um einen Kanal zum Cluster zu öffnen:

    az connectedk8s proxy --name "sample-aksarccluster" --resource-group "sample-rg"

  2. Nachdem der Proxykanal eingerichtet wurde, öffnen Sie eine andere Sitzung, und planen Sie einen NGINX-Pod mithilfe des kubectl run Befehls im Dev-Namespace :

    kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev

    Wenn NGINX erfolgreich geplant wurde, wird die folgende Ausgabe angezeigt:

    pod/nginx-dev created

  3. Verwenden Sie nun den kubectl get pods Befehl, um Pods im dev Namespace anzuzeigen:

    kubectl get pods --namespace dev

    Wenn NGINX erfolgreich ausgeführt wird, sollte die folgende Ausgabe angezeigt werden:

    NAME        READY   STATUS    RESTARTS   AGE
nginx-dev   1/1     Running   0          4m

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