Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt - Amazon EKS
Vorteile von EKS-Pod-IdentitätenÜbersicht über die Einrichtung von EKS-Pod-IdentitätenGrenzwerteÜberlegungen

Unterstützung für die Verbesserung dieser Seite beitragen

Um zu diesem Benutzerhandbuch beizutragen, klicken Sie auf den Link Diese Seite auf GitHub bearbeiten, der sich im rechten Bereich jeder Seite befindet.

Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt

Die Anwendungen in den Containern eines Pods können ein AWS-SDK oder die AWS-CLI verwenden, um API-Anforderungen an AWS-Services mithilfe von AWS Identity and Access Management (IAM)-Berechtigungen zu senden. Die Anwendungen müssen ihre AWS-API-Anforderungen mit AWS-Anmeldeinformationen signieren.

EKS-Pod-Identitäten bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie Amazon-EC2-Instance-Profile Anmeldeinformationen für Amazon-EC2-Instances bereitstellen. Anstatt Ihre AWS-Anmeldeinformationen zu erstellen und an die Container zu verteilen oder die Rolle der Amazon-EC2-Instance zu verwenden, verknüpfen Sie eine IAM-Rolle mit einem Kubernetes-Servicekonto und konfigurieren Ihre Pods so, dass sie das Servicekonto verwenden.

Jede EKS-Pod-Identity-Zuordnung ordnet einem Servicekonto in einem Namespace im angegebenen Cluster eine Rolle zu. Wenn Sie dieselbe Anwendung in mehreren Clustern haben, können Sie in jedem Cluster identische Zuordnungen vornehmen, ohne die Vertrauensrichtlinie der Rolle zu ändern.

Wenn ein Pod ein Servicekonto mit einer Zuordnung verwendet, legt Amazon EKS Umgebungsvariablen in den Containern des Pods fest. Die Umgebungsvariablen konfigurieren die AWS-SDKs, einschließlich der AWS-CLI, für die Verwendung der Anmeldeinformationen für EKS Pod Identity.

Vorteile von EKS-Pod-Identitäten

EKS-Pod-Identitäten bieten die folgenden Vorteile:

  • Geringste Berechtigung – Sie können IAM-Berechtigungen auf ein Servicekonto beschränken, und nur Pods, die dieses Servicekonto verwenden, haben Zugriff auf diese Berechtigungen. Mit diesem Feature entfällt auch die Notwendigkeit von Drittanbieterlösungen wie kiam oder kube2iam.

  • Isolierung von Anmeldeinformationen – Wenn der Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS) eingeschränkt ist, können die Container eines Pods nur Anmeldeinformationen für die IAM-Rolle abrufen, die dem vom Container verwendeten Servicekonto zugeordnet ist. Ein Container hat nie Zugriff auf Anmeldeinformationen, die von anderen Containern in anderen Pods verwendet werden. Wenn IMDS nicht eingeschränkt ist, haben die Container des Pods auch Zugriff auf die IAM-Rolle des Amazon-EKS-Knotens und die Container können möglicherweise auf Anmeldeinformationen von IAM-Rollen anderer Pods auf demselben Knoten zugreifen. Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist.

Anmerkung

Mit hostNetwork: true konfigurierte Pods haben immer IMDS-Zugriff, aber die AWS-SDKs und die CLI verwenden bei Aktivierung die Pod-Identity-Anmeldeinformationen.

  • Überprüfbarkeit – Die Zugriffs- und Ereignisprotokollierung ist über AWS CloudTrail verfügbar, um eine nachträgliche Überprüfung zu vereinfachen.

Wichtig

