Workload-Identität und Zugriff in EKS und AKS

Amazon Elastic Kubernetes Service (EKS) und Azure Kubernetes Service (AKS) sind verwaltete Kubernetes-Plattformen, die eine ähnliche grundlegende Erfahrung bieten. Der Cloudanbieter betreibt die Kubernetes-Kontrollebene, während Sie Kubernetes-Workloads, Richtlinien, Namespaces, Dienstkonten und Anwendungen bereitstellen und verwalten. Aus Sicht der Identitäts- und Zugriffsverwaltung implementieren die beiden Plattformen jedoch Sicherheitsarchitekturen, die auf ihren jeweiligen Cloud-Ökosystemen basieren.

EKS basiert auf AWS Identity and Access Management (IAM), IAM-Rollen, temporären Anmeldeinformationen, Kubernetes RBAC, EKS-Zugriffseinträgen und Workload-Identitätsmechanismen wie EKS Pod Identity and IAM Roles for Service Accounts (IRSA). AKS basiert auf Microsoft Entra ID, Azure RBAC, Kubernetes RBAC, Azure verwalteten Identitäten und Microsoft Entra Workload ID. In beiden Plattformen ist das zentrale Architekturziel identisch: Vermeiden Sie die Verwendung von langlebigen Anmeldeinformationen in Anwendungen und richten Sie stattdessen eine kontrollierte Beziehung zwischen einer Kubernetes-Identität und einer Cloudidentität ein.

In diesem Artikel wird beschrieben, wie EKS und AKS Identitäten bereitstellen, um Kubernetes-Workloads für den Zugriff auf Cloudplattformdienste zu ermöglichen. Einen detaillierten Vergleich von AMAZON Web Services (AWS) IAM und Microsoft Entra ID finden Sie in den folgenden Ressourcen:

Hinweis

Dieser Artikel ist Teil einer Reihe von Artikeln , die Fachleuten helfen, die mit Amazon EKS vertraut sind, Azure Kubernetes Service (AKS) zu verstehen.

Als verwaltete Kubernetes-Plattformen lösen Amazon EKS und Azure Kubernetes Service dasselbe Problem: Aktivieren eines Clusters, seiner Knoten und seiner Workloads für den Zugriff auf Cloudressourcen ohne verwendung von langlebigen Anmeldeinformationen. Aber sie lösen es mit verschiedenen Architekturen. EKS leitet fast alles durch ein einzelnes System, AWS IAM. AKS teilt das Problem auf zwei Systeme auf: verwaltete Identitäten für die Clusterkommunikation mit Azure und Microsoft Entra ID, um zu konfigurieren, wer mit dem Cluster kommunizieren kann und was sie tun können. Andernfalls funktionieren beide Plattformen in einem ähnlichen Muster.

Amazon EKS-Identitäts- und Zugriffsoptionen

Amazon EKS verwendet AWS IAM für cloudorientierte Identitäts- und Kubernetes-API-Authentifizierung, ersetzt jedoch nicht Kubernetes-native Identitäten. Kubernetes-Dienstkonten identifizieren Workloads innerhalb des Clusters, und Kubernetes RBAC- oder EKS-Zugriffsrichtlinien autorisieren den Zugriff auf Kubernetes-Ressourcen.

Cluster- und Knotenidentität

Jeder EKS-Cluster erfordert eine CLUSTER-IAM-Rolle, die von der Kontrollebene zum Verwalten von Clusterressourcen verwendet wird. EC2-Knoten verwenden eine separate Knoten-IAM-Rolle, sodass das Kubelet die Knoten registrieren, Container-Images abrufen und erforderliche AWS-APIs aufrufen kann. Diese Rollen entsprechen den verwalteten Identitäten für die AKS-Steuerungsebene und das Kubelet, die später in diesem Artikel beschrieben werden. Weitere Informationen finden Sie unter IAM-Rolle des Amazon-EKS-Clusters und IAM-Rolle des Amazon-EKS-Knotens.

Pod-Identität

Amazon EKS bietet zwei Mechanismen, mit denen einzelne Pods gezielten Zugriff auf AWS-Dienste erhalten können, ohne die Knotenrolle für alle Pods auf einem Knoten zu erweitern.

