Freigeben über

Zugriffs- und Identitätsoptionen für von Azure Arc aktivierte AKS

  • Artikel

Gilt für: AKS auf Azure Local, Version 23H2

Sie können den Zugriff auf Kubernetes-Cluster auf verschiedene Arten authentifizieren, autorisieren, schützen und steuern:

Kubernetes RBAC und Azure RBAC helfen Ihnen, den Clusterzugriff zu sichern und nur die mindest erforderlichen Berechtigungen für Entwickler und Operatoren bereitzustellen.

In diesem Artikel werden die wichtigsten Konzepte für die Authentifizierung und Zuweisung von Berechtigungen in AKS vorgestellt.

RBAC in Kubernetes

Kubernetes RBAC ermöglicht eine präzise Filterung von Benutzeraktionen. Der Steuerungsmechanismus ist wie folgt:

  • Sie weisen Benutzern oder Benutzergruppen die Berechtigung zum Erstellen und Ändern von Ressourcen oder zum Anzeigen von Protokollen zur Ausführung von Anwendungsworkloads zu.
  • Sie können Berechtigungen auf einen einzelnen Namespace begrenzen oder für den gesamten AKS-Cluster erteilen.
  • Sie erstellen Rollen, um Berechtigungen zu definieren, und weisen dann Benutzern diese Rollen mit Rollenbindungen zu.

Weitere Informationen finden Sie unter Verwenden der Kubernetes RBAC-Autorisierung.

Rollen und Clusterrollen

Rollen

Bevor Sie Benutzern mit Kubernetes RBAC Berechtigungen zuweisen, definieren Sie Benutzerberechtigungen als Rolle. Erteilen von Berechtigungen innerhalb eines Kubernetes-Namespaces mithilfe von Rollen.

Mit Kubernetes-Rollen werden Berechtigungen erteilt und nicht verweigert. Um Berechtigungen für den gesamten Cluster oder für Clusterressourcen außerhalb eines bestimmten Namespaces zu erteilen, können Sie ClusterRoles verwenden.

Clusterrollen

Eine Clusterrolle erteilt Berechtigungen für Ressourcen im gesamten Cluster und nicht nur in einem bestimmten Namespace und wendet diese an.

Rollenbindungen und Clusterrollenbindungen

Nachdem Sie Rollen definiert haben, um Ressourcen Berechtigungen zu erteilen, weisen Sie diese Kubernetes RBAC-Berechtigungen mit einer RoleBinding zu. Wenn Ihr AKS-Cluster in Microsoft Entra ID integriert ist, erteilen RoleBindings Microsoft Entra-Benutzern Berechtigungen zum Ausführen von Aktionen innerhalb des Clusters. Siehe Steuern des Zugriffs mithilfe von Microsoft Entra ID und Kubernetes RBAC

Rollenbindungen

Weisen Sie Benutzern Rollen für einen bestimmten Namespace mithilfe von Rollenbindungen zu. Mit Rollenbindungen können Sie einen einzelnen AKS-Cluster logisch aufteilen und den Benutzern nur den Zugriff auf die Anwendungsressourcen im jeweils zugewiesenen Namespace erlauben.

Verwenden Sie ClusterRoleBindings, um Rollen über den gesamten Cluster oder an Clusterressourcen außerhalb eines bestimmten Namespaces zu binden.

ClusterRoleBinding

Mit einer Clusterrollenbindung binden Sie Rollen an Benutzer und wenden sie auf Ressourcen im gesamten Cluster und nicht auf einen bestimmten Namespace an. Mit diesem Ansatz können Sie Ihren Administratoren oder Supporttechnikern Zugriff auf alle Ressourcen im AKS-Cluster gewähren.

Kubernetes-Dienstkonten

Dienstkonten sind einer der Hauptbenutzertypen in Kubernetes. Die Kubernetes-API enthält und verwaltet Dienstkonten. Dienstkontoanmeldeinformationen werden als Kubernetes-Schlüssel gespeichert, sodass sie von autorisierten Pods für die Kommunikation mit dem API-Server verwendet werden können. Die meisten API-Anforderungen stellen einen Authentifizierungstoken für ein Dienstkonto oder ein normales Benutzerkonto bereit.

Normale Benutzerkonten ermöglichen den eher herkömmlichen Zugriff für Personen wie Administratoren oder Entwickler und nicht nur für Dienste und Prozesse. Kubernetes bietet zwar keine Identitätsverwaltungslösung zum Speichern regulärer Benutzerkonten und Kennwörter, aber Sie können externe Identitätslösungen in Kubernetes integrieren. Bei AKS-Clustern ist diese integrierte Identitätslösung Microsoft Entra ID.

Weitere Informationen zu den Identitätsoptionen in Kubernetes finden Sie unter Kubernetes-Authentifizierung.

