Share via

Steuern des Zugriffs mithilfe von Microsoft Entra ID und Kubernetes RBAC in AKS, die von Azure Arc aktiviert werden

  • Artikel

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

Azure Kubernetes Service (AKS) kann für die Verwendung 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 Microsoft Entra Gruppenmitgliedschaft in AKS Arc steuern. Sie erstellen eine Demogruppe und Benutzer in 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 mithilfe Microsoft Entra Identität einrichten, benötigen Sie Folgendes:

  • Ein kubernetes-Cluster, der in AKS Arc erstellt wurde

    Sie benötigen einen Kubernetes-Cluster, der in AKS Arc erstellt wurde. Wenn Sie Ihren Cluster einrichten müssen, finden Sie Anweisungen zum Verwenden von Windows Admin Center oder PowerShell zum Bereitstellen von AKS.

  • Azure Arc-Verbindung

    Sie benötigen eine Azure Arc-Verbindung mit Ihrem Kubernetes-Cluster. Informationen zum Aktivieren von Azure Arc finden Sie unter Verbinden einer Azure Kubernetes Service im Azure Stack HCI-Cluster mit Azure Arc-fähigen Kubernetes.

  • Sie benötigen Zugriff auf die folgenden Befehlszeilentools:

    • Azure CLI und die connectedk8s-Erweiterung

      Die Azure-Befehlszeilenschnittstelle (Command-Line Interface, CLI) setzt sich aus Befehlen zum Erstellen und Verwalten von Azure-Ressourcen zusammen. Um zu überprüfen, ob Sie über die Azure CLI verfügen, öffnen Sie ein Befehlszeilentool, und geben Sie Folgendes ein: az -v. Außerdem müssen Sie die connectedk8s-Erweiterung installieren, um einen Kanal für Ihren Kubernetes-Cluster zu öffnen.

      Die erforderlichen Installationsanleitungen finden Sie unter Installieren der Azure CLI.

    • Kubectl

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

    • PowerShell und das PowerShell-Modul „AksHci“

      PowerShell ist ein plattformübergreifendes Framework zur Aufgabenautomatisierung und Konfigurationsverwaltung, das aus einer Befehlszeilenshell und einer Skriptsprache besteht. Wenn Sie AKS Arc installiert haben, haben Sie Zugriff auf das AksHci PowerShell-Modul.

Optionale erste Schritte

Wenn Sie noch nicht über eine Microsoft Entra Gruppe verfügen, die Mitglieder enthält, können Sie eine Gruppe erstellen und einige Mitglieder hinzufügen, damit Sie die Anweisungen in diesem Artikel befolgen können.

Um die Arbeit mit Microsoft Entra ID und Kubernetes RBAC zu veranschaulichen, können Sie eine Microsoft Entra-Gruppe für Anwendungsentwickler erstellen, die verwendet werden kann, um zu zeigen, wie Kubernetes RBAC und Microsoft Entra ID den Zugriff auf Clusterressourcen steuern. In Produktionsumgebungen können Sie vorhandene Benutzer und Gruppen innerhalb eines Microsoft Entra Mandanten verwenden.

Create einer Demogruppe in Microsoft Entra ID

Erstellen Sie zunächst die Gruppe in Microsoft Entra ID in Ihrem Mandanten für die Anwendungsentwickler, indem Sie den Befehl az ad group create verwenden. Im folgenden Beispiel melden Sie sich bei Ihrem Azure-Mandanten an und erstellen dann eine Gruppe namens appdev:

az login
az ad group create --display-name appdev --mail-nickname appdev

Hinzufügen von Benutzern zu Ihrer Gruppe

Mit der Beispielgruppe, die in Microsoft Entra ID für unsere Anwendungsentwickler erstellt wurde, fügen wir 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 der Gruppe appdev, die im vorherigen Abschnitt erstellt wurde, einen Benutzer hinzu, indem Sie den Befehl az ad group member add verwenden. Wenn Sie Ihre Sitzung beenden, stellen Sie mithilfe von eine verbindung mit az loginAzure her.

