Verwenden der rollenbasierten Zugriffssteuerung in Kubernetes mit Microsoft Entra ID in Azure Kubernetes Service

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 bei einem AKS-Cluster mithilfe eines Microsoft Entra-Authentifizierungstokens 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 lernen Sie Folgendes:

• Steuern Sie den Zugriff mit Kubernetes RBAC in einem AKS-Cluster auf Grundlage der Microsoft Entra-Gruppenmitgliedschaft.
• Erstellen Sie Beispielgruppen und -benutzer*innen in Microsoft Entra ID.
• Erstellen Sie Rollen und RoleBindings in einem AKS-Cluster, um die entsprechenden Berechtigungen zum Erstellen und Anzeigen von Ressourcen zu gewähren.

Voraussetzungen

• Sie verfügen über einen AKS-Cluster mit aktivierter Microsoft Entra-Integration. Falls Sie einen AKS-Cluster mit dieser Konfiguration benötigen, lesen Sie die Informationen unter Integrieren von Microsoft Entra ID mit AKS.
• Kubernetes RBAC ist während der Erstellung des AKS-Clusters standardmäßig aktiviert. Um ein vorhandenes Cluster mit Microsoft Entra-Integration und Kubernetes RBAC zu aktualisieren, aktivieren Sie die Microsoft Entra-Integration auf Ihrem vorhandenen AKS-Cluster.
• Stellen Sie sicher, dass die Version 2.0.61 oder höher der Azure CLI installiert und konfiguriert ist. Führen Sie az --version aus, um die Version zu finden. Informationen zum Ausführen einer Installation oder eines Upgrades finden Sie unter Installieren der Azure CLI.
• Wenn Sie Terraform verwenden, installieren Sie Terraform, Version 2.99.0 oder höher.

Verwenden Sie das Azure-Portal oder die Azure-Befehlszeilenschnittstelle, um zu überprüfen, ob die Microsoft Entra-Integration mit Kubernetes RBAC aktiviert ist.

Azure-Portal

So führen Sie die Überprüfung über das Azure-Portal durch

1. Melden Sie sich beim Azure-Portal an, und navigieren Sie zu Ihrer AKS-Clusterressource.
2. Wählen Sie im Dienstmenü unter "Einstellungen" die Option "Sicherheitskonfiguration" aus.
3. Vergewissern Sie sich im Abschnitt Authentifizierung und Autorisierung, dass die Option Microsoft Entra-Authentifizierung mit Kubernetes RBAC aktiviert ist.

Azure-Befehlszeilenschnittstelle

Zur Überprüfung können Sie den Azure CLI-Befehl az aks show verwenden. Ersetzen Sie den Wert "myResourceGroup " durch den Ressourcengruppennamen, der Ihre AKS-Clusterressource hostet, und ersetzen Sie myAKSCluster durch den tatsächlichen Namen Ihres AKS-Clusters.

az aks show --resource-group myResourceGroup --name myAKSCluster

Wenn aktiviert, zeigt die Ausgabe, dass der Wert für enableAzureRbacfalse ist.

Erstellen von Demogruppen in Microsoft Entra ID

In diesem Artikel erstellen Sie zwei Benutzerrollen, um zu zeigen, wie Kubernetes RBAC und Microsoft Entra ID den Zugriff auf Clusterressourcen steuern. Die beiden folgenden Beispielrollen werden verwendet:

• Anwendungsentwickler
  • Ein Benutzer mit dem Namen aksdev, der der Gruppe appdev angehört.
• Websitezuverlässigkeits-Techniker (Site Reliability Engineer, SRE)
  • Ein Benutzer mit dem Namen akssre, der der Gruppe opssre angehört.

In Produktionsumgebungen können Sie vorhandene Benutzer*innen und Gruppen in einem Microsoft Entra-Mandanten nutzen.

1. Rufen Sie zuerst die Ressourcen-ID Ihres AKS-Clusters ab, indem Sie den Befehl az aks show verwenden. Weisen Sie die Ressourcen-ID anschließend einer Variablen mit dem Namen AKS_ID zu, damit in anderen Befehlen darauf verwiesen werden kann.

   AKS_ID=$(az aks show \
       --resource-group myResourceGroup \
       --name myAKSCluster \
       --query id -o tsv)
   