Container stellen keine Sicherheitsgrenze dar und die Verwendung von Pod Identity ändert daran nichts. Pods, die demselben Knoten zugewiesen sind, teilen sich einen Kernel und möglicherweise andere Ressourcen, abhängig von Ihrer Pod-Konfiguration. Während Pods, die auf separaten Knoten ausgeführt werden, auf der Rechenebene isoliert sind, gibt es Knotenanwendungen, die über zusätzliche Berechtigungen in der Kubernetes-API verfügen, die über den Umfang einer einzelnen Instance hinausgehen. Einige Beispiele sind kubelet, kube-proxy, CSI-Speichertreiber oder Ihre eigenen Kubernetes-Anwendungen.

EKS Pod Identity ist eine einfachere Methode als IAM-Rollen für Servicekonten, da diese keine OIDC-Identitätsanbieter nutzt. EKS Pod Identity bietet die folgenden Verbesserungen:

  • Unabhängiger Betrieb – In vielen Organisationen liegt die Verantwortung für die Erstellung von OIDC-Identitätsanbietern bei anderen Teams als für die Verwaltung der Kubernetes-Cluster. EKS Pod Identity hat eine klare Aufgabentrennung: Die gesamte Konfiguration der EKS-Pod-Identity-Zuordnungen erfolgt in Amazon EKS und die gesamte Konfiguration der IAM-Berechtigungen erfolgt in IAM.

  • Wiederverwendbarkeit – EKS Pod Identity verwendet einen einzigen IAM-Prinzipal anstelle der separaten Prinzipale für jeden Cluster, den IAM-Rollen für Servicekonten verwenden. Ihr IAM-Administrator fügt der Vertrauensrichtlinie jeder Rolle den folgenden Prinzipal hinzu, damit sie von EKS-Pod-Identitäten verwendet werden kann.

                "Principal": {
                "Service": "pods.eks.amazonaws.com"
            }

  • Skalierbarkeit – Jeder Satz temporärer Anmeldeinformationen wird vom EKS-Service in EKS Pod Identity angenommen statt von jedem AWS-SDK, das Sie in jedem Pod ausführen. Anschließend stellt der Amazon EKS Pod Identity Agent, der auf jedem Knoten ausgeführt wird, die Anmeldeinformationen an die SDKs aus. Dadurch wird die Last für jeden Knoten reduziert und nicht in jedem Pod dupliziert. Weitere Details zu diesem Prozess finden Sie unter Funktionsweise von EKS Pod Identity verstehen.

Weitere Informationen zum Vergleich der beiden Alternativen finden Sie unter Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren.

Übersicht über die Einrichtung von EKS-Pod-Identitäten

Aktivieren Sie EKS-Pod-Identitäten, indem Sie die folgenden Verfahren ausführen:

  1. Einrichtung des Amazon-EKS-Pod-Identity-Agenten – Sie führen diesen Vorgang für jeden Cluster nur einmal durch. Sie müssen diesen Schritt nicht ausführen, wenn EKS Auto Mode in Ihrem Cluster aktiviert ist.

  2. Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto – Führen Sie dieses Verfahren für jeden einzelnen Berechtigungssatz durch, den eine Anwendung haben soll.

  3. Konfiguration von Pods für den Zugriff auf AWS-Services mit Servicekonten – Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf AWS-Services benötigt.

  4. Verwendung der Pod Identity mit dem AWS-SDK – Stellen Sie sicher, dass der Workload ein AWS-SDK einer unterstützten Version verwendet und dass der Workload die Kette standardmäßiger Anmeldeinformationen verwendet.

Grenzwerte

  • Pro Cluster werden bis zu 5 000 EKS-Pod-Identity-Zuordnungen unterstützt, um IAM-Rollen Kubernetes-Servicekonten zuzuordnen.

