View a markdown version of this page

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 unter, 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

Registrieren Sie sich für bevorstehende Amazon EKS-Workshops.

Anwendungen in den Containern eines Pods können ein AWS SDK oder die AWS CLI verwenden, um API-Anfragen an AWS Dienste zu stellen, die AWS Identity and Access Management (IAM) -Berechtigungen verwenden. 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 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-Dienstkonto und konfigurieren Ihre Pods so, dass sie das Dienstkonto verwenden. Sie können keine IAM-Rollen für Dienstkonten mit lokalen Clustern für Amazon EKS auf Outposts verwenden. AWS

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

Pods, die mit hostNetwork: true konfiguriert sind, haben immer IMDS-Zugriff, aber die AWS SDKs und die CLI verwenden 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 die VPC Ihres Clusters keinen ausgehenden Internetzugang hat und Sie keinen privaten Zugriff auf den Cluster-OIDC-Endpunkt eingerichtet haben, können Operationen, die diesen Endpunkt innerhalb der VPC erreichen, wie z. B. das Erstellen eines OIDC-Anbieters mit, den Hostnamen des OIDC-Ausstellers nicht auflösen. eksctl Es folgt ein Beispiel für eine Fehlermeldung:

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

    Um den Cluster-OIDC-Endpunkt privat von Ihrer VPC aus zu erreichen, erstellen Sie dafür einen VPC-Schnittstellenendpunkt () mit aktiviertem privaten DNS. com.amazonaws.region-code.oidc-eks Weitere Informationen finden Sie unter Greifen Sie auf Amazon EKS zu mit AWS PrivateLink.

    Alternativ können Sie den Befehl auch außerhalb der VPC ausführen (z. B. in AWS CloudShell) oder einen bedingten Split-Horizon-Resolver erstellen. Ein Beispiel 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 aus, der Zugriff AWS auf Dienste benötigt.

  4. IRSA mit dem AWS SDK verwenden — Stellen Sie sicher, dass der Workload ein AWS SDK einer unterstützten Version verwendet und dass der Workload die Standard-Anmeldeinformationskette verwendet.

Hintergrundinformationen zu IAM, Kubernetes und OpenID Connect (OIDC)

2014 fügte AWS Identity and Access Management 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-Web-Token (JWT) erhalten. Sie können dieses Token an den AWS AssumeRoleWithWebIdentity STS-API-Vorgang übergeben und die Anmeldeinformationen für temporäre IAM-Rollen erhalten. Sie können diese Anmeldeinformationen verwenden, um mit jedem AWS Dienst 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.