IRSA war der ursprüngliche Mechanismus. Es erfordert, dass der Cluster einen IAM OIDC-Identitätsanbieter ausführt, der an den eigenen OIDC-Endpunkt des Clusters (OpenID Connect) gebunden ist. Die Vertrauensrichtlinie einer IAM-Rolle wird so geschrieben, dass nur Token akzeptiert werden, die an einen bestimmten Kubernetes-Namespace und ein Dienstkonto ausgegeben wurden, und das Kubernetes-Dienstkonto wird mit dem Amazon Resource Name (ARN) der Rolle kommentiert. Wenn ein Pod mit diesem Dienstkonto eine AWS-API aufruft, tauscht das AWS SDK das projizierte Dienstkontotoken des Pods für temporäre AWS-Anmeldeinformationen über AWS Security Token Service (STS) aus.

Amazon EKS Pod Identity ist ein neuerer, einfacherer Mechanismus, der die OIDC-Abhängigkeit entfernt. Anstelle einer OIDC-Vertrauensstellung pro Cluster ordnet eine Pod-Identity-Zuordnung über die EKS-API direkt eine IAM-Rolle einem Kubernetes-Dienstkonto zu. Die Vertrauensrichtlinie der Rolle erfordert nur einen clusterunabhängigen Prinzipal, pods.eks.amazonaws.com. Anmeldeinformationen werden vom EKS Auth-Dienst ausgegeben und pro Knoten zwischengespeichert, anstatt unabhängig vom SDK-Aufruf jedes Pods angefordert zu werden, das AWS als skalierbares und tragbares Muster positioniert: Dieselbe IAM-Rolle kann in mehreren Clustern wiederverwendet werden, ohne eine Verbundvertrauensbeziehung für jede neu zu erstellen. Pod Identity unterstützt Linux EC2-Knoten und EKS-Hybridknoten. Es ist nicht für Fargate, Windows Knoten, nicht-EKS selbstverwaltete Kubernetes-Cluster, AWS Outposts oder EKS Anywhere verfügbar. Weitere Informationen finden Sie unter EKS Pod Identity.

Beide Mechanismen stellen kurzlebige Anmeldeinformationen pro Workload bereit, ohne statische AWS-Zugriffstasten in Pods zu speichern. Die IAM-Rolle bestimmt die Berechtigungen einer Workload.

Clusterzugriff, Authentifizierung und Autorisierung

Menschliche Benutzer, IAM-Rollen, die von CI/CD-Pipelines verwendet werden, und kontoübergreifende Identitäten authentifizieren sich gegenüber der Kubernetes-API alle als IAM-Identitäten. EKS-Zugriffseinträge ordnen diese Prinzipale Kubernetes-Berechtigungen über die EKS-API zu. Sie bieten den Vergleichspunkt für den über Microsoft Entra ID verwalteten AKS-Zugriff und Azure RBAC. Vorhandene EKS-Cluster verwenden stattdessen die veraltete aws-auth ConfigMap, deren Einträge nicht automatisch migriert werden, wenn Zugriffseinträge aktiviert sind. Weitere Informationen finden Sie unter Amazon EKS-Zugriffseinträge.

Nach der Authentifizierung kann EKS einen Prinzipal über eine EKS-Zugriffsrichtlinie, Kubernetes-RBAC-Gruppen oder beides autorisieren. Zugriffsrichtlinien werden über die EKS-API verwaltet, während Kubernetes-RBAC-Berechtigungen Rollen-, ClusterRole-, RoleBinding- und ClusterRoleBinding-Objekte in jedem Cluster verwenden. Diese Auswahl entspricht der AKS-Unterscheidung zwischen Azure RBAC für Kubernetes-Autorisierung und Kubernetes RBAC. Weitere Informationen finden Sie unter "Informationen zur Funktionsweise der Zugriffssteuerung in Amazon EKS".

Auditing

Jeder IAM- und EKS-API-Aufruf, einschließlich Clustererstellung, Rollenannahme und Zugriffseingabeänderungen, wird von AWS CloudTrail erfasst, der erfasst, wer welche Aktion ausgeführt hat und wann. Kubernetes-API-Aktivitäten innerhalb des Clusters werden nur erfasst, wenn Sie die EKS-Überwachungsprotokollierung auf Steuerebene aktivieren. EKS sendet aktivierte Überwachungsprotokolle an Amazon CloudWatch Logs. Weitere Informationen finden Sie unter Control-Plane-Protokolle an CloudWatch Logs senden.

