IAM-Rollen für Servicekonten - Amazon EKS
Hintergrundinformationen zu IAM, Kubernetes und OpenID Connect (OIDC)

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.

IAM-Rollen für Servicekonten

Tipp

Melden Sie sich für bevorstehende Amazon EKS-Workshops an.

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. IAM-Rollen für Servicekonten (IRSA) bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie EC2 Amazon-Instance-Profile Anmeldeinformationen für Amazon-Instances bereitstellen. EC2 Anstatt Ihre AWS Anmeldeinformationen zu erstellen und an die Container zu verteilen oder die Rolle der EC2 Amazon-Instance zu verwenden, verknüpfen Sie eine IAM-Rolle mit einem Kubernetes-Dienstkonto und konfigurieren Ihre Pods so, dass sie das Dienstkonto verwenden. Sie können IAM-Rollen nicht für Dienstkonten mit lokalen Clustern für Amazon EKS auf AWS Outposts verwenden.

IAM-Rollen für Servicekonten bietet 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 Dienstkonto zugeordnet ist, das der Container verwendet. 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 AND-CLI verwendet IRSA-Anmeldeinformationen, wenn sie aktiviert sind.

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

Wichtig

Container stellen keine Sicherheitsgrenze dar, und die Verwendung von IAM-Rollen für Servicekonten ä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.

Aktivieren Sie IAM-Rollen für Servicekonten, indem Sie die folgenden Verfahren ausführen:

  1. IAM-OIDC-Anbieter für Ihren Cluster erstellen – Sie müssen diesen Vorgang nur einmal für einen Cluster durchführen.

    Anmerkung

    Wenn Sie den EKS-VPC-Endpunkt aktiviert haben, kann von innerhalb dieser VPC nicht auf den EKS-OIDC-Service-Endpunkt zugegriffen werden. Folglich funktionieren Ihre Operationen wie das Erstellen eines OIDC-Anbieters mit eksctl in der VPC nicht und führen zu einem Timeout, wenn Sie versuchen, https://oidc.eks.region.amazonaws.com anzufordern. Es folgt ein Beispiel für eine Fehlermeldung:

    server cant find oidc.eks.region.amazonaws.com: NXDOMAIN

    Um diesen Schritt abzuschließen, können Sie den Befehl außerhalb der VPC ausführen, z. B. in AWS CloudShell oder auf einem Computer, der mit dem Internet verbunden ist. Alternativ können Sie einen Split-Horizon-Conditional-Resolver in der VPC erstellen, z. B. Route 53 Resolver, um einen anderen Resolver für die OIDC-Aussteller-URL zu verwenden und dafür nicht das VPC-DNS zu nutzen. Ein Beispiel für bedingte Weiterleitung in CoreDNS finden Sie in der Amazon EKS-Funktionsanfrage unter. GitHub

  2. IAM-Rollen Kubernetes-Servicekonten zuweisen – Führen Sie diesen Vorgang für jede einzelne Berechtigungsgruppe durch, über die eine Anwendung verfügen soll.

  3. Pods so konfigurieren, dass sie ein Kubernetes-Dienstkonto verwenden — Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf Dienste benötigt. AWS

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

Hintergrundinformationen zu IAM, Kubernetes und OpenID Connect (OIDC)

2014 fügte AWS Identity and Access Management die Unterstützung für föderierte Identitäten mithilfe von OpenID Connect (OIDC) hinzu. Mit dieser Funktion können Sie AWS API-Aufrufe bei unterstützten Identitätsanbietern authentifizieren und ein gültiges OIDC-JSON-Webtoken (JWT) erhalten. Sie können dieses Token an den AWS AssumeRoleWithWebIdentity STS-API-Vorgang übergeben und temporäre IAM-Rollenanmeldedaten erhalten. Sie können diese Anmeldeinformationen verwenden, um mit jedem AWS Service zu interagieren, einschließlich Amazon S3 und DynamoDB.

Jedes JWT-Token ist mit einem Signaturschlüsselpaar signiert. Die Schlüssel werden für den von Amazon EKS verwalteten OIDC-Anbieter bereitgestellt und der private Schlüssel wechselt alle 7 Tage. Amazon EKS bewahrt die öffentlichen Schlüssel auf, bis sie ablaufen. Wenn Sie externe OIDC-Clients verbinden, beachten Sie, dass Sie die Signaturschlüssel aktualisieren müssen, bevor der öffentliche Schlüssel abläuft. Erfahren Sie, wie Sie Signaturschlüssel abrufen, um OIDC-Token zu validieren.

Kubernetes verwendet seit langem Servicekonten als eigenes internes Identitätssystem. Pods können sich beim Kubernetes-API-Server mithilfe eines automatisch gemounteten Tokens (ein Nicht-OIDC-JWT) authentifizieren, das nur der Kubernetes-API-Server validieren kann. Diese alten Servicekonto-Token laufen nicht ab und das Rotieren des Signaturschlüssels ist ein schwieriger Prozess. In der Kubernetes-Version 1.12 wurde Support für ein neues ProjectedServiceAccountToken-Feature hinzugefügt. Dieses Feature ist ein OIDC-JSON-Web-Token, das auch die Identität des Servicekontos enthält und eine konfigurierbare Zielgruppe unterstützt.

Amazon EKS hostet jetzt einen öffentlichen OIDC-Erkennungsendpunkt pro Cluster, der die Signaturschlüssel für die ProjectedServiceAccountToken-JSON-Web-Token enthält, sodass externe Systeme wie IAM die von Kubernetes ausgegebenen OIDC-Token validieren und akzeptieren können.