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.
Dieser Artikel enthält eine Übersicht über vom System zugewiesene und vom Benutzer zugewiesene verwaltete Identitäten in AKS, einschließlich ihrer Funktionsweise, Rollenzuweisungen und AKS-spezifischen Features für verwaltete Identitäten.
Weitere Informationen zu verwalteten Identitäten in Azure finden Sie in der Dokumentation zu verwalteten Identitäten für Azure-Ressourcen.
Hinweis
Verwaltete Identitäten decken das Cluster-zu-Azure-Identitätsszenario in AKS ab – wie der AKS-Cluster auf Azure agiert, um Ressourcen in Ihrem Auftrag zu verwalten. Für die anderen Identitätsszenarien (Authentifizierung und Autorisierung der Kontrollebene sowie Pod-zu-Azure-Workload-Identität) siehe Zugriffs- und Identitätsoptionen für AKS.
Hinweis
Die vom System zugewiesenen und vom Benutzer zugewiesenen Identitätstypen unterscheiden sich von einer Workload-Identität, die für die Verwendung durch eine Anwendung vorgesehen ist, die auf einem Pod ausgeführt wird.
Autorisierungsfluss mit von AKS verwalteter Identität
AKS-Cluster verwenden vom System zugewiesene oder vom Benutzer zugewiesene verwaltete Identitäten , um Token von Microsoft Entra anzufordern. Diese Token helfen beim Autorisieren des Zugriffs auf andere Ressourcen, die in Azure ausgeführt werden. Sie weisen der verwalteten Identität eine rollebasierte Azure-Zugriffssteuerungsrolle (Azure RBAC) zu, um ihm Berechtigungen für eine bestimmte Azure-Ressource zu erteilen. Sie können z. B. Berechtigungen für eine verwaltete Identität erteilen, um auf geheime Schlüssel in einem Azure-Schlüsseltresor zuzugreifen, der vom Cluster verwendet werden kann.
Verhalten der verwalteten Identität in AKS
Wenn Sie einen AKS-Cluster bereitstellen, wird standardmäßig eine vom System zugewiesene verwaltete Identität erstellt. Sie können den Cluster auch mit einer vom Benutzer zugewiesenen verwalteten Identität erstellen oder einen vorhandenen Cluster auf einen anderen Typ verwalteter Identität aktualisieren.
Wenn Ihr Cluster bereits eine verwaltete Identität verwendet und Sie den Identitätstyp ändern (z. B. von system-zugewiesen zu benutzer-zugewiesen), gibt es eine Verzögerung, während die Komponenten der Steuerungsebene auf die neue Identität umschalten. Steuerungsebenenkomponenten verwenden weiterhin die alte Identität, bis das Token der alten Identität abläuft. Nachdem das Token aktualisiert wurde, wechseln sie zur neuen Identität. Dieser Prozess kann mehrere Stunden dauern.
Hinweis
Sie können auch einen Cluster mit einem Anwendungsdienstprinzipal und nicht mit einer verwalteten Identität erstellen. Verwenden Sie jedoch eine verwaltete Identität über einen Anwendungsdienstprinzipal, um Sicherheit und Benutzerfreundlichkeit zu gewährleisten. Wenn Sie über einen vorhandenen Cluster verfügen, der einen Anwendungsdienstprinzipal verwendet, können Sie ihn aktualisieren, um eine verwaltete Identität zu verwenden.
AKS-Identitäts- und Anmeldeinformationsverwaltung
Die Azure-Plattform verwaltet sowohl vom System zugewiesene als auch vom Benutzer zugewiesene verwaltete Identitäten und ihre Anmeldeinformationen, sodass Sie den Zugriff von Ihren Anwendungen autorisieren können, ohne geheime Schlüssel bereitstellen oder drehen zu müssen.
Vom System zugewiesene verwaltete Identität
In der folgenden Tabelle sind die wichtigsten Merkmale einer vom System zugewiesenen verwalteten Identität in AKS zusammengefasst:
| Wie es erstellt wird | Lebenszyklusverhalten | Gemeinsame Nutzung von Ressourcen | Häufige Anwendungsfälle in AKS |
|---|---|---|---|
| Erstellt als Teil einer Azure-Ressource, z. B. eines AKS-Clusters | An den Lebenszyklus der übergeordneten Ressource gebunden, sodass sie gelöscht wird, wenn die übergeordnete Ressource gelöscht wird. | Kann nur einer einzelnen Ressource zugeordnet werden | • Workloads, die in einer einzelnen Azure-Ressource enthalten sind • Workloads, die unabhängige Identitäten erfordern |
Vom Benutzer zugewiesene verwaltete Identität
In der folgenden Tabelle sind die wichtigsten Merkmale einer vom Benutzer zugewiesenen verwalteten Identität in AKS zusammengefasst:
| Wie es erstellt wird | Lebenszyklusverhalten | Gemeinsame Nutzung von Ressourcen | Häufige Anwendungsfälle in AKS |
|---|---|---|---|
| Erstellt als eigenständige Azure-Ressource und muss vor der Clustererstellung vorhanden sein. | Unabhängig vom Lebenszyklus einer bestimmten Ressource ist daher ein manueller Löschvorgang erforderlich, wenn er nicht mehr benötigt wird. | Kann für mehrere Ressourcen freigegeben werden | • Arbeitslasten, die auf mehreren Ressourcen ausgeführt werden und eine einzelne Identität teilen können • Workloads, die eine Vorautorisierung für eine sichere Ressource im Rahmen eines Bereitstellungsprozesses erfordern • Workloads, bei denen Ressourcen häufig wiederverwendet werden, aber konsistente Berechtigungen benötigen |
Vorab erstellte verwaltete Kubelet-Identität
Eine vordefinierte kubelet verwaltete Identität ist eine optionale vom Benutzer zugewiesene Identität, die Kubelet für den Zugriff auf andere Ressourcen in Azure verwenden kann. Dieses Feature ermöglicht Szenarien wie die Verbindung mit der Azure Container Registry (ACR) während der Clustererstellung. Wenn Sie keine vom Benutzer zugewiesene verwaltete Identität für Kubelet angeben, erstellt AKS eine vom Benutzer zugewiesene Kubelet-Identität in der Knotenressourcengruppe. Weisen Sie für eine vom Benutzer zugewiesene Kubelet-Identität außerhalb der Ressourcengruppe des Standardarbeitsknotens die Rolle "Managed Identity Operator " der Steuerungsebene des Clusters zu, unabhängig davon, ob vom System zugewiesen oder vom Benutzer zugewiesen, mit der Rollenzuweisung, die auf die Kubelet-Identität beschränkt ist.
Rollenzuweisungen für verwaltete Identitäten in AKS
Sie können einer verwalteten Identität eine Azure RBAC-Rolle zuweisen, um den Clusterberechtigungen für eine andere Azure-Ressource zu erteilen. Azure RBAC unterstützt integrierte und benutzerdefinierte Rollendefinitionen, die Berechtigungsebenen angeben. Informationen zum Zuweisen einer Rolle finden Sie unter "Schritte zum Zuweisen einer Azure-Rolle".
Wenn Sie einer verwalteten Identität eine Azure RBAC-Rolle zuweisen, müssen Sie den Bereich für die Rolle definieren. Im Allgemeinen empfiehlt es sich, den Umfang einer Rolle auf die mindestberechtigungen zu beschränken, die von der verwalteten Identität benötigt werden. Weitere Informationen zur Festlegung des Geltungsbereichs von Azure RBAC-Rollen finden Sie unter Grundlegendes zum Geltungsbereich von Azure RBAC.
Zuweisungen der Rolle Operator für verwaltete Identität auf Steuerungsebene
Wenn Sie Ihr eigenes VNet, angefügte Azure-Datenträger, eine statische IP-Adresse, eine Routentabelle oder eine benutzerzugewiesene Kubelet-Identität erstellen und verwenden, wobei sich die Ressourcen außerhalb der Ressourcengruppe des Arbeitsknotens befinden, fügt die Azure CLI automatisch die Rollenzuweisung hinzu. Wenn Sie eine ARM-Vorlage oder eine andere Methode verwenden, verwenden Sie die Prinzipal-ID der verwalteten Identität, um eine Rollenzuweisung auszuführen.
Wenn Sie die Azure CLI nicht verwenden, aber Ihr eigenes VNet verwenden, Azure Datenträger, statische IP-Adresse, Routentabelle oder vom Benutzer zugewiesene Kubelet-Identität, bei der sich diese Ressourcen außerhalb der Ressourcengruppe des Arbeitsknotens befinden, empfehlen wir die Verwendung einer vom Benutzer zugewiesenen verwalteten Identität für die Steuerungsebene und manuelles Ausführen der erforderlichen Rollenzuweisung mithilfe der Prinzipal-ID dieser Identität.
Wenn die Steuerungsebene eine vom System zugewiesene verwaltete Identität verwendet, erstellen Sie die Identität gleichzeitig mit dem Cluster, sodass Sie die Rollenzuweisung erst nach der Clustererstellung ausführen können. Nachdem Sie den Cluster erstellt haben, rufen Sie die Prinzipal-ID der Identität ab, und fügen Sie die erforderliche Rollenzuweisung hinzu.
Zusammenfassung der von AKS verwendeten verwalteten Identitäten
AKS verwendet mehrere verwaltete Identitäten für integrierte Dienste und Add-Ons. In der folgenden Tabelle sind die verwalteten Identitäten zusammengefasst, die von AKS verwendet werden, deren Anwendungsfälle, Standardberechtigungen und ob Sie Ihre eigene Identität mitbringen können:
| Identität | Name | Anwendungsfall | Standardberechtigungen | Eigene Identität mitbringen |
|---|---|---|---|---|
| Steuerebene | AKS-Cluster-Name | Wird von Komponenten der AKS-Steuerungsebene verwendet, um Clusterressourcen wie Lastenausgleichsmodule für eingehenden Datenverkehr und von AKS verwaltete öffentliche IP-Adressen, die Autoskalierung im Cluster sowie CSI-Treiber für Datenträger, Dateien und Blobs in Azure zu verwalten. | Rolle „Mitwirkender“ für Knotenressourcengruppe | Unterstützt |
| Kubelet | AKS-Cluster name-agentpool | Authentifizierung mit Azure Container Registry (ACR) | Nichts; erfordert eine ACR-Pullrolle basierend auf dem Registrierungsberechtigungsmodus | Unterstützt |
| Add-On | AzureNPM | Keine Identität erforderlich | N/A | Nicht unterstützt |
| Add-On | AzureCNI-Netzwerküberwachung | Keine Identität erforderlich | N/A | Nicht unterstützt |
| Add-On | azure-policy (Gatekeeper) | Keine Identität erforderlich | N/A | Nicht unterstützt |
| Add-On | Calico | Keine Identität erforderlich | N/A | Nicht unterstützt |
| Add-On | Application-Routing (NGINX) | Verwaltet Azure DNS- und Azure Key Vault-Zertifikate | Key Vault Rolle "Zertifikatbenutzer" für Key Vault, Rolle "DNS-Zonenmitwirkender" für DNS-Zonen | Nicht unterstützt |
| Add-On | ingressapplicationgateway-AKS-Clustername | Verwaltet erforderliche Netzwerkressourcen für den Application Gateway-Eingangscontroller (AGIC) | Hängt von der Bereitstellungstopologie ab | Nicht unterstützt |
| Add-On | Containereinblicke | Sammelt Containerprotokolle und Bestandsdaten und sendet sie an einen Log Analytics Arbeitsbereich. | Verwendet die vom Cluster verwaltete Identität; keine Überwachungsmetriken Publisher Rolle erforderlich | Verwendet die Clusteridentität |
| Add-On | Virtual-Node (ACIConnector) | Verwaltet erforderliche Netzwerkressourcen für Azure-Containerinstanzen (ACI) | Rolle „Mitwirkender“ für Knotenressourcengruppe | Nicht unterstützt |
| Add-On | Cost-Analysis-Identity | Erfasst Azure Resource Manager Bezeichner für die Kostenzuordnung | Lesezugriff auf die Knotenressourcengruppe | Nicht unterstützt |
| Workload-Identität | Vom Benutzer konfigurierte Microsoft Entra-Identität | Ermöglicht Anwendungen den sicheren Zugriff auf Cloudressourcen mit der Microsoft Entra Workload-ID | Hängt von den Ressourcen ab, auf die die Workload zugreift | Erforderlich |
Hinweis
Für die Kubelet-Identität ist eine ACR-Pullrolle erforderlich. Verwenden Sie für Registrierungen im RBAC-Registrierungsberechtigungsmodus die AcrPull Rolle. Verwenden Sie die Container Registry Repository Reader Rolle für Registrierungen im RBAC-Registrierungsmodus + ABAC-Repositoryberechtigungen. Fügen Sie die Container Registry Repository Catalog Lister Rolle nur hinzu, wenn die Identität Repositorys auflisten muss. Weitere Informationen finden Sie unter zugeordneter AKS-Knotenidentität.
Die Zeile "Anwendungsrouting" beschreibt die NGINX-basierte Oberfläche. Microsoft bietet Unterstützung für kritische Sicherheitspatches für Anwendungsrouting-Add-On-NGINX Ingress-Ressourcen bis November 2026. Migrieren Sie bis November 2026 zur Anwendungsroutinggateway-API oder einer anderen unterstützten Implementierung. Die Gateway-API-DNS- und TLS-Integration verwendet Microsoft Entra Workload ID anstelle der verwalteten Identität des Add-Ons. Erstellen Sie für die Gateway-API eine vom Benutzer zugewiesene verwaltete Identität, gewähren Sie ihm die erforderlichen Azure DNS und Azure Key Vault Rollen, und erstellen Sie Verbundidentitätsanmeldeinformationen für die Kubernetes-Dienstkonten.
AGIC-Berechtigungen hängen davon ab, wie Sie Das Anwendungsgateway bereitstellen. Wenn das Add-On ein neues Anwendungsgateway erstellt, weist es in der Regel automatisch die erforderlichen Berechtigungen zu. Wenn Sie Berechtigungen manuell zuweisen müssen, erteilen Sie dem Add-On-Identitätsnetzwerkmitwirkenden im Anwendungsgateway-Subnetz. Gewähren Sie für ein vorhandenes Anwendungsgateway in einer anderen Ressourcengruppe als dem AKS-Cluster den Add-On-Identitätsnetzwerkmitwirkenden und -Leser in der Ressourcengruppe "Application Gateway". Weitere Informationen finden Sie unter Enable AGIC with a new Application Gateway und enable AGIC with an existing Application Gateway.
Container Insights verwendet standardmäßig die verwaltete Identitätsauthentifizierung und verwendet die clusterverwaltete Identität, um Daten an Azure Monitor zu senden. Legacyauthentifizierung, die die Überwachungsmetriken Publisher Rolle erfordert, wird am 30. September 2026 eingestellt. Container Insights sammelt Protokolle und Bestandsdaten in einem Log Analytics Arbeitsbereich; Azure Monitor verwalteter Dienst für Prometheus sammelt prometheus-Metriken separat in einem Azure Monitor Arbeitsbereich. Weitere Informationen finden Sie unter Container Insights-Authentifizierung.
AKS erstellt den cost-analysis-identity mit Lesezugriff auf die Knotenressourcengruppe und weist ihn den Knotenpools des Clusters zu, wenn Sie die Kostenanalyse aktivieren. Sie können keine andere Identität für das Add-On bereitstellen. Weitere Informationen finden Sie unter Aktivieren der AKS-Kostenanalyse.
Microsoft Entra Workload ID ist ein Pod-to-Azure-Identitätsmodell, kein Cluster oder add-On verwaltete Identität. Sie konfigurieren die Microsoft Entra Identität, die von jeder Workload verwendet wird, kommentieren Sie das Kubernetes-Dienstkonto mit der Client-ID der Identität, und erstellen Sie eine Verbundidentitäts-Anmeldeinformationen. Weitere Informationen finden Sie unter Bereitstellen und Konfigurieren von Microsoft Entra Workload ID.
Nächster Schritt
Aktivieren Sie ihren gewünschten verwalteten Identitätstyp in einem neuen oder vorhandenen AKS-Cluster mithilfe der folgenden Leitfäden: