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. Für ein Upgrade Ihres Clusters mit Microsoft Entra-Integration und Kubernetes RBAC aktivieren Sie die Microsoft Entra-Integration in 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 ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sei bei Bedarf 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 Clusterkonfiguration 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 Namen der Ressourcengruppe, die die AKS-Clusterressource hostet, und ersetzen Sie myAKSCluster durch den tatsächlichen Namen Ihres AKS-Clusters.

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

Wenn Kubernetes RBAC aktiviert ist, hat enableAzureRbac in der Ausgabe den Wert false.

Erstellen von Demogruppen in Microsoft Entra ID

In diesem Artikel erstellen Sie zwei Benutzerrollen, mit denen veranschaulicht wird, wie mit Kubernetes RBAC und Microsoft Entra ID der Zugriff auf Clusterressourcen gesteuert wird. 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 Sie in Microsoft Entra ID nun zwei Beispielgruppen für Anwendungsentwickler*innen und SREs erstellt haben, erstellen Sie zwei Beispielbenutzer*innen. Um am Ende des Artikels die Integration von Kubernetes RBAC zu testen, melden Sie sich mit diesen Konten am 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.

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 az ad group member add, um den Benutzer zur Gruppe appdev 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 Azure AD 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. Konfigurieren Sie den AKS-Cluster nun so, dass für diese unterschiedlichen Gruppen der Zugriff auf bestimmte Ressourcen zugelassen wird.

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 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 obigen 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 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 kubectl create namespace einen Namespace für sre.

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

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

5. 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, ob die Berechtigungen wie erwartet funktionieren, wenn Sie in einem AKS-Cluster Ressourcen erstellen und verwalten. In diesen Beispielen werden Pods im zugewiesenen Namespace des Benutzers geplant und angezeigt, und es wird versucht, 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 etwa 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

Probieren Sie die obigen Befehle aus, wenn Sie als Benutzer*in opssre angemeldet sind, um zu bestätigen, dass Ihre Microsoft Entra-Gruppenmitgliedschaft und Kubernetes RBAC für unterschiedliche Benutzer*innen und Gruppen richtig funktionieren.

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. To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code BM4RHP3FD to authenticate.

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.