Steuern des Zugriffs mithilfe von Microsoft Entra ID und Kubernetes RBAC für Windows Server

Gilt für: AKS auf Azure Stack HCI 22H2, AKS unter Windows Server

Azure Kubernetes Service (AKS) kann für die Verwendung von Microsoft Entra ID für die Benutzerauthentifizierung konfiguriert werden. 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 Arc 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, benötigen Sie die folgenden Voraussetzungen:

• Ein Kubernetes-Cluster, der in AKS Arc erstellt wurde. Wenn Sie Ihren Cluster einrichten müssen, lesen Sie die Anweisungen für die Verwendung von Windows Admin Center oder PowerShell zum Bereitstellen von AKS.
• Azure Arc-Verbindung. Sie müssen über eine Azure Arc-Verbindung mit Ihrem Kubernetes-Cluster verfügen. Informationen zum Aktivieren von Azure Arc finden Sie unter Connect an Azure Kubernetes Service on Azure Stack HCI cluster to Azure Arc-enabled Kubernetes.
• Sie benötigen Zugriff auf die folgenden Befehlszeilentools:
  • Azure CLI und die connectedk8s-Erweiterung. Azure CLI ist eine Reihe von Befehlen zum Erstellen und Verwalten von Azure-Ressourcen. 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. Installationsanweisungen finden Sie unter Installieren der Azure CLI.
  • Kubectl. Mit diesem Kubernetes-Befehlszeilentool 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 Version v1.24.0 ist. Installationsanweisungen finden Sie unter kubectl.
  • PowerShell und das AksHci PowerShell-Modul. PowerShell ist eine plattformübergreifende Aufgabenautomatisierungslösung, die aus einer Befehlszeilenshell, einer Skriptsprache und einem Konfigurationsverwaltungsframework besteht. Wenn Sie AKS Arc installiert haben, haben Sie Zugriff auf das AksHci PowerShell-Modul.
  • 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. 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. Rufen Sie die Clusteradministratoranmeldeinformationen mithilfe des Get-AksHciCredential Befehls ab:

   Get-AksHciCredential -name <name-of-your-cluster>
   

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.

3. 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: ["*"]
   

4. 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
   

5. 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
   

6. 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 die Rollenbindung (RoleBinding) für einen einzelnen Benutzer erstellen möchten, geben Sie kind: User an, und ersetzen Sie groupObjectId durch den Benutzerprinzipalnamen (User Principal Name, UPN) im Beispiel.

7. 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-IDs

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 bei Azure mit dem $AKSDEV_ID Benutzerkonto an, das Sie als Eingabe für den az ad group member add Befehl angegeben haben. Führen Sie den az connectedk8s proxy Befehl aus, um einen Kanal zum Cluster zu öffnen:

   az connectedk8s proxy -n <cluster-name> -g <resource-group>
   

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, sollte die folgende Ausgabe angezeigt werden:

   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

• Weitere Informationen zur Sicherheit in AKS Arc auf Windows Server