AKS-Identitäts- und Zugriffsoptionen

AKS teilt die gleiche Gruppe von Bedenken in zwei Systeme auf: Azure verwaltete Identitäten, die steuern, wie der Cluster und seine Workloads auf Azure Ressourcen reagieren, und Microsoft Entra ID, die steuert, wer die Kubernetes-API aufrufen kann und was sie nach der Authentifizierung tun dürfen. Weitere Informationen finden Sie unter "Konzepte: Zugriff und Identität in AKS".

Clusteridentität

Jeder AKS-Cluster wird standardmäßig mit einer vom System zugewiesenen verwalteten Identität erstellt. Diese Identität wird zusammen mit dem Cluster erstellt und mit ihm gelöscht, erfordert kein gespeichertes Geheimnis und benötigt keine manuelle Rotation von Anmeldeinformationen. Die Steuerungsebene verwendet diese Identität mit Mitwirkender-Rechten, die auf die Knotenressourcengruppe des Clusters beschränkt sind, um im Auftrag des Clusters Load Balancer, verwaltete Datenträger und Speicher-CSI-Treiber zu verwalten. Eine separate Kubelet-Identität authentifiziert die Knoten des Clusters beim Abrufen von Bildern auf Azure Container Registry. Weitere Informationen finden Sie unter Übersicht über verwaltete Identitäten in AKS.

Cluster können anstelle der vom System zugewiesenen Identität eine vom Benutzer zugewiesene verwaltete Identität verwenden, wenn die Identität unabhängig von einem einzelnen Cluster einen Lebenszyklus benötigt oder wenn sie über mehrere Azure Ressourcen hinweg freigegeben werden muss. Die kubelet-Identität kann insbesondere auch vorab erstellt werden, wodurch ein Administrator ihre Berechtigungen für die Container Registry präzise festlegen kann, noch bevor der Cluster erstellt wird, unabhängig von der Control-Plane-Identität. Weitere Informationen finden Sie unter vom System zugewiesene verwaltete Identität, vom Benutzer zugewiesene verwaltete Identität und vorab erstellte verwaltete Kubelet-Identität.

Dienstprinzipale bleiben als Legacyalternative verfügbar, werden mit az ad sp create-for-rbac erstellt und AKS als Anwendungs-ID und Kennwort zur Verfügung gestellt, die auf den virtuellen Computern der Knoten gespeichert sind. Wir empfehlen verwaltete Identitäten gegenüber Dienstprinzipalen, da die Anmeldeinformationen von Dienstprinzipalen standardmäßig nach einem Jahr ablaufen und manuell rotiert werden müssen. Ein Cluster, das mit einer verwalteten Identität erstellt wurde, kann ebenfalls nicht wieder für die Verwendung eines Dienstprinzipals konfiguriert werden. Weitere Informationen finden Sie unter Verwenden eines Dienstprinzipals mit AKS.

Workload-Identität

Für den Zugriff auf Azure-Ressourcen auf Pod-Ebene verwendet AKS Microsoft Entra Workload ID, die, wie die IRSA von Amazon EKS, auf OIDC-Föderation basiert. Der OIDC-Aussteller des Clusters muss aktiviert sein, damit der Cluster ein Ermittlungsdokument veröffentlichen kann, das Microsoft Entra ID verwendet, um vom Cluster ausgestellte Token zu überprüfen. Sobald sie aktiviert ist, kann der OIDC-Aussteller nicht deaktiviert werden, und die Aktivierung auf einem vorhandenen Cluster führt zu einer kurzen Unterbrechung der Steuerungsebene. Eine Verbundidentitäts-Anmeldeinformation verknüpft dann eine Microsoft Entra verwaltete Identität (oder registrierte Anwendung) mit einem bestimmten Kubernetes-Namespace und einem Dienstkontobetreff. Das Dienstkonto wird mit der Client-ID der verwalteten Identität annotiert, und der Pod wird mit azure.workload.identity/use: "true" gekennzeichnet, wodurch ein mutierender Webhook ausgelöst wird, der das projizierte Dienstkontotoken einfügt. Zur Laufzeit muss die Anwendung eine unterstützte Version einer Azure Identity-Clientbibliothek oder der Microsoft Authentication Library (MSAL) (MSAL) verwenden, um dieses Token gegen ein Microsoft Entra-Zugriffstoken mit einer auf 24 Stunden begrenzten Gültigkeitsdauer auszutauschen, ohne eine Verbindungszeichenfolge, einen Zugriffsschlüssel oder ein Kennwort zu handhaben. Weitere Informationen finden Sie unter Übersicht über Microsoft Entra Workload ID und Verwenden des OIDC-Issuers.

