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

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.

IAM-Rollen für Servicekonten

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. IAM-Rollen für Servicekonten (IRSA) 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. Sie können keine IAM-Rollen für Servicekonten mit lokalen Clustern für Amazon EKS in 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 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. Die AWS-SDKs und die CLI verwenden jedoch IRSA-Anmeldeinformationen, wenn sie aktiviert sind.

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

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, beispielsweise in AWS CloudShell oder auf einem mit dem Internet verbundenen Computer. 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 die bedingte Weiterleitung in CoreDNS finden Sie in der Amazon-EKS-Feature-Anforderung auf 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 für die Verwendung eines Kubernetes-Servicekontos konfigurieren – Führen Sie diesen Vorgang für jeden Pod durch, der Zugriff auf AWS-Services benötigt.

  4. IRSA mit dem AWS-SDK verwenden – Stellen Sie sicher, dass die Workload ein AWS-SDK einer unterstützten Version verwendet und dass die Workload die standardmäßige Anmeldeinformationskette verwendet.

Hintergrundinformationen zu IAM, Kubernetes und OpenID Connect (OIDC)

2014 wurde die AWS-Identitäts- und Zugriffsverwaltung um den Support für Verbundidentitäten unter Verwendung von OpenID Connect (OIDC) erweitert. Mit dieser Funktion können Sie AWS-API-Aufrufe mit unterstützten Identitätsanbietern authentifizieren und ein gültiges OIDC-JSON-Web-Token (JWT) erhalten. Sie können dieses Token an die Operation für AWS STS AssumeRoleWithWebIdentity API übergeben und temporäre IAM-Rollen-Anmeldeinformationen erhalten. Sie können diese Anmeldeinformationen verwenden, um mit jedem AWS-Service wie Amazon S3 und DynamoDB zu interagieren.

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.