Rollenbasierte Zugriffssteuerung (Azure)

Azure Role-based Access Control (RBAC) ist ein Autorisierungssystem, das auf Azure Resource Manager basiert und eine differenzierte Zugriffsverwaltung von Azure-Ressourcen bietet.

RBAC-System Beschreibung
Kubernetes RBAC Ist für Kubernetes-Ressourcen innerhalb Ihres AKS-Clusters bestimmt.
Azure RBAC Ist für Ressourcen innerhalb Ihres Azure-Abonnements bestimmt.

Mit der rollenbasierten Zugriffssteuerung von Azure erstellen Sie eine Rollendefinition, welche die anzuwendenden Berechtigungen erläutert. Anschließend weisen Sie einem Benutzer oder einer Gruppe diese Rollendefinition über eine Rollenzuweisung für einen bestimmten Bereich zu. Der Bereich kann eine einzelne Ressource, eine Ressourcengruppe oder das gesamte Abonnement sein.

Weitere Informationen finden Sie unter Was ist die rollenbasierte Zugriffssteuerung von Azure (Azure Role-Based Access Control, Azure RBAC)?

Es gibt zwei erforderliche Zugriffsebenen, um einen AKS Arc-Cluster vollständig zu betreiben:

  • Zugriff auf die AKS-Ressource in Ihrem Azure-Abonnement.
    • Steuern Sie die Skalierung oder das Upgrade Ihres Clusters mithilfe der von Azure Arc-APIs aktivierten AKS.
    • Rufen Sie Ihren Administrator, zertifikatbasierte Kubeconfig ab.
    • Pull your Entra ID enabled kubeconfig.
  • Zugriff auf die Kubernetes-API. Dieser Zugriff wird mit einer der beiden folgenden Methoden gesteuert:
    • Kubernetes RBAC oder
    • Integration von Azure RBAC in AKS für die Kubernetes-Autorisierung

Azure RBAC zum Autorisieren des Zugriffs auf die AKS-Ressource

Mit Azure RBAC können Sie Ihren Benutzern (oder Identitäten) einen präzisen Zugriff auf AKS-Ressourcen in einem Abonnement oder abonnementsübergreifend bereitstellen. Für diese Aktion der Steuerungsebene stehen drei Rollen zur Verfügung: Azure Kubernetes Service Arc Cluster Admin Role, Azure Kubernetes Service Arc Cluster User Role und Azure Kubernetes Service Arc Contributor Role. Jede Rolle verfügt über einen anderen Berechtigungsbereich, wie in Azure integrierte Rollen für Container beschrieben. Sie können beispielsweise die Rolle "Azure Kubernetes Service Arc-Mitwirkender " verwenden, um Ihren Cluster zu erstellen, zu skalieren und zu aktualisieren. Unterdessen verfügt ein anderer Benutzer mit der Azure Kubernetes Service Arc Cluster-Administratorrolle nur über die Berechtigung, den Administrator kubeconfig abzurufen.

Azure RBAC für die Kubernetes-Autorisierung

Mit der Azure RBAC-Integration verwendet AKS einen Kubernetes-Autorisierungswebhook-Server, sodass Sie die integrierten Kubernetes-Clusterressourcenberechtigungen und -zuordnungen mithilfe von Azure-Rollendefinitionen und Rollenzuweisungen verwalten können.

Diagramm des Autorisierungsflusses.

Wie in diesem Diagramm gezeigt, folgen bei Verwendung der Azure RBAC-Integration alle Anforderungen an die Kubernetes-API dem gleichen Authentifizierungsfluss wie in der Microsoft Entra-Integration beschrieben.

Wenn die Identität, die die Anforderung stellt, in Microsoft Entra ID vorhanden ist, azure teams with Kubernetes RBAC to authorize the request. Wenn die Identität außerhalb der Microsoft Entra-ID vorhanden ist (z. B. ein Kubernetes-Dienstkonto), wird die Autorisierung auf das normale Kubernetes-RBAC zurückverzögert.

In diesem Szenario verwenden Sie Azure RBAC-Mechanismen und -APIs, um Benutzern integrierte Rollen zuzuweisen oder benutzerdefinierte Rollen zu erstellen, wie es auch bei Kubernetes-Rollen der Fall ist.

Mit diesem Feature gewähren Sie Benutzern nicht nur abonnementübergreifende Berechtigungen für die AKS-Ressource, sondern konfigurieren auch die Rolle und die Berechtigungen für Aktionen innerhalb dieser Cluster, die den Zugriff auf die Kubernetes-API steuern. Für diese Datenebenenaktion stehen vier integrierte Rollen zur Verfügung, die jeweils einen eigenen Berechtigungsbereich aufweisen, wie im Abschnitt "Integrierte Rollen" beschrieben.