Überlegungen

  • IAM-Rollenzuordnung: Jedes Kubernetes-Servicekonto in einem Cluster kann einer IAM-Rolle aus demselben AWS-Konto wie das Cluster zugeordnet werden. Sie ändern die Rolle, indem Sie die EKS-Pod-Identity-Zuordnung bearbeiten. Für den kontenübergreifenden Zugriff delegieren Sie den Zugriff auf die Rolle mithilfe von IAM-Rollen. Weitere Informationen finden Sie unter Delegieren des Zugriffs über alle AWS-Konten hinweg mithilfe von IAM-Rollen im IAM-Benutzerhandbuch.

  • EKS-Pod-Identity-Agent: Der Pod-Identity-Agent ist zur Verwendung von EKS Pod Identity erforderlich. Der Agent wird als Kubernetes DaemonSet in Cluster-Knoten ausgeführt und stellt Anmeldeinformationen nur für Pods auf demselben Knoten bereit. Er verwendet das hostNetwork des Knotens und belegt die Ports 80 und 2703 auf der link-lokalen Adresse (169.254.170.23 für IPv4, [fd00:ec2::23] für IPv6). Wenn IPv6 in Ihrem Cluster deaktiviert ist, deaktivieren Sie IPv6 für den Pod-Identity-Agent. Weitere Informationen finden Sie unter IPv6 im EKS-Pod-Identity-Agent deaktivieren.

  • Eventuelle Konsistenz: EKS-Pod-Identity-Zuordnungen sind letztendlich konsistent, mit möglichen Verzögerungen von mehreren Sekunden nach API-Aufrufen. Vermeiden Sie die Erstellung oder Aktualisierung von Verknüpfungen in kritischen Code-Pfaden mit hoher Verfügbarkeit. Führen Sie diese Aktionen stattdessen in separaten, weniger häufigen Initialisierungs- oder Einrichtungsroutinen durch. Weitere Informationen finden Sie unter Sicherheitsgruppen pro Pod im EKS-Leitfaden für bewährte Methoden.

  • Überlegungen zu Proxy und Sicherheitsgruppe: Bei Pods, die einen Proxy verwenden, fügen Sie 169.254.170.23 (IPv4) und [fd00:ec2::23] (IPv6) zu den no_proxy/NO_PROXY-Umgebungsvariablen hinzu, um fehlgeschlagene Anfragen an den EKS-Pod-Identity-Agent zu vermeiden. Wenn Sie Sicherheitsgruppen für Pods mit AWS VPC CNI verwenden, setzen Sie das ENABLE_POD_ENI-Flag auf „true“ und das POD_SECURITY_GROUP_ENFORCING_MODE-Flag auf „standard“. Weitere Informationen finden Sie unter Zuweisen von Sicherheitsgruppen zu einzelnen Pods.

Cluster-Versionen von EKS Pod Identity

Um EKS Pod Identity nutzen zu können, muss der Cluster über eine Plattformversion verfügen, die mindestens der in der folgenden Tabelle aufgeführten Version entspricht, oder über eine Kubernetes-Version, die neuer ist als die in der Tabelle aufgeführten Versionen. Die empfohlene Version des Amazon-EKS-Pod-Identity-Agent für eine Kubernetes-Version finden Sie unter Kompatibilität der Add-On-Version von Amazon EKS mit einem Cluster überprüfen.

Kubernetes-Version Plattformversion

Nicht aufgeführte Kubernetes-Versionen

Alle Plattformversionen werden unterstützt

1.28

eks.4

Einschränkungen von EKS Pod Identity

EKS-Pod-Identitäten sind auf folgenden Plattformen verfügbar:

EKS Pod Identities sind auf folgenden Plattformen nicht verfügbar:

  • AWS Outposts

  • Amazon EKS Anywhere.

  • Kubernetes-Cluster, die Sie in Amazon EC2 erstellen und ausführen. Die EKS-Pod-Identity-Komponenten sind nur in Amazon EKS verfügbar.

Sie können EKS Pod Identities nicht verwenden mit:

  • Pods, die nicht auf Linux-Amazon-EC2-Instances ausgeführt werden. Linux- und Windows-Pods, die in AWS Fargate (Fargate) ausgeführt werden, werden nicht unterstützt. In Windows-Amazon-EC2-Instances ausgeführte Pods werden nicht unterstützt.