IAM-Rollen für Servicekonten

Anwendungen in den Container eines Pod können ein AWS-SDK oder die AWS CLI verwenden, um API-Anfragen an AWS-Services mithilfe von AWS Identity and Access Management (IAM)-Berechtigungen zu stellen. Anwendungen müssen ihre AWS-API-Anforderungen mit AWS-Anmeldeinformationen signieren. IAM-Rollen für Servicekonten 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, ordnen Sie eine IAM-Rolle einem Kubernetes-Servicekonto zu und konfigurieren Ihre Pods für die Verwendung des Service-Kontos. Sie können keine IAM-Rollen für Servicekonten 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.

• Isolation von Anmeldeinformationen – Ein Container eines Pod's kann nur Anmeldeinformationen für die IAM-Rolle abrufen, die dem Servicekonto zugeordnet ist, zu dem er gehört. Ein Container hat nie Zugriff auf Anmeldeinformationen, die von anderen Containern in anderen Pods verwendet werden. Wenn IAM-Rollen für Servicekonten verwendet werden, haben Pod's-Container auch die Berechtigungen, die der Amazon-EKS-Knoten-IAM-Rolle zugeordnet sind, es sei denn, Sie blockieren den Pod-Zugang zum 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.

• Auditierbarkeit – Die Zugriffs- und Ereignisprotokollierung ist über AWS CloudTrail verfügbar, um eine nachträgliche Auditierung zu ermöglichen.

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

1. Erstellen eines IAM-OIDC-Anbieters für Ihren Cluster – Sie führen dieses Verfahren für jeden Cluster nur einmal durch.

   Anmerkung

   Wenn Sie den EKS-VPC-Endpunkt aktivieren, kann von dieser VPC aus 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 can't 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.

2. Konfigurieren eines Kubernetes-Servicekontos zur Übernahme einer IAM-Rolle – Führen Sie dieses Verfahren für jeden eindeutigen Satz von Berechtigungen aus, über den eine Anwendung verfügen soll.

3. Konfigurieren von Pods für die Verwendung eines Kubernetes-Servicekontos – Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf AWS-Services benötigt.

4. Verwendung eines unterstützten AWS-SDK – 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 AWS Identity and Access Management Unterstützung für Verbundidentitäten mit OpenID Connect (OIDC) hinzugefügt. Mit diesem Feature 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 AWS STS AssumeRoleWithWebIdentity-API-Operation ü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. Weitere Informationen erhalten Sie unter Abrufen von Signaturschlüsseln.

Kubernetes verwendet seit langem Servicekonten als eigenes internes Identitätssystem. Pods kann sich mit dem authentifizieren KubernetesAPI-Server unter Verwendung eines automatisch gemounteten Tokens (ein Nicht-OIDC JWT) authentifizieren, das nur der Kubernetes-API-Server validieren kann. Diese Legacy-Servicekonto-Token laufen nicht ab und das Rotieren des Signaturschlüssels ist ein schwieriger Prozess. In Kubernetes der Version 1.12 wurde Unterstützung 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.