Wichtig

Sie müssen Azure RBAC für Kubernetes-Autorisierung aktivieren, bevor Sie rollenzuweisungen ausführen. Weitere Details und schrittweise Anleitungen finden Sie unter Verwenden von Azure RBAC für kubernetes-Autorisierung.

Integrierte Rollen

AKS, die von Arc aktiviert sind, stellt die folgenden fünf integrierten Rollen bereit. Sie ähneln den integrierten Kubernetes-Rollen mit einigen Unterschieden, z. B. der Unterstützung von CRDs. Sehen Sie sich die vollständige Liste der Aktionen an, die für die einzelnen integrierten Azure-Rollen zulässig sind.

Rolle Beschreibung
Azure Arc-aktivierter Kubernetes-Clusterbenutzer Ermöglicht es Ihnen, die Cluster Connect-basierte Kubeconfig-Datei abzurufen, um Cluster von überall aus zu verwalten.
Anzeigeberechtigter für Azure Arc Kubernetes Ermöglicht schreibgeschützten Zugriff, um die meisten Objekte in einem Namespace anzuzeigen.
Ermöglicht das Anzeigen von geheimen Schlüsseln nicht, da leseberechtigungen für geheime Schlüssel den Zugriff auf ServiceAccount-Anmeldeinformationen im Namespace ermöglichen. Diese Anmeldeinformationen ermöglichen wiederum den API-Zugriff über diesen ServiceAccount-Wert (eine Form der Berechtigungseskalation).
Schreibberechtigter für Azure Arc Kubernetes Ermöglicht Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace.
Ermöglicht das Anzeigen oder Ändern von Rollen oder Rollenbindungen nicht. Diese Rolle ermöglicht jedoch den Zugriff auf geheime Schlüssel und das Ausführen von Pods als beliebiger ServiceAccount-Wert im Namespace, sodass sie verwendet werden kann, um die API-Zugriffsebenen eines solchen ServiceAccount-Werts im Namespace zu erhalten.
Azure Arc Kubernetes-Administrator Mit dieser Rolle wird Administratorzugriff gewährt. Es soll innerhalb eines Namespace über RoleBinding gewährt werden. Wenn Sie es in RoleBinding verwenden, ermöglicht es Lese-/Schreibzugriff auf die meisten Ressourcen in einem Namespace, einschließlich der Möglichkeit, Rollen und Rollenbindungen innerhalb des Namespaces zu erstellen. Diese Rolle lässt keinen Schreibzugriff auf das Ressourcenkontingent oder den Namespace selbst zu.
Azure Arc Kubernetes-Clusteradministrator Ermöglicht den Zugriff auf "Superuser", um jede Aktion für jede Ressource auszuführen. Wenn Sie es in ClusterRoleBinding verwenden, bietet es die vollständige Kontrolle über jede Ressource im Cluster und in allen Namespaces. Wenn Sie es in RoleBinding verwenden, bietet es die vollständige Kontrolle über jede Ressource im Rollenbindungsnamespace, einschließlich des Namespace selbst.

Microsoft Entra-Integration

Verbessern Sie Ihre AKS-Clustersicherheit mit der Microsoft Entra-Integration. Basierend auf der Unternehmensidentitätsverwaltung ist Microsoft Entra ID ein mehrinstanzenbasierter, cloudbasierter Verzeichnis- und Identitätsverwaltungsdienst, der kerne Verzeichnisdienste, Anwendungszugriffsverwaltung und Identitätsschutz kombiniert. Mit Microsoft Entra ID können Sie lokale Identitäten in AKS-Cluster integrieren und so eine zentrale Quelle für die Kontoverwaltung und Sicherheit bereitstellen.

Flussdiagramm mit Entra-Integration.

Mit Microsoft Entra-integrierten AKS-Clustern können Sie Benutzern oder Gruppen Zugriff auf Kubernetes-Ressourcen innerhalb eines Namespaces oder über den Cluster gewähren.

  • Führen Sie den Befehl "az aksarc get-credentials" aus, um einen Kubectl-Konfigurationskontext abzurufen.
  • Wenn ein Benutzer mit kubectl mit dem AKS-Cluster interagiert, wird er aufgefordert, sich mit seinen Microsoft Entra-Anmeldeinformationen anzumelden.

Dieser Ansatz stellt eine zentrale Quelle für die Verwaltung von Benutzerkonten und Anmeldekennwörtern bereit. Der Benutzer kann nur auf die Vom Kubernetes-Clusteradministrator definierten Ressourcen zugreifen.

Die Microsoft Entra-Authentifizierung wird für AKS-Cluster mit OpenID Connect bereitgestellt. OpenID Connect ist eine Identitätsebene, die auf dem OAuth 2.0-Protokoll aufbaut. Weitere Informationen zu OpenID Connect finden Sie in der OpenID Connect-Dokumentation. Von innerhalb des Kubernetes-Clusters wird die Webhook-Tokenauthentifizierung verwendet, um Authentifizierungstoken zu überprüfen. Die Webhooktokenauthentifizierung wird als Teil des AKS-Clusters konfiguriert und verwaltet.

Zusammenfassung

Die folgende Tabelle enthält eine Zusammenfassung, wie Benutzer sich bei Kubernetes authentifizieren können, wenn die Microsoft Entra-Integration aktiviert ist. In allen Fällen lautet die Reihenfolge der Befehle:

  1. Ausführen von az login zur Authentifizierung bei Azure.
  2. Führen Sie diesen Befehl az aksarc get-credentials aus, um Anmeldeinformationen für den Kubernetes-Cluster herunterzuladen .kube/config.
  3. Ausführung von kubectl-Befehlen.
    • Der erste Befehl kann die browserbasierte Authentifizierung auslösen, um sich beim Kubernetes-Cluster zu authentifizieren, wie in der folgenden Tabelle beschrieben.
Beschreibung Rollenzuweisung erforderlich Clusteradministrator-Microsoft Entra-Gruppen Einsatzgebiete
Administratoranmeldung mit Clientzertifikat Azure Kubernetes Service Arc Cluster-Administratorrolle. Diese Rolle ermöglicht az aksarc get-credentials die Verwendung mit dem --admin Flag, das ein Nicht-Microsoft Entra-Cluster-Administratorzertifikat in die KUBE/config des Benutzers herunterlädt. Dies ist der einzige Zweck der Azure Kubernetes-Administratorrolle. Nicht zutreffend Wenn Sie permanent blockiert werden, indem Sie keinen Zugriff auf eine gültige Microsoft Entra-Gruppe mit Zugriff auf Ihren Cluster haben.
Microsoft Entra-ID mit manuellen (Cluster) RoleBindings Azure Kubernetes Service Arc Cluster-Benutzerrolle. Die Benutzerrolle ermöglicht az aksarc get-credentials die Verwendung ohne Kennzeichnung --admin . Dies ist der einzige Zweck der Azure Kubernetes-Dienstclusterbenutzerrolle .) Das Ergebnis für einen Microsoft Entra ID-fähigen Cluster ist der Download eines leeren Eintrags in .kube/config, der die browserbasierte Authentifizierung auslöst, wenn er zum ersten Mal von Kubectl verwendet wird. Da sich der Benutzer nicht in einer Clusteradministratorgruppe befindet, werden seine Rechte vollständig von Rollenbindings oder ClusterRoleBindings gesteuert, die von Clusteradministratoren eingerichtet werden. Die (Cluster) RoleBindings nominieren Microsoft Entra-Benutzer oder Microsoft Entra-Gruppen als Themen. Wenn keine solchen Bindungen eingerichtet wurden, kann der Benutzer keine Kubectl-Befehle aussetzen. Wenn Sie eine differenzierte Zugriffssteuerung wünschen und Azure RBAC nicht für die Kubernetes-Autorisierung verwenden. Beachten Sie, dass sich der Benutzer, der die Bindungen einrichtet, mit einer der anderen in dieser Tabelle aufgeführten Methoden anmelden muss.
Microsoft Entra-ID nach Mitglied der Microsoft Entra-Gruppe des Clusteradministrators (festlegen mithilfe --aad-admin-group-object-ids der Kennzeichnung in Azure CLI) Identisch mit vorheriger. Der Benutzer ist Mitglied einer der hier aufgelisteten Gruppen. AKS generiert automatisch eine Clusterrollenbindung, die alle aufgelisteten Gruppen an die Kubernetes-Rolle cluster-admin bindet. Daher können Benutzer in diesen Gruppen alle kubectl-Befehle als cluster-admin ausführen. Wenn Sie Benutzern vollständige Administratorrechte gewähren möchten und azure RBAC für die Kubernetes-Autorisierung nicht verwenden.
Microsoft Entra-ID mit Azure RBAC für Kubernetes-Autorisierung Zwei Rollen:
Azure Kubernetes Service Arc Cluster-Benutzerrolle (wie zuvor beschrieben).
Eine der zuvor beschriebenen Azure Arc Kubernetes-Rollen oder Ihre eigene benutzerdefinierte Alternative.		 Das Feld "Administratorrollen" auf der Registerkarte "Konfiguration " ist irrelevant, wenn die Azure RBAC für kubernetes-Autorisierung aktiviert ist. Sie verwenden Azure RBAC für die Kubernetes-Autorisierung. Dieser Ansatz ermöglicht Ihnen eine differenzierte Steuerung, ohne Rollenbindungen oder Clusterrollenbindungen einrichten zu müssen.

Nächste Schritte