Verwenden Sie für jede Workload eine separate verwaltete Identität, wenn dies praktisch ist. Legen Sie die Azure Rollenzuweisungen jeder Identität nur auf die Ressourcen und Aktionen fest, die von der Workload benötigt werden.

Jede vom Benutzer zugewiesene verwaltete Identität ist auf 20 Verbundidentitätsanmeldeinformationen beschränkt. Dieser Grenzwert kann Organisationen einschränken, die eine Identität über viele Cluster hinweg mit unterschiedlichen OIDC-Ausstellern teilen. Identitätsbindungen für AKS adressieren diesen Grenzwert mithilfe einer Verbundanmeldeinformation pro verwalteter Identität und Zuordnen mehrerer Cluster über separate Identitätsbindungen.

Das folgende Diagramm zeigt, wie ein Kubernetes-Cluster zu einem Sicherheitstokenherausgeber wird, der Token für Kubernetes-Dienstkonten ausgibt. Sie können diese Token so konfigurieren, dass sie von Microsoft Entra-Anwendungen als vertrauenswürdig eingestuft werden. Die Token können dann über die Azure Identity Services-SDKs oder die Microsoft-Authentifizierungsbibliothek für Microsoft Entra-Zugriffstoken ausgetauscht werden.

Diagramm mit einem vereinfachten Workflow für Microsoft Entra Workload ID in Azure.

Clusterauthentifizierung und -autorisierung

Benutzer und Automatisierung authentifizieren sich mithilfe von Microsoft Entra ID bei der AKS-Steuerungsebene. Benutzer und Gruppen werden anhand des Entra-Mandanten des Clusters überprüft, und Gruppenmitgliedschaftsänderungen werden ohne clusterseitige Neukonfiguration wirksam. Die Entra ID-Integration bringt Conditional Access, Multifaktor-Authentifizierung und Privileged Identity Management in den Geltungsbereich für den Clusterzugriff. Das Kubelogin-Client-Plug-In verarbeitet interaktive und Gerätecode-Anmeldeabläufe für kubectl. AKS unterstützt auch lokale Konten, ein integriertes Administratorzertifikat, das Microsoft Entra ID vollständig umgeht. Es wird empfohlen, lokale Konten in Produktionsclustern zu deaktivieren, da sie einen nicht auditierbaren Pfad um alle anderen konfigurierten Zugriffssteuerungen darstellen. Weitere Informationen finden Sie unter Clusterauthentifizierungskonzepte in AKS und Verwalten lokaler Konten.

AKS unterstützt Kubernetes RBAC und Azure RBAC für die Kubernetes-Autorisierung, und Sie können beide Modelle auf demselben Cluster verwenden. Verwenden Sie Azure RBAC als Standardeinstellung für zentral geregelten menschlichen Zugriff und autorisierung in mehreren Clustern. Verwenden Sie Kubernetes RBAC für Dienstkonten, gitOps-verwaltete Berechtigungen und präzisen Zugriff innerhalb eines Clusters oder Namespaces. Kubernetes RBAC verwendet die Objekte Role/RoleBinding und ClusterRole/ClusterRoleBinding, die je Cluster verwaltet werden. Azure attributbasierte Zugriffssteuerung (Azure ABAC) verwendet integrierte oder benutzerdefinierte Azure Rollen auf Cluster-, Ressourcengruppen-, Abonnement- oder Verwaltungsgruppenebene. Azure ABAC-Bedingungen sind nur in der Vorschau verfügbar, um den Zugriff auf bestimmte benutzerdefinierte Ressourcendefinitionsgruppen und -typen einzuschränken. Verwenden Sie dieses Vorschaufeature nicht für Produktionsworkloads. Weitere Informationen finden Sie unter Clusterautorisierungskonzepte in AKS und Verwenden Microsoft Entra ID Autorisierung für die Kubernetes-API.

