IAM-Rollen für Servicekonten

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 Rechte — Sie können IAM-Berechtigungen auf ein Dienstkonto beschränken, und nur Pods, die dieses Dienstkonto verwenden, haben Zugriff auf diese Berechtigungen. Mit diesem Feature entfällt auch die Notwendigkeit von Drittanbieterlösungen wie kiam oder kube2iam.

• Isolierung von Anmeldeinformationen — Die Container eines Pods können nur Anmeldeinformationen für die IAM-Rolle abrufen, die dem Dienstkonto zugeordnet ist, das der Container verwendet. Ein Container hat niemals Zugriff auf Anmeldeinformationen, die von anderen Containern in anderen Pods verwendet werden. Wenn Sie IAM-Rollen für Dienstkonten verwenden, verfügen die Container des Pods auch über die Berechtigungen, die der IAM-Rolle des Amazon EKS-Knotens zugewiesen sind, es sei denn, Sie blockieren den Pod-Zugriff auf den Amazon EC2 Instance Metadata Service (IMDS). Weitere Informationen finden Sie unter Beschränken Sie den Zugriff auf das Instance-Profil, das dem Worker-Knoten zugewiesen ist.

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

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

1. Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster — Sie führen dieses Verfahren für jeden Cluster nur einmal durch.

   Anmerkung

   Wenn Sie den EKS-VPC-Endpunkt aktiviert haben, konnte von dieser VPC aus nicht auf den EKS-OIDC-Dienstendpunkt 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 in der VPC einen bedingten Split-Horizon-Resolver erstellen, z. B. den Route 53-Resolver, um einen anderen Resolver für die OIDC-Aussteller-URL zu verwenden und nicht das VPC-DNS dafür zu verwenden. Ein Beispiel für bedingte Weiterleitung in CoreDNS finden Sie in der Amazon EKS-Funktionsanfrage unter. GitHub

2. Weisen Sie Kubernetes-Servicekonten IAM-Rollen zu — Führen Sie dieses Verfahren für jeden eindeutigen Satz von Berechtigungen aus, über den 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 Dienstkonto-Tokens laufen nicht ab, und die Rotation des Signaturschlüssels ist ein schwieriger Prozess. In der Kubernetes-Version 1.12 wurde Unterstützung für eine neue ProjectedServiceAccountToken Funktion hinzugefügt. Bei dieser Funktion handelt es sich um ein OIDC-JSON-Webtoken, das auch die Identität des Dienstkontos enthält und eine konfigurierbare Zielgruppe unterstützt.

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