$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

Create 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 Create Demogruppen in Microsoft Entra ID.

  1. Rufen Sie die Anmeldeinformationen des Clusteradministrators mit dem Befehl Get-AksHciCredential ab :

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

  2. Create mithilfe des Befehls kubectl create namespace einen Namespace im Kubernetes-Cluster. Im folgenden Beispiel wird ein Namespace namens deverstellt:

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

    Create eine Rolle für den Dev-Namespace. Mit dieser Rolle wird Vollzugriff auf den Namespace gewährt. In Produktionsumgebungen können Sie differenziertere Berechtigungen für verschiedene Benutzer oder Gruppen angeben.

  3. Create eine Datei namens 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. Create die Rolle mithilfe des Befehls kubectl apply aus, 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 groupObjectIdverwenden:

    38E5FA30-XXXX-4895-9A00-050712E3673A

  6. Create eine Datei namens rolebinding-dev-namespace.yaml, und fügen Sie das folgende YAML-Manifest ein. Sie legen die Rollenbindung fest, die es der appdev-Gruppe ermöglicht, die Rolle für den role-dev-namespace Namespacezugriff zu verwenden. Ersetzen Sie groupObjectId in der letzten Zeile durch die vom az ad group show Befehl erzeugte Gruppenobjekt-ID.

    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 das RoleBinding-Element mit dem Befehl kubectl apply, 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 Benutzerseitige Rollen für Kubernetes RBAC.

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 gibt 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 Administratorzugriff, der innerhalb eines Namespace mithilfe einer Rollenbindung gewährt werden soll. Ermöglicht bei Verwendung in einer Rollenbindung Lese-/Schreibzugriff auf die meisten Ressourcen in einem Namespace, einschließlich der Möglichkeit, Rollen und Rollenbindungen innerhalb des Namespace zu erstellen. 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 und höher erstellt wurden. Weitere Informationen finden Sie unter Schreibzugriff für Endpunkte.
Bearbeiten 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 Geheimnisse und ausgeführte Pods als beliebiges ServiceAccount im Namespace, sodass sie verwendet werden kann, um die API-Zugriffsebenen eines beliebigen ServiceAccount im Namespace zu erhalten. Diese Rolle lässt auch keinen Schreibzugriff auf Endpunkte in Clustern zu, die mit Kubernetes v1.22 und höher erstellt wurden. Weitere Informationen finden Sie unter Schreibzugriff für Endpunkte.
Ansicht 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 Geheimnissen nicht zu, da das Lesen des Inhalts von Geheimnissen den Zugriff auf ServiceAccount-Anmeldeinformationen im Namespace ermöglicht, was den API-Zugriff als beliebiges ServiceAccount im Namespace ermöglicht (eine Form der Rechteausweitung).

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 view auf Ihre Microsoft Entra Gruppe 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 view auf jeden Ihrer Microsoft Entra Benutzer an:

    kubectl create clusterrolebinding <name of your cluster role binding> --clusterrole=view --user=<Azure AD user object ID>

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

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

  2. Nachdem der Proxykanal eingerichtet wurde, öffnen Sie eine weitere Sitzung, und planen Sie einen NGINX-Pod mit dem Befehl kubectl run 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 Befehl kubectl get pods , um Pods im dev Namespace anzuzeigen:

    kubectl get pods --namespace dev

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

    $ kubectl get pods --namespace dev

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

Create und Anzeigen von Clusterressourcen außerhalb des zugewiesenen Namespace

Um Zu versuchen, Pods außerhalb des Dev-Namespace anzuzeigen, verwenden Sie den Befehl kubectl get pods mit dem --all-namespaces Flag.

kubectl get pods --all-namespaces

Die Gruppenmitgliedschaft des Benutzers verfügt nicht über eine Kubernetes-Rolle, die diese Aktion zulässt. Ohne die Berechtigung löst der Befehl einen Fehler aus.

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

Nächste Schritte