Überwachung in AKS

Azure zeichnet identitätsbezogene Aktivitäten mithilfe von ergänzenden Protokollen auf. Das Azure Aktivitätsprotokoll erfasst Steuerungsebenen- und Identitätsvorgänge, z. B. Rollenzuweisungen und Änderungen der verwalteten Identität. Microsoft Entra ID Anmeldeprotokolle erfassen, wer sich beim Cluster authentifiziert, wann die Authentifizierung erfolgt und welche Richtlinien für bedingten Zugriff gelten. Kubernetes-API-Aktivität wird standardmäßig nicht erfasst. Erstellen Sie eine AKS-Diagnoseeinstellung und leiten Sie die Ressourcenprotokolle kube-audit oder kube-audit-admin an ein Ziel wie einen Log Analytics-Arbeitsbereich weiter. Weitere Informationen finden Sie unter "Überwachen Azure Kubernetes Service".

Vergleich der beiden Modelle

Auf konzeptioneller Ebene lösen die beiden Plattformen eine ähnliche Gruppe von Identitätsproblemen. IRSA und Microsoft Entra Workload ID beide den OIDC-Partnerverbund verwenden, während EKS Pod Identity stattdessen den EKS Auth-Dienst verwendet.

Sorge Amazon EKS Azure Kubernetes-Dienst
Cluster, der auf Cloudressourcen wirkt Cluster-IAM-Rolle Vom System zugewiesene oder vom Benutzer zugewiesene verwaltete Identität
Knoten, die Cloud-APIs aufrufen Node IAM-Rolle Verwaltete Kubelet-Identität
Zugriff auf Pod-Ebene ohne gespeicherte geheime Schlüssel IAM-Rollen für Dienstkonten (IRSA) oder EKS Pod Identity Microsoft Entra Workload ID
Verbundmechanismus Clusterspezifischer IAM-OIDC-Anbieter (IRSA) oder Vertrauensstellung für pods.eks.amazonaws.com (Pod Identity) AKS OIDC-Aussteller plus Verbundidentitäts-Anmeldeinformationen
Gemeinsame Nutzung einer Identität über Cluster hinweg Nativ mit Pod Identity, bei IRSA ist clusterweise eine Vertrauensstellung erforderlich Identitätsbindungen (Vorschau), um den Grenzwert von 20 Anmeldeinformationen zu umgehen
Menschliche und Automatisierungsauthentifizierung IAM-Prinzipale, über Zugriffseinträge oder die veraltete aws-auth ConfigMap Microsoft Entra ID, via kubelogin. Lokale Konten sind ebenfalls vorhanden, werden jedoch nicht empfohlen.
Autorisierung innerhalb des Clusters EKS-Zugriffsrichtlinien, Kubernetes RBAC oder beides Kubernetes RBAC oder Azure RBAC für Kubernetes-Autorisierung
Multicluster, zentral verwalteter Zugriff IAM Identity Center zentralisiert Mitarbeiteridentitäten, aber Zugriffseinträge müssen pro Cluster konfiguriert werden, in der Regel über Infrastruktur als Code Azure RBAC-Rollenzuweisungen oberhalb des Clusterbereichs
Just-in-Time-Privilegierter Zugriff Keine native Entsprechung Verwaltung privilegierter Identitäten
Steuerungsebene und Identitätsprüfprotokoll AWS CloudTrail Azure Aktivitätsprotokoll und Microsoft Entra Anmeldeprotokolle

Die Ähnlichkeiten sind erheblich. Beide Plattformen verwenden plattformverwaltete Identitäten, die statische Anmeldeinformationen und separate Clusterebene, Knotenebene und Pod-Level-Identität vermeiden. IRSA und Microsoft Entra Workload ID OIDC-Partnerverbund verwenden, während EKS Pod Identity den EKS-Authentifizierungsdienst verwendet. Beide Plattformen unterstützen Kubernetes RBAC neben cloud identity. AWS ersetzt die veraltete aws-auth ConfigMap durch Zugriffseinträge, während IRSA weiterhin zusammen mit Pod Identity unterstützt wird. Wir empfehlen verwaltete Identitäten und Workload-ID anstelle von Dienstprinzipalen und der veralteten podseitig verwalteten Identität

