Verwenden der rollenbasierten Zugriffssteuerung (role-based access control, RBAC) für Kubernetes mit Azure Active Directory in Azure Kubernetes Service

Artikel
03/09/2023
12 Minuten Lesedauer

Azure Kubernetes Service (AKS) kann für die Verwendung von Azure Active Directory (Azure AD) für die Benutzerauthentifizierung konfiguriert werden. In dieser Konfiguration melden Sie sich an einem AKS-Cluster über ein Azure AD-Authentifizierungstoken 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 des Zugriffs mit Kubernetes RBAC in einem AKS-Cluster auf Grundlage der Azure AD-Gruppenmitgliedschaft.
Erstellen Sie Beispielgruppen und -benutzer in Azure AD.
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 Azure AD-Integration. Falls Sie einen AKS-Cluster mit dieser Konfiguration benötigen, lesen Sie die Informationen unter Von AKS verwaltete Azure Active Directory-Integration.
Kubernetes RBAC ist während der Erstellung des AKS-Clusters standardmäßig aktiviert. Aktivieren Sie die Azure AD-Integration in Ihrem AKS-Cluster, um ein Upgrade Ihres Clusters mit Azure AD-Integration und Kubernetes RBAC durchzuführen.
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 CLI, um sich zu vergewissern, dass die Azure AD-Integration mit Kubernetes RBAC aktiviert ist.

Azure portal
Azure-Befehlszeilenschnittstelle

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

Melden Sie sich in Ihrem Browser beim Azure-Portal an.
Navigieren Sie zu Kubernetes-Dienste, und wählen Sie im linken Bereich die Option Clusterkonfiguration aus.
Vergewissern Sie im Abschnitt Authentifizierung und Autorisierung, dass die Option Azure AD-Authentifizierung mit Kubernetes RBAC aktiviert ist.

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 Azure AD

In diesem Artikel erstellen wir zwei Benutzerrollen, mit denen veranschaulicht wird, wie mit Kubernetes RBAC und Azure AD 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 und Gruppen in einem Azure AD-Mandanten nutzen.

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)
```
Erstellen Sie die erste Beispielgruppe in Azure AD für die Anwendungsentwickler, indem Sie den Befehl az ad group createverwenden. 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)
```
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 Azure AD-Gruppenobjekts im Verzeichnis verteilt wurde. Versuchen Sie dann erneut, den Befehl az role assignment create auszuführen.

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 objectId -o tsv)
```
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 Demobenutzern in Azure AD

Nachdem Sie in Azure AD nun zwei Beispielgruppen für Anwendungsentwickler und SREs erstellt haben, erstellen Sie zwei Beispielbenutzer. 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

Erstellen Sie das erste Benutzerkonto in Azure AD mit dem Befehl 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 objectId -o tsv)

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

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

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

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 objectId -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 Azure AD-Gruppen, Benutzer und Azure-Rollenzuweisungen erstellt. Konfigurieren Sie den AKS-Cluster nun so, dass für diese unterschiedlichen Gruppen der Zugriff auf bestimmte Ressourcen zugelassen wird.

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 ab, um den Azure AD-Authentifizierungsablauf in Aktion sehen zu können.

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

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 der Benutzer, für den die Kubernetes RBAC-Bindung gewährt wird, auf demselben Azure AD-Mandanten befindet, weisen Sie Berechtigungen gemäß userPrincipalName (UPN) zu. Befindet sich der Benutzer in einem anderen Azure AD-Mandanten, müssen Sie stattdessen die objectId-Eigenschaft abfragen und verwenden.

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

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

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

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.

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.

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

kubectl create namespace sre

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

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

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

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

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 über Azure AD-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.

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 Administratorbenutzer umgeht Azure AD-Anmeldeaufforderungen. Ohne den Parameter --admin wird der Benutzerkontext angewendet, für den alle Anforderungen per Azure AD authentifiziert werden müssen.

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

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

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

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

kubectl get pods --namespace dev

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 opssre angemeldet sind, um zu bestätigen, dass unsere Azure AD-Gruppenmitgliedschaft und Kubernetes RBAC für unterschiedliche Benutzer und Gruppen richtig funktionieren.

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

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

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 und Gruppen in Azure AD 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.