Freigeben über

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

  • Artikel

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

Azure Kubernetes Service (AKS) kann für die Verwendung der 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 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 zur 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 Verbinden eines Azure Kubernetes Service in Azure Stack HCI-Clusters mit Kubernetes mit Azure Arc-Unterstützung.
  • Sie benötigen Zugriff auf die folgenden Befehlszeilentools:
    • Azure CLI und die Erweiterung connectedk8s. Die Azure CLI ist eine Reihe von Befehlen, die zum Erstellen und Verwalten von Azure-Ressourcen verwendet werden. 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 für Ihren 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 1.24.0 ist. Installationsanweisungen finden Sie unter kubectl.
    • PowerShell und das PowerShell-Modul AksHci. PowerShell ist eine plattformübergreifende Lösung zur Aufgabenautomatisierung, die aus einer Befehlszeilenshell, einer Skriptsprache und einem Konfigurationsverwaltungsframework besteht. Wenn Sie AKS Arc installiert haben, haben Sie Zugriff auf das PowerShell-Modul AksHci .

Optionale erste Schritte

Wenn Sie noch nicht über eine Microsoft Entra-Gruppe verfügen, die Mitglieder enthält, sollten 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.

Erstellen einer Demogruppe in Microsoft Entra ID

Erstellen Sie zunächst die Gruppe in Microsoft Entra ID in Ihrem Mandanten für die Anwendungsentwickler mithilfe des az ad group create Befehls. 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

Fügen Sie mit der Beispielgruppe, die in der Microsoft Entra-ID für Anwendungsentwickler erstellt wurde, 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 appdev-Gruppe , die im vorherigen Abschnitt erstellt wurde, mithilfe des az ad group member add Befehls einen Benutzer hinzu. Wenn Sie Ihre Sitzung beenden, stellen Sie mithilfe von wieder 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

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

  1. Rufen Sie die Anmeldeinformationen des Clusteradministrators mithilfe des Befehls ab Get-AksHciCredential :

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

  2. Erstellen Sie mithilfe kubectl create namespace des Befehls einen Namespace im Kubernetes-Cluster. Im folgenden Beispiel wird ein Namespace mit dem Namen 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.

    Erstellen Sie 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. 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 eines RoleBinding festgelegt:

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

    Der az ad group show Befehl gibt den Wert zurück, den groupObjectIdSie als verwenden:

    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, die es der appdev-Gruppe ermöglicht, die Rolle für den role-dev-namespace Namespacezugriff zu verwenden. 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 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-Rollen mit Benutzerzugriff.

Benutzerbezogene Rollen

Standard-ClusterRole Standard-ClusterRoleBinding BESCHREIBUNG
cluster-admin Gruppe „system:masters“ Ermöglicht den Zugriff von Superbenutzern, 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 den Administratorzugriff, der in einem 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+ 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 die Ausführung von Pods als jeden 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+ 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 beliebiger ServiceAccount im Namespace ermöglicht (eine Form der Berechtigungserweiterung).

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 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 kubectl run Befehl 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-Namespace anzuzeigen, verwenden Sie den kubectl get pods Befehl 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 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