View a markdown version of this page

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

Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

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

Anwendungen in den Containern eines Pods können ein AWS SDK oder die AWS CLI verwenden, um API-Anfragen an AWS Dienste mithilfe von AWS Identity and Access Management (IAM) -Berechtigungen zu stellen. Anwendungen müssen ihre AWS API-Anfragen 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 EC2-Instance zu verwenden, verknüpfen Sie eine IAM-Rolle mit einem Kubernetes-Dienstkonto und konfigurieren Ihre Pods so, dass sie das Dienstkonto 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, so, dass sie die EKS Pod Identity-Anmeldeinformationen verwenden.

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

Pods, hostNetwork: true die mit konfiguriert sind, haben immer IMDS-Zugriff, aber die AWS SDKs und die CLI verwenden Pod Identity-Anmeldeinformationen, wenn sie aktiviert sind.

  • Überprüfbarkeit — Zugriffs- und Ereignisprotokollierung sind über verfügbar, AWS CloudTrail um nachträgliche Prüfungen zu erleichtern.

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-Authentifizierungsdienst in EKS Pod Identity angenommen und nicht 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 Gewähren Sie Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Dienstkonten.

Ü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. Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren— Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf AWS Dienste benötigt.

  4. Verwenden Sie Pod Identity mit dem AWS SDK— Vergewissern Sie sich, dass der Workload ein AWS SDK einer unterstützten Version verwendet und dass der Workload die standardmäßige Anmeldeinformationskette verwendet.

Einschränkungen

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

Überlegungen

  • IAM-Rollenzuordnung: Jedes Kubernetes-Dienstkonto in einem Cluster kann mit einer IAM-Rolle aus demselben Konto wie AWS der Cluster verknüpft 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 AWS kontenübergreifenden Zugriffs 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. Es verwendet die KnotenhostNetwork, belegt die Ports 80 und 2703 verwendet die Link-Local-Adresse (169.254.170.23für IPv4, für IPv6). [fd00:ec2::23] 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 dem 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 Version der Plattform

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 auf AWS Fargate (Fargate) laufen, werden nicht unterstützt. In Windows-Amazon-EC2-Instances ausgeführte Pods werden nicht unterstützt.