2. Erstellen Sie die erste Beispielgruppe in Microsoft Entra ID für die Anwendungsentwickler*innen mit dem Befehl az ad group create. Im folgenden Beispiel wird eine Gruppe mit dem Namen appdev erstellt:

   APPDEV_ID=$(az ad group create --display-name appdev --mail-nickname appdev --query id -o tsv)
   

3. Erstellen Sie eine Azure-Rollenzuweisung für die Gruppe appdev, indem Sie den Befehl az role assignment create verwenden. Bei dieser Zuweisung können alle Mitglieder der Gruppe kubectl zum Interagieren mit einem AKS-Cluster nutzen, wenn ihnen die Rolle Azure Kubernetes Service-Clusterbenutzer gewährt wird.

   az role assignment create \
     --assignee $APPDEV_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

   Tipp

   Wenn Sie einen Fehler erhalten (z. B. Principal 35bfec9328bd4d8d9b54dea6dac57b82 doesn't exist in the directory a5443dcd-cd0e-494d-a387-3039b419f0d5.), sollten Sie einige Sekunden warten, bis die ID des Microsoft Entra-Gruppenobjekts im Verzeichnis verteilt wurde. Versuchen Sie dann erneut, den Befehl az role assignment create auszuführen.

4. Erstellen Sie eine zweite Beispielgruppe für SREs (Websitezuverlässigkeits-Techniker) mit dem Namen opssre.

   OPSSRE_ID=$(az ad group create --display-name opssre --mail-nickname opssre --query id -o tsv)
   

5. Erstellen Sie eine Azure-Rollenzuweisung, um Mitgliedern der Gruppe die Rolle Azure Kubernetes Service-Clusterbenutzer zu gewähren.

   az role assignment create \
     --assignee $OPSSRE_ID \
     --role "Azure Kubernetes Service Cluster User Role" \
     --scope $AKS_ID
   

Erstellen von Demobenutzer*innen in Microsoft Entra ID

Nachdem wir nun zwei Beispielgruppen in der Microsoft Entra-ID für unsere Anwendungsentwickler und SREs erstellt haben, erstellen Sie zwei Beispielbenutzer. Um die Kubernetes RBAC-Integration am Ende des Artikels zu testen, melden Sie sich mit diesen Konten beim AKS-Cluster an.

Legen Sie den Benutzerprinzipalnamen und das Kennwort für Anwendungsentwickler fest.

Legen Sie den Benutzerprinzipalnamen (UPN) und das Kennwort für die Anwendungsentwickler fest. Der UPN muss den verifizierten Domänennamen Ihres Mandanten enthalten, zum Beispiel aksdev@contoso.com. Informationen zum Ermitteln (oder Festlegen) der überprüften Domänennamen in Ihrem Mandanten finden Sie unter Verwalten von benutzerdefinierten Domänennamen in Ihrer Microsoft Entra-ID.

Mit dem folgenden Befehl werden Sie aufgefordert, den UPN einzugeben, und er wird auf AAD_DEV_UPN festgelegt, damit er in einem späteren Befehl verwendet werden kann:

echo "Please enter the UPN for application developers: " && read AAD_DEV_UPN

Mit dem folgenden Befehl werden Sie aufgefordert, das Kennwort einzugeben, und es wird auf AAD_DEV_PW zur Verwendung in einem späteren Befehl festgelegt:

echo "Please enter the secure password for application developers: " && read AAD_DEV_PW

Erstellen der Benutzerkonten

1. Erstellen Sie das erste Benutzerkonto in Microsoft Entra ID mithilfe des Befehls az ad user create. Im folgenden Beispiel wird ein Benutzer mit dem AnzeigenameAKS Dev und dem UPN und dem sicheren Kennwort erstellt, wobei die Werte in AAD_DEV_UPN und AAD_DEV_PWverwendet werden:

   AKSDEV_ID=$(az ad user create \
     --display-name "AKS Dev" \
     --user-principal-name $AAD_DEV_UPN \
     --password $AAD_DEV_PW \
     --query id -o tsv)
   

2. Verwenden Sie den Befehl , um den Benutzer zur Gruppe az ad group member add hinzuzufügen, die im vorherigen Abschnitt erstellt wurde.

   az ad group member add --group appdev --member-id $AKSDEV_ID
   

3. Legen Sie den UPN und das Kennwort für SRES fest. Der UPN muss den verifizierten Domänennamen Ihres Mandanten enthalten, zum Beispiel akssre@contoso.com. Mit dem folgenden Befehl werden Sie aufgefordert, den UPN einzugeben, und er wird auf AAD_SRE_PW zur Verwendung in einem späteren Befehl festgelegt:

   echo "Please enter the UPN for SREs: " && read AAD_SRE_UPN
   

4. Mit dem folgenden Befehl werden Sie aufgefordert, das Kennwort einzugeben, und es wird auf AAD_SRE_PW zur Verwendung in einem späteren Befehl festgelegt:

   echo "Please enter the secure password for SREs: " && read AAD_SRE_PW
   

5. Erstellen Sie ein zweites Benutzerkonto. Im folgenden Beispiel wird ein Benutzer mit dem AnzeigenameAKS SRE und dem UPN und dem sicheren Kennwort erstellt, wobei die Werte in AAD_SRE_UPN und AAD_SRE_PWverwendet werden:

   # Create a user for the SRE role
   AKSSRE_ID=$(az ad user create \
     --display-name "AKS SRE" \
     --user-principal-name $AAD_SRE_UPN \
     --password $AAD_SRE_PW \
     --query id -o tsv)
   
   # Add the user to the opssre Entra ID group
   az ad group member add --group opssre --member-id $AKSSRE_ID
   

Erstellen von AKS-Clusterressourcen für Anwendungsentwickler

Sie haben damit Microsoft Entra-Gruppen und -Benutzer*innen sowie Azure-Rollenzuweisungen erstellt. Jetzt konfigurieren Sie den AKS-Cluster so, dass diese verschiedenen Gruppen auf bestimmte Ressourcen zugreifen können.

1. Rufen Sie die Administratoranmeldeinformationen für den Cluster mit dem Befehl az aks get-credentials ab. In einem der folgenden Abschnitte rufen Sie die Clusteranmeldeinformationen für reguläre Benutzer*innen ab, um den Microsoft Entra-Authentifizierungsflow in Aktion sehen zu können.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin
   

2. Erstellen Sie im AKS-Cluster einen Namespace, indem Sie den Befehl kubectl create namespace verwenden. Im folgenden Beispiel wird der Namespacename dev erstellt:

   kubectl create namespace dev
   

   Hinweis

   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 Zuweisungen können auf einen bestimmten Namespace oder im gesamten Cluster angewendet werden. Weitere Informationen finden Sie unter Verwenden der Kubernetes RBAC-Autorisierung.

   Wenn sich die Benutzer*innen, für die Sie die Kubernetes RBAC-Bindung gewähren, zum selben Microsoft Entra-Mandanten gehören, weisen Sie die Berechtigungen auf Grundlage des userPrincipalName (UPN, Benutzerprinzipalname) zu. Befindet sich der Benutzer in einem anderen Microsoft Entra-Mandanten, müssen Sie stattdessen die objectId-Eigenschaft abfragen und verwenden.

3. Erstellen Sie eine Rolle für den dev-Namespace, der dem Namespace vollständige Berechtigungen gewährt. In Produktionsumgebungen können Sie für unterschiedliche Benutzer oder Gruppen präzisere Berechtigungen angeben. Erstellen Sie eine Datei mit dem Namen role-dev-namespace.yaml, und fügen Sie das folgende YAML-Manifest ein:

   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 mit dem Befehl kubectl apply, 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 subject-Element eines RoleBinding-Elements festgelegt.

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

6. Erstellen Sie ein RoleBinding-Element für die Gruppe appdev, um die zuvor erstellte Rolle für den Namespacezugriff zu verwenden. Erstellen Sie eine Datei namens rolebinding-dev-namespace.yaml, und fügen Sie das folgende YAML-Manifest ein. Ersetzen Sie in der letzten Zeile groupObjectId durch die Gruppenobjekt-ID, die vom vorherigen Befehl ausgegeben wird.

   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 kind: User an und ersetzen Sie groupObjectId durch den Benutzerprinzipalnamen (UPN) im vorherigen Beispiel.

7. Erstellen Sie das RoleBinding-Element mit dem Befehl kubectl apply, und geben Sie den Dateinamen Ihres YAML-Manifests an:

   kubectl apply -f rolebinding-dev-namespace.yaml
   

Erstellen der AKS-Clusterressourcen für Websitezuverlässigkeits-Techniker

Wiederholen Sie nun die vorherigen Schritte zum Erstellen eines Namespace, einer Rolle und eines RoleBinding-Elements für die Websitezuverlässigkeits-Techniker.

1. Erstellen Sie mithilfe des Befehls einen Namespace für kubectl create namespace.

   kubectl create namespace sre
   

2. Erstellen Sie eine Datei mit dem Namen role-sre-namespace.yaml, und fügen Sie das folgende YAML-Manifest ein:

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

3. Erstellen Sie die Rolle mit dem Befehl kubectl apply, und geben Sie den Dateinamen Ihres YAML-Manifests an.

   kubectl apply -f role-sre-namespace.yaml
   

4. Rufen Sie die Ressourcen-ID für die Gruppe opssre ab, indem Sie den Befehl az ad group show verwenden.

   az ad group show --group opssre --query id -o tsv
   

5. Erstellen Sie ein RoleBinding-Element für die Gruppe opssre, um die zuvor erstellte Rolle für den Namespacezugriff zu verwenden. Erstellen Sie eine Datei namens rolebinding-sre-namespace.yaml, und fügen Sie das folgende YAML-Manifest ein. Ersetzen Sie in der letzten Zeile groupObjectId durch die Gruppenobjekt-ID, die vom vorherigen Befehl ausgegeben wird.

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

6. Erstellen Sie das RoleBinding-Element mit dem Befehl kubectl apply, und geben Sie den Dateinamen Ihres YAML-Manifests an.

   kubectl apply -f rolebinding-sre-namespace.yaml
   

Interagieren mit Clusterressourcen mithilfe von Microsoft Entra-Identitäten

Testen Sie nun, dass die erwarteten Berechtigungen funktionieren, wenn Sie Ressourcen in einem AKS-Cluster erstellen und verwalten. In diesen Beispielen planen und anzeigen Sie Pods im zugewiesenen Namespace des Benutzers, und versuchen Sie, Pods außerhalb des zugewiesenen Namespaces zu planen und anzuzeigen.

1. Setzen Sie den Kontext kubeconfig zurück, indem Sie den Befehl az aks get-credentials verwenden. In einem vorherigen Abschnitt haben Sie den Kontext mit den Anmeldeinformationen für den Clusteradministrator festgelegt. Der/die Administratorbenutzer*in umgeht Microsoft Entra-Anmeldeaufforderungen. Ohne den --admin-Parameter wird der Benutzerkontext angewandt, für den alle Anforderungen mit Microsoft Entra ID authentifiziert werden müssen.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
   

2. Planen Sie einen grundlegenden NGINX-Pod, indem Sie den Befehl kubectl run im Namespace dev verwenden.

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

3. Geben Sie die Anmeldeinformationen für Ihr eigenes appdev@contoso.com-Konto, das Sie zu Beginn dieses Artikels erstellt haben, an der Anmeldeaufforderung ein. Nach der erfolgreichen Anmeldung wird das Kontotoken für weitere kubectl-Befehle zwischengespeichert. Die NGINX-Planung ist erfolgreich, wie die folgende Beispielausgabe zeigt:

   $ kubectl run nginx-dev --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   
   To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code B24ZD6FP8 to authenticate.
   
   pod/nginx-dev created
   

4. Verwenden Sie den Befehl kubectl get pods, um die Pods im Namespace dev anzuzeigen.

   kubectl get pods --namespace dev
   

5. Stellen Sie sicher, dass der Status des NGINX-Pods Wird ausgeführt lautet. Die Ausgabe sieht wie die folgende Ausgabe aus:

   $ kubectl get pods --namespace dev
   
   NAME        READY   STATUS    RESTARTS   AGE
   nginx-dev   1/1     Running   0          4m
   

Erstellen und Anzeigen von Clusterressourcen außerhalb des zugewiesenen Namespace

Versuchen Sie, Pods außerhalb des Namespace dev anzuzeigen. Verwenden Sie erneut den Befehl kubectl get pods, um nun --all-namespaces anzuzeigen.

kubectl get pods --all-namespaces

Die Gruppenmitgliedschaft des Benutzers verfügt nicht über eine Kubernetes-Rolle, die diese Aktion ermöglicht. Dies ist in der folgenden Beispielausgabe dargestellt:

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

Versuchen Sie auf die gleiche Weise, einen Pod in einem anderen Namespace zu planen, z. B. in sre. Die Gruppenmitgliedschaft des Benutzers wird nicht an einer Kubernetes-Rolle und einem RoleBinding-Element ausgerichtet, um diese Berechtigungen zu gewähren. Dies ist in der folgenden Beispielausgabe dargestellt:

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

Error from server (Forbidden): pods is forbidden: User "aksdev@contoso.com" cannot create resource "pods" in API group "" in the namespace "sre"

Testen des Zugriffs auf die AKS-Clusterressourcen durch Websitezuverlässigkeits-Techniker

Um zu bestätigen, dass unsere Microsoft Entra-Gruppenmitgliedschaft und Kubernetes RBAC zwischen verschiedenen Benutzern und Gruppen ordnungsgemäß funktionieren, probieren Sie die vorherigen Befehle aus, wenn sie als opssre-Benutzer angemeldet sind.

1. Setzen Sie den Kontext kubeconfig mit dem Befehl az aks get-credentials zurück. Hiermit wird das zuvor zwischengespeicherte Authentifizierungstoken für den Benutzer aksdev gelöscht.

   az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --overwrite-existing
   

2. Versuchen Sie, Pods im zugewiesenen Namespace sre zu planen und anzuzeigen. Melden Sie sich bei entsprechender Aufforderung mit Ihren eigenen opssre@contoso.com-Anmeldeinformationen an, die Sie zu Beginn dieses Artikels erstellt haben.

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

   Wie in der folgenden Beispielausgabe dargestellt, ist das Erstellen und Anzeigen der Pods erfolgreich:

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

3. Um sich anzumelden, verwenden Sie einen Webbrowser, um die Seite https://microsoft.com/devicelogin zu öffnen, und geben Sie den Code BM4RHP3FD ein, um sich zu authentifizieren.

   pod/nginx-sre created
   
   $ kubectl get pods --namespace sre
   
   NAME        READY   STATUS    RESTARTS   AGE
   nginx-sre   1/1     Running   0
   

4. Versuchen Sie, Pods außerhalb des zugewiesenen SRE-Namespace anzuzeigen bzw. zu planen.

   kubectl get pods --all-namespaces
   kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   

   Für diese kubectl-Befehle treten Fehler auf, wie in der folgenden Beispielausgabe zu sehen. Über die Gruppenmitgliedschaft des Benutzers und die Kubernetes-Rolle und RoleBindings werden keine Berechtigungen zum Erstellen oder Verwalten von Ressourcen in anderen Namespaces gewährt.

   $ kubectl get pods --all-namespaces
   Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot list pods at the cluster scope
   
   $ kubectl run nginx-sre --image=mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine --namespace dev
   Error from server (Forbidden): pods is forbidden: User "akssre@contoso.com" cannot create pods in the namespace "dev"
   

Bereinigen von Ressourcen

In diesem Artikel haben Sie Ressourcen im AKS-Cluster und Benutzer*innen und Gruppen in Microsoft Entra ID erstellt. Führen Sie zum Bereinigen aller Ressourcen die folgenden Befehle aus:

# Get the admin kubeconfig context to delete the necessary cluster resources.

az aks get-credentials --resource-group myResourceGroup --name myAKSCluster --admin

# Delete the dev and sre namespaces. This also deletes the pods, Roles, and RoleBindings.

kubectl delete namespace dev
kubectl delete namespace sre

# Delete the Azure AD user accounts for aksdev and akssre.

az ad user delete --upn-or-object-id $AKSDEV_ID
az ad user delete --upn-or-object-id $AKSSRE_ID

# Delete the Azure AD groups for appdev and opssre. This also deletes the Azure role assignments.

az ad group delete --group appdev
az ad group delete --group opssre

Nächste Schritte

• Weitere Informationen zum Schutz von Kubernetes-Clustern finden Sie unter Zugriffs- und Identitätsoptionen für AKS.
• Best Practices zur Identitäts- und Ressourcenkontrolle finden Sie unter Best Practices für Authentifizierung und Autorisierung in AKS.