Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Artikel wird beschrieben, wie Azure Kubernetes Service (AKS) entscheidet, was ein authentifizierter Aufrufer für die Kubernetes-API tun darf. Es behandelt die beiden von AKS unterstützten Autorisierungsmodelle sowie die fein abgestimmte benutzerdefinierte Ressourcensteuerung mit Azure ABAC-Bedingungen.
Informationen dazu, wie AKS Anrufer an erster Stelle authentifiziert , finden Sie unter Clusterauthentifizierungskonzepte.
Eine Übersicht über alle vier AKS-Identitätsszenarien finden Sie unter Zugriffs- und Identitätsoptionen für AKS.
Autorisieren der Kubernetes-API
Nachdem ein Anrufer authentifiziert wurde, wertet AKS aus, ob der Anrufer berechtigt ist, die angeforderte Aktion auszuführen. AKS unterstützt zwei Autorisierungsmodelle für die Kubernetes-API:
- Kubernetes rollenbasierte Zugriffssteuerung (RBAC). Das systemeigene Kubernetes-Autorisierungsmodell. Berechtigungen werden als
RoleundClusterRoleObjekte definiert und Subjekten überRoleBindingundClusterRoleBindingObjekte, die in jedem Cluster gespeichert sind, gewährt. - Microsoft Entra ID-Autorisierung. Ein AKS-Autorisierungswebhook, der Autorisierungsentscheidungen an Microsoft Entra ID delegiert. Berechtigungen werden als Azure-Rollenzuweisungen für Entra-ID-Identitäten erteilt und können optional mit Azure ABAC-Bedingungen optimiert werden.
Sie können beide Modelle auf demselben Cluster verwenden. Wir empfehlen die Microsoft Entra ID-Autorisierung als Standard und reservieren Kubernetes RBAC für differenzierte Intraclusterberechtigungen. Im restlichen Abschnitt wird erläutert, warum und wann sie verwendet werden sollen.
Kubernetes RBAC
Kubernetes RBAC ist das upstream-Kubernetes-Autorisierungsmodell. Sie erstellen Role- oder ClusterRole-Objekte, die Verben (z. B. get, list, create) auf Ressourcen (z. B. pods, deployments) erteilen und binden diese mithilfe von RoleBinding- oder ClusterRoleBinding-Objekten an Subjekte (Benutzer, Gruppen oder Dienstkonten). Der integrierte RBAC-Autorisierer des Kubernetes-API-Servers wertet diese Bindungen bei jeder Anfrage aus.
Verwenden Sie kubernetes RBAC, wenn Sie möchten:
- Feinkörnige, intraclusterbasierte Zugriffssteuerung pro Namespace, die als Kubernetes-Manifeste zusammen mit den von ihnen geschützten Workloads erstellt wurde.
- GitOps-verwaltete Autorisierung, die sich in derselben Wahrheitsquelle wie Ihre Anwendungskonfiguration befindet.
- Berechtigungen für Dienstkonten innerhalb des Clusters, die Workloads zum Aufrufen der Kubernetes-API verwenden.
Kubernetes-RBAC-Berechtigungen sind auf einen einzelnen Cluster beschränkt. Um dieselbe Richtlinie auf viele Cluster anzuwenden, müssen Sie die Manifeste auf jeden Cluster anwenden (in der Regel über GitOps). Verwenden Sie Microsoft Entra-Benutzer und -Gruppen als Themen in Kubernetes RoleBinding und ClusterRoleBinding Objekten, damit menschliche Identitäten immer noch aus Ihrem zentralen Verzeichnis stammen.
Hintergrundinformationen zum Kubernetes RBAC-Modell finden Sie in der Upstream-Dokumentation zu Kubernetes RBAC. Informationen zum Einrichten in AKS finden Sie unter Verwenden von Kubernetes RBAC mit Microsoft Entra-Integration.
Microsoft Entra ID-Autorisierung für die Kubernetes-API
Mit der Entra-ID-Autorisierung stellt AKS einen Autorisierungswebhook bereit, der Kubernetes-API-Autorisierungsentscheidungen an Microsoft Entra ID delegiert. Wenn eine Anforderung den API-Server erreicht, ruft der Webhook die Entra-ID-API checkaccess auf, um die Azure-Rollenzuweisungen des Aufrufers (und alle angefügten ABAC-Bedingungen) auszuwerten und eine Zulassungs- oder Ablehnungsentscheidung zurückgibt.
Die Entra-ID-Autorisierung bietet Ihnen die folgenden Vorteile beim Verwalten von Kubernetes RBAC-Manifesten auf jedem Cluster:
- Einzelne Identitätsebene. Die gleichen Microsoft Entra-Benutzer, Gruppen und Dienstprinzipale, die den Zugriff auf Ihre Azure-Ressourcen steuern, steuern auch den Zugriff auf Ihre Kubernetes-API. Es gibt kein separates Benutzerverzeichnis zum Bereitstellen oder Wechseln.
- Einmal zuweisen, viele Cluster steuern. Azure-Rollenzuweisungen können im Abonnement-, Verwaltungsgruppen- oder Ressourcengruppenbereich vorgenommen werden. Eine einzelne Rollenzuweisung in einem Ressourcengruppenbereich gewährt zugriff auf jeden aktuellen und zukünftigen AKS-Cluster in dieser Ressourcengruppe. Mit Kubernetes RBAC müssen Sie Manifeste auf jeden Cluster einzeln anwenden.
- Bedingter Zugriff und Privileged Identity Management (PIM). Der Clusterzugriff erbt automatisch die vorhandenen Richtlinien für den bedingten Zugriff Ihrer Organisation (z. B. Mehrfaktor-Authentifizierung oder standortbasierte Einschränkungen) und kann über PIM just-in-time erweitert werden.
- Zentralisierte Überwachung. Jede Änderung der Rollenzuweisung wird im Azure-Aktivitätsprotokoll zusammen mit anderen Azure-Ressourcenänderungen aufgezeichnet, sodass Sie über einen Überwachungspfad für die Clusterzugriffsgovernance verfügen.
- Feinkörnige benutzerdefinierte Ressourceneinschränkungen. Mit ABAC-Bedingungen können Sie den Zugriff auf bestimmte benutzerdefinierte Ressourcengruppen und -typen einschränken, ohne pro Cluster Kubernetes-RBAC-Manifeste zu schreiben.
AKS stellt die folgenden integrierten Rollen für die Entra-ID-Autorisierung bereit:
| Role | Beschreibung |
|---|---|
| RBAC-Leser von Azure Kubernetes Service | Schreibgeschützter Zugriff auf die meisten Objekte in einem Namespace. Ermöglicht nicht das Anzeigen von Rollen, Rollenbindungen oder Secrets. |
| Azure Kubernetes Service RBAC-Verfasser | Lese-/Schreibzugriff auf die meisten Objekte in einem Namespace. Ermöglicht das Anzeigen oder Ändern von Rollen oder Rollenbindungen nicht. |
| RBAC-Administrator von Azure Kubernetes Service | Lese-/Schreibzugriff auf die meisten Ressourcen in einem Namespace sowie die Möglichkeit zum Erstellen von Rollen und Rollenbindungen innerhalb des Namespaces. |
| RBAC-Clusteradministrator von Azure Kubernetes Service | Vollzugriff auf jede Ressource im Cluster über alle Namespaces hinweg. |
Für benutzerdefinierte Berechtigungsmuster können Sie benutzerdefinierte Rollendefinitionen erstellen, die auf bestimmte Kubernetes-API-Gruppen abzielen, indem Sie die Datenaktionen des Microsoft.ContainerService Ressourcenanbieters verwenden. Schrittweises Einrichten und benutzerdefinierte Rollenbeispiele finden Sie unter Verwenden der Microsoft Entra ID-Autorisierung für die Kubernetes-API.
Vergleich
| Fähigkeit | Kubernetes RBAC | Entra-ID-Autorisierung |
|---|---|---|
| Identitätsquelle | Kubernetes-Benutzer, Gruppen, Dienstkonten | Microsoft Entra-ID-Identitäten |
| Umfang eines einzelnen Stipendiums | Ein Cluster | Ressource, Ressourcengruppe, Abonnement oder Verwaltungsgruppe |
| Multicluster-Governance | Anwenden von Manifesten auf jeden Cluster (in der Regel GitOps) | Eine Rollenzuweisung in einem höheren Bereich steuert viele Cluster |
| Bedingter Zugriff / PIM | Nicht unterstützt | Geerbt von Entra ID |
| Überwachungspfad | Clusterüberwachungsprotokoll | Azure-Aktivitätsprotokoll |
| Filtern des Zugriffs nach CRD-Gruppe oder -Art | Erstellen von pro CRD-Objekten Role |
Verwenden von ABAC-Bedingungsattributen für die Rollenzuweisung |
Einschränken des benutzerdefinierten Ressourcenzugriffs mit ABAC-Bedingungen
Wenn Sie einen umfassenden Lesezugriff über die Microsoft Entra ID-Autorisierung gewähren, aber einschränken möchten, welche benutzerdefinierten Ressourcen (CRDs) der Zugewiesene lesen kann, fügen Sie eine Azure ABAC-Bedingung an die Rollenzuweisung an.
Ohne ABAC-Bedingungen erfordert die Gewährung von Lesevorgängen für benutzerdefinierte Ressourcen einen Wildcard-Typ wie Microsoft.ContainerService/managedClusters/*/read, der alle CRD innerhalb des Geltungsbereichs auf jedem Cluster abdeckt. Mit ABAC können Sie eine Bedingung anfügen, die den Zugriff auf bestimmte CRD-Gruppen und -Typen beschränkt, z. B. templates.gatekeeper.sh zulassen, während kyverno.io blockiert wird, ohne pro Cluster Kubernetes RBAC-Manifeste zu schreiben.
Für die Kubernetes-API-Autorisierung können Sie den Zugriff auf benutzerdefinierte Ressourcen anhand der API-Gruppe und art mithilfe der folgenden Attribute filtern:
Microsoft.ContainerService/managedClusters/customResources:groupMicrosoft.ContainerService/managedClusters/customResources:kind
Hintergrundinformationen zu Azure ABAC finden Sie unter Was sind Azure-Rollenzuweisungsbedingungen?. Eine schrittweise Einrichtung finden Sie unter "Einschränken des benutzerdefinierten Ressourcenzugriffs mithilfe von ABAC-Bedingungen".