Die Plattformen organisieren die Identitätsverwaltung unterschiedlich. Amazon EKS belässt die Verantwortung für den Cluster, die Knoten, die Pods und die Personen, die den Cluster verwalten, bei AWS IAM. Diese Konfiguration bietet einer Organisation, die bereits mit IAM vertraut ist, eine konsistente Richtliniensprache und einen einheitlichen Werkzeugsatz über alle Ebenen hinweg. Es gibt jedoch keine integrierte Entsprechung mit bedingtem Zugriff oder Just-in-Time-Erhöhung für den Clusterzugriff. Azure Kubernetes Service trennt den Cloudressourcenzugriff durch verwaltete Identität von menschlichem und API-Zugriff über Microsoft Entra ID und bietet eine Wahl zwischen Kubernetes-nativer und Azure nativer Autorisierung. Diese Einrichtung erfordert Teams, ein anderes Identitätsmodell zu erlernen, bietet aber funktionen, die für Entra ID nativ sind, einschließlich bedingter Zugriff, Privileged Identity Management und zentralisierter Multicluster-RBAC.

Identität und Zugriff mit EKS Auto Mode und AKS Automatic

Beide Plattformen bieten eine vollständig verwaltete Clusterebene, die reduziert, wie viel Identitätskonfiguration ein Operator direkt ausführen muss, und beide Ebenen ändern die Identitätsstandardwerte auf ähnliche Weise.

EKS Auto Mode verlagert mehr Berechtigungen auf die Cluster-IAM-Rolle, sodass EKS Rechen-, Speicher-, Netzwerk- und Load-Balancing-Vorgänge automatisieren kann. Die Knoten-IAM-Rolle ist auf Vorgänge beschränkt, z. B. das Verknüpfen des Clusters, das Abrufen von Bildern und die Annahme von Pod Identity-Rollen. Der automatische Modus enthält auch den Pod Identity Agent. Weitere Informationen finden Sie unter Amazon EKS Auto Mode Cluster-IAM-Rolle und Amazon EKS Auto Mode Knoten-IAM-Rolle.

AKS Automatic verfolgt in Azure einen vergleichbaren Ansatz, geht jedoch weiter in Richtung der Vollständigen Entfernung von Konfigurationsoptionen, anstatt sie einzuschränken. In der folgenden Tabelle sind die Identitätsstandardwerte zusammengefasst, die zwischen AKS Automatic und Standard AKS geändert werden.

Identitätseinstellungen AKS Standard AKS Automatik
Kubernetes-API-Authentifizierung Lokale Konten sind standardmäßig aktiviert. Microsoft Entra Authentifizierung ist optional. Microsoft Entra-Authentifizierung vorkonfiguriert. Lokale Konten sind deaktiviert.
Kubernetes-API-Autorisierung Kubernetes RBAC oder Azure RBAC für Kubernetes-Autorisierung Azure RBAC vorkonfiguriert. Kubernetes RBAC kann für Dienstkonten und differenzierte Berechtigungen koexistieren.
Lokale Konten Standardmäßig aktiviert Standardmäßig deaktiviert
OIDC-Aussteller Standardmäßig für neue Cluster auf Kubernetes 1.34 oder höher aktiviert. Manuell für vorhandene Cluster und frühere Kubernetes-Versionen aktiviert. Vorkonfiguriert
Microsoft Entra Workload ID Optional, separat aktiviert Vorkonfiguriert

AKS Automatic vereinfacht nicht nur die Identitätskonfiguration. Er entfernt den am wenigsten sicheren Standardwert (lokale Konten) und ersetzt ihn durch Azure RBAC, OIDC-Partnerverbund und Workload-ID, die von Anfang an aktiviert ist. Ein mit AKS Automatic erstelltes Cluster startet mit derselben standardmäßig sicheren Sicherheitskonfiguration, die ein sicherheitsbewusstes Team auf AKS Standard andernfalls explizit konfigurieren müsste.

Im direkten Vergleich verfolgen EKS Auto Mode und AKS Automatic klar das Ziel, den Umfang der Identitätskonfiguration, der dem Operator überlassen bleibt, zu reduzieren und auf jeder Ebene standardmäßig die sicherere Option zu wählen, sie setzen jedoch auf unterschiedlichen Ebenen des Stacks an. Die Identitätsänderungen von EKS Auto Mode konzentrieren sich auf die Cluster- und Knotenebene, wobei die IAM-Richtlinien standardisiert werden und IAM weiterhin als einziges Identitätssystem dient. Die Identität auf Podebene wird in Richtung EKS Pod Identity verschoben, während der Clusterzugriff EKS-Zugriffsrichtlinien, Kubernetes RBAC oder beides verwenden kann. Die Identitätsänderungen von AKS Automatic konzentrieren sich auf die Authentifizierungs- und Autorisierungsebene: Lokale Konten entfallen, Azure RBAC ist standardmäßig aktiviert, und OIDC-Verbund sowie Workload ID sind für den Zugriff auf Pod-Ebene bereits vorkonfiguriert.

Identitätseinstellungen EKS-Automodus AKS Automatik
Cluster und Knoten IAM/Identity Standardisierter, enger gefasster Satz von IAM-Richtlinien Verwaltete Identität, unverändert gegenüber AKS Standard.
Zugriff auf Human/API-Cluster IAM-Prinzipale authentifizieren sich über Zugriffseinträge oder aws-auth; EKS-Zugriffsrichtlinien oder Kubernetes RBAC autorisieren den Zugriff Microsoft Entra ID authentifiziert Benutzer. Azure RBAC ist vorkonfiguriert für die Autorisierung. Lokale Konten sind deaktiviert.
Identität auf Pod-Ebene Pod Identity Agent vorinstalliert. Operatoren erstellen weiterhin Pod-Identitätszuordnungen. OIDC-Issuer und Workload-ID aktiviert. Operatoren konfigurieren weiterhin eine Identität, Verbundanmeldeinformationen, ein Dienstkonto und einen Pod.
Autorisierung innerhalb des Clusters EKS-Zugriffsrichtlinien, Kubernetes RBAC oder beides Azure RBAC vorkonfiguriert ist. Kubernetes RBAC kann für Dienstkonten und fein abgestufte Berechtigungen nebeneinander bestehen.

Überlegungen zur Kubernetes-Identität

Beachten Sie unabhängig davon, welche Plattform Sie verwenden, die folgenden Punkte:

Zuerst ist die Identität auf Podebene der Ort, an dem die beiden Plattformen am ehesten gleich sind. IRSA ist das nächstgelegene EKS-Äquivalent zu Microsoft Entra Workload ID, da beide einen OIDC-Verbund verwenden. EkS Pod Identity verwendet stattdessen den EKS Auth-Dienst. Verwenden Sie für neue AKS-Workloads die Workload ID anstelle der veralteten podverwalteten Identität.

Zweitens umgehen AKS lokale Konten Microsoft Entra Authentifizierung. Deaktivieren Sie lokale Konten nach dem Aktivieren Microsoft Entra Integration, sodass Administratoren die zentralisierte Authentifizierung verwenden. Für EKS-Experten bieten Zugriffseinträge den nächstgelegenen Vergleichspunkt für den zentral verwalteten Prinzipal-zu-Cluster-Zugriff, während Azure RBAC die AKS-Autorisierungsebene bereitstellt.

Drittens ist die Zentralisierung des Zugriffs über viele Cluster hinweg eine Funktion, nicht eine gegebene. Amazon EKS wickelt dies über IAM-Tools ab, die allgemein für AWS entwickelt wurden (z. B. IAM Identity Center), statt über etwas EKS-Spezifisches. Azure RBAC ist dagegen für die Kubernetes-Autorisierung von Anfang an so konzipiert, dass sie einheitlich auf Cluster, Abonnements und Verwaltungsgruppen angewendet wird.

Schließlich ist AKS Automatic für die meisten AKS-Workloads die empfohlene Standardeinstellung für den Produktiveinsatz. Im Vergleich zum AUTOMATISCHen EKS-Modus ändert AKS Automatic mehr Authentifizierungs- und Autorisierungsstandardwerte, indem lokale Konten deaktiviert und Azure RBAC, der OIDC-Aussteller und die Workload-ID vorkonfiguriert werden.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

Andere Mitwirkende:

Um nichtöffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

  • Zuletzt aktualisiert um