**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.
# Erfahren Sie, wie die Zugriffskontrolle in Amazon EKS funktioniert
Erfahren Sie, wie Sie den Zugriff auf Ihren Amazon-EKS-Cluster verwalten. Die Verwendung von Amazon EKS erfordert Kenntnisse darüber, wie sowohl Kubernetes als auch AWS Identity and Access Management (AWS IAM) die Zugriffskontrolle handhaben.
**Dieser Abschnitt enthält:**
** [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md) ** – Erfahren Sie, wie Sie Anwendungen oder Benutzern die Authentifizierung bei der Kubernetes-API ermöglichen. Sie können Zugriffseinträge, aws-auth ConfigMap oder einen externen OIDC-Anbieter verwenden.
**[Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole](view-kubernetes-resources.md)**— Erfahren Sie, wie Sie den AWS-Managementkonsole für die Kommunikation mit Ihrem Amazon EKS-Cluster konfigurieren. Verwenden Sie die Konsole, um Kubernetes-Ressourcen im Cluster anzuzeigen, z. B. Namespaces, Knoten und Pods.
**[AWS Diensten Schreibzugriff auf Kubernetes gewähren APIs](mutate-kubernetes-resources.md)**— Erfahren Sie mehr über die Berechtigungen, die zum Ändern von Kubernetes-Ressourcen erforderlich sind.
** [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md) ** – Erfahren Sie, wie Sie kubectl für die Kommunikation mit Ihrem Amazon-EKS-Cluster konfigurieren. Verwenden Sie die AWS CLI, um eine kubeconfig-Datei zu erstellen.
**[Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren](service-accounts.md)**— Erfahren Sie, wie Sie ein Kubernetes-Dienstkonto mit IAM-Rollen verknüpfen. AWS Sie können Pod Identity oder IAM Roles for Service Accounts (IRSA) verwenden.
## Allgemeine Aufgaben
+ Gewähren Sie Entwicklern Zugriff auf die Kubernetes-API. Kubernetes-Ressourcen finden Sie in der. AWS-Managementkonsole
+ Lösung: [Verwenden Sie Zugriffseinträge](access-entries.md), um Kubernetes-RBAC-Berechtigungen IAM-Benutzern oder -Rollen zuzuordnen. AWS
+ Konfigurieren Sie kubectl so, dass es mithilfe AWS von Anmeldeinformationen mit einem Amazon EKS-Cluster kommuniziert.
+ Lösung: Verwenden Sie die AWS CLI, um [eine kubeconfig-Datei zu erstellen](create-kubeconfig.md).
+ Verwenden Sie einen externen Identitätsanbieter wie Ping Identity, um Benutzer bei der Kubernetes-API zu authentifizieren.
+ Lösung: [Verbinden Sie einen externen OIDC-Anbieter](authenticate-oidc-identity-provider.md).
+ Gewähren Sie Workloads auf Ihrem Kubernetes-Cluster die Möglichkeit, Anrufe zu tätigen. AWS APIs
+ Lösung: [Verwenden Sie Pod Identity](pod-identities.md), um eine AWS IAM-Rolle einem Kubernetes-Dienstkonto zuzuordnen.
## Hintergrund
+ [Erfahren Sie, wie Kubernetes-Servicekonten funktionieren.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Überprüfen Sie das rollenbasierte Zugriffskontrollmodell (RBAC) von Kubernetes.](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Weitere Informationen zur Verwaltung des Zugriffs auf AWS Ressourcen finden Sie im [AWS IAM-Benutzerhandbuch](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html). Alternativ können Sie an einer kostenlosen [Einführungsschulung zur Verwendung von AWS IAM](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam) teilnehmen.
## Überlegungen zu EKS Auto Mode
EKS Auto Mode lässt sich mit EKS Pod Identity und EKS-Zugriffseinträgen integrieren.
+ EKS Auto Mode verwendet Zugriffseinträge, um der EKS-Steuerebene Kubernetes-Berechtigungen zu gewähren. Beispielsweise ermöglichen die Zugriffsrichtlinien EKS Auto Mode, Informationen über Netzwerkendpunkte und -services zu lesen
+ Es ist nicht möglich, Zugriffseinträge in einem EKS-Auto-Mode-Cluster zu deaktivieren.
+ Optional können Sie die `aws-auth` `ConfigMap` aktivieren.
+ Die Zugriffseinträge für EKS Auto Mode werden automatisch konfiguriert. Sie können diese Zugriffseinträge anzeigen, jedoch nicht ändern.
+ Wenn Sie eine NodeClass benutzerdefinierte Node-IAM-Rolle verwenden, müssen Sie mithilfe der EKSAuto NodePolicy Amazon-Zugriffsrichtlinie einen Zugriffseintrag für die Rolle erstellen.
+ Wenn Sie Workload-Berechtigungen für AWS Dienste gewähren möchten, verwenden Sie EKS Pod Identity.
+ Sie müssen den Pod-Identity-Agenten nicht auf EKS-Auto-Mode-Clustern installieren.
# Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs
Ihr Cluster verfügt über einen Kubernetes-API-Endpunkt. Kubectl verwendet diese API. Sie können sich mit zwei Identitätstypen bei dieser API authentifizieren:
+ **Ein AWS Identity and Access Management (IAM) *-Prinzipal* (Rolle oder Benutzer)** — Dieser Typ erfordert eine Authentifizierung bei IAM. Benutzer können sich AWS als [IAM-Benutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) oder mit einer [föderierten Identität anmelden, indem sie Anmeldeinformationen verwenden, die über eine Identitätsquelle](https://aws.amazon.com/identity/federation/) bereitgestellt wurden. Benutzer können sich nur dann mit einer Verbundidentität anmelden, wenn Ihr Administrator zuvor mithilfe von IAM-Rollen einen Identitätsverbund eingerichtet hat. Wenn Benutzer AWS mithilfe eines Verbunds darauf zugreifen, [übernehmen sie indirekt eine Rolle](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole). Wenn Benutzer diese Art von Identität verwenden, gilt Folgendes:
+ Kann ihnen Kubernetes-Berechtigungen zuweisen, damit sie mit Kubernetes-Objekten in Ihrem Cluster arbeiten können. Weitere Informationen dazu, wie Sie Ihren IAM-Prinzipalen Berechtigungen zuweisen, damit sie auf Kubernetes-Objekte in Ihrem Cluster zugreifen können, finden Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md).
+ Kann ihnen IAM-Berechtigungen zuweisen, sodass sie mithilfe der Amazon EKS-API, AWS CLI,, oder `eksctl` mit Ihrem Amazon EKS-Cluster und seinen Ressourcen arbeiten können. AWS CloudFormation AWS-Managementkonsole Weitere Informationen finden Sie in der Service-Authorization-Referenz unter [Von Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
+ Wenn Knoten in Ihren Cluster eingebunden werden, nehmen sie eine IAM-Rolle an. Die Möglichkeit, mit IAM-Prinzipalen auf Ihren Cluster zuzugreifen, wird durch den [AWS IAM Authenticator für Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) bereitgestellt, der auf der Steuerebene von Amazon EKS ausgeführt wird.
+ **Ein Benutzer in Ihrem eigenen OpenID Connect (OIDC)-Anbieter** – Dieser Typ erfordert eine Authentifizierung bei Ihrem [OIDC](https://openid.net/connect/)-Anbieter. Weitere Informationen zur Einrichtung Ihres eigenen OIDC-Anbieters mit Ihrem Amazon-EKS-Cluster finden Sie unter [Benutzern Zugriff auf Kubernetes mit einem externen OIDC-Anbieter gewähren](authenticate-oidc-identity-provider.md). Wenn Benutzer diese Art von Identität verwenden, gilt Folgendes:
+ Kann ihnen Kubernetes-Berechtigungen zuweisen, damit sie mit Kubernetes-Objekten in Ihrem Cluster arbeiten können.
+ Ihnen können keine IAM-Berechtigungen zugewiesen werden, sodass sie mithilfe der Amazon EKS-API, AWS CLI,, oder `eksctl` mit Ihrem Amazon EKS-Cluster und seinen Ressourcen arbeiten können. AWS CloudFormation AWS-Managementkonsole
Sie können beide Arten von Identitäten mit Ihrem Cluster verwenden. Die IAM-Authentifizierungsmethode kann nicht deaktiviert werden. Die OIDC-Authentifizierungsmethode ist optional.
## IAM-Identitäten Kubernetes-Berechtigungen zuordnen
Der [AWS IAM Authenticator für Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) ist auf der Steuerebene Ihres Clusters installiert. Er ermöglicht [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM)-Prinzipale (Rollen und Benutzer), denen Sie den Zugriff auf Kubernetes-Ressourcen in Ihrem Cluster gestatten. Sie können eine der folgenden Methoden verwenden, um IAM-Prinzipalen Zugriff auf Kubernetes-Objekte in Ihrem Cluster zu gewähren:
+ **Erstellen von Zugriffseinträgen** – Wenn Ihr Cluster mindestens über die Plattformversion verfügt, die im Abschnitt [Voraussetzungen](access-entries.md) für die Kubernetes-Version Ihres Clusters aufgeführt ist, sollten Sie diese Option verwenden.
Verwenden Sie *Zugriffseinträge*, um die Kubernetes-Berechtigungen von IAM-Prinzipalen außerhalb des Clusters zu verwalten. Sie können den Zugriff auf den Cluster mithilfe der EKS-API, der AWS Befehlszeilenschnittstelle, AWS SDKs AWS CloudFormation, und hinzufügen und AWS-Managementkonsole verwalten. Für die Benutzerverwaltung können also die gleichen Tools verwendet werden wie für die Clustererstellung.
Folgen Sie zunächst den Anweisungen [Authentifizierungsmodus zur Verwendung von Zugriffseinträgen ändern und anschließend Vorhandene aws-auth-Einträge](setting-up-access-entries.md) [zu ConfigMap Zugriffseinträgen migrieren](migrating-access-entries.md).
+ **Hinzufügen von Einträgen zu `aws-auth` `ConfigMap` **: Wenn die Plattformversion Ihres Clusters älter ist als die im Abschnitt [Voraussetzungen](access-entries.md) aufgeführte Version, muss diese Option verwendet werden. Falls die Plattformversion Ihres Clusters mindestens der Plattformversion entspricht, die im Abschnitt [Voraussetzungen](access-entries.md) für die Kubernetes-Version Ihres Clusters angegeben ist, und Sie Einträge zu `ConfigMap` hinzugefügt haben, empfiehlt es sich, diese Einträge zu Zugriffseinträgen zu migrieren. Sie können allerdings keine Einträge migrieren, die von Amazon EKS zu `ConfigMap` hinzugefügt wurden (also beispielsweise Einträge für IAM-Rollen, die mit verwalteten Knotengruppen oder Fargate-Profilen verwendet werden). Weitere Informationen finden Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](#grant-k8s-access).
+ Wenn Sie `aws-auth` `ConfigMap` verwenden müssen, können Sie mithilfe des Befehls `eksctl create iamidentitymapping` Einträge zu `ConfigMap` hinzufügen. Weitere Informationen finden Sie in der Dokumentation zu `eksctl` unter [Manage IAM users and roles](https://eksctl.io/usage/iam-identity-mappings/).
## Einstellen des Cluster-Authentifizierungsmodus
Jeder Cluster hat einen *Authentifizierungsmodus*. Der Authentifizierungsmodus bestimmt, welche Methoden Sie verwenden können, um IAM-Prinzipalen den Zugriff auf Kubernetes-Objekte in Ihrem Cluster zu ermöglichen. Es gibt drei Authentifizierungsmodi.
**Wichtig**
Sobald die Zugriffseingabemethode aktiviert ist, kann sie nicht mehr deaktiviert werden.
Wenn die `ConfigMap`-Methode während der Cluster-Erstellung nicht aktiviert wird, kann sie später nicht mehr aktiviert werden. Für alle Cluster, die vor der Einführung von Zugriffseinträgen erstellt wurden, ist die `ConfigMap`-Methode aktiviert.
Wenn Sie Hybridknoten mit Ihrem Cluster verwenden, müssen Sie die Cluster-Authentifizierungsmodi `API` oder `API_AND_CONFIG_MAP` verwenden.
**Die `aws-auth` `ConfigMap` innerhalb des Clusters**
Dies ist der ursprüngliche Authentifizierungsmodus für Amazon-EKS-Cluster. Der IAM-Prinzipal, der den Cluster erstellt hat, ist zunächst der einzige Benutzer, der über `kubectl` auf den Cluster zugreifen kann. Dieser Benutzer muss der Liste in `aws-auth` `ConfigMap` weitere Benutzer hinzufügen und Berechtigungen zuweisen, die sich auf die anderen Benutzer innerhalb des Clusters auswirken. Die anderen Benutzer können den ursprünglichen Benutzer nicht verwalten oder entfernen, da `ConfigMap` keinen zu verwaltenden Eintrag enthält.
**Sowohl die als auch die Zugriffseinträge `ConfigMap`**
In diesem Authentifizierungsmodus können Sie beide Methoden verwenden, um dem Cluster IAM-Prinzipale hinzuzufügen. Beachten Sie, dass jede Methode separate Einträge speichert. Wenn Sie beispielsweise einen Zugriffseintrag über die AWS CLI hinzufügen, `aws-auth` `ConfigMap` wird dieser nicht aktualisiert.
**Nur auf Einträge zugreifen**
In diesem Authentifizierungsmodus können Sie die EKS-API, die AWS Befehlszeilenschnittstelle,, und verwenden AWS SDKs AWS CloudFormation, AWS-Managementkonsole um den Zugriff auf den Cluster für IAM-Prinzipale zu verwalten.
Jeder Zugriffseintrag hat einen *Typ* und Sie können eine Kombination aus *Zugriffsbereich* und *Zugriffsrichtlinie* verwenden, um mithilfe des Zugriffsbereichs den Prinzipal auf einen bestimmten Namespace zu beschränken und mithilfe der Zugriffsrichtlinie vorkonfigurierte, wiederverwendbare Berechtigungsrichtlinien festzulegen. Alternativ können Sie den Typ STANDARD und Kubernetes RBAC-Gruppen verwenden, um benutzerdefinierte Berechtigungen zuzuweisen.
| Authentifizierungsmodus | Methoden |
| --- | --- |
| Nur `ConfigMap` (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| EKS-API und `ConfigMap` (`API_AND_CONFIG_MAP`) | auf Einträge in der EKS-API, der AWS Befehlszeilenschnittstelle, AWS SDKs AWS CloudFormation, und zugreifen AWS-Managementkonsole `aws-auth` `ConfigMap` |
| Nur EKS-API (`API`) | auf Einträge in der EKS-API, der AWS Befehlszeilenschnittstelle, AWS SDKs, AWS CloudFormation, zugreifen und AWS-Managementkonsole |
**Anmerkung**
Amazon EKS Auto Mode erfordert Zugriffseinträge.
# IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren
Dieser Abschnitt zeigt Ihnen, wie Sie den IAM-Prinzipalzugriff auf Kubernetes-Cluster in Amazon Elastic Kubernetes Service (EKS) mithilfe von Zugriffseinträgen und Richtlinien verwalten. Sie finden detaillierte Informationen zum Ändern von Authentifizierungsmodi, zur Migration von veralteten `aws-auth`-ConfigMap-Einträgen, zum Erstellen, Aktualisieren und Löschen von Zugriffseinträgen, zum Verknüpfen von Richtlinien mit Einträgen, zum Überprüfen vordefinierter Richtlinienberechtigungen sowie zu wichtigen Voraussetzungen und Überlegungen für eine sichere Zugriffsverwaltung.
## Übersicht
EKS-Zugriffseinträge sind die optimale Methode, um Benutzern Zugriff auf die Kubernetes-API zu gewähren. Beispielsweise können Sie Zugriffseinträge verwenden, um Entwicklern Zugriff auf die Verwendung von kubectl zu gewähren. Grundsätzlich ordnet ein EKS-Zugriffseintrag eine Reihe von Kubernetes-Berechtigungen einer IAM-Identität zu, beispielsweise einer IAM-Rolle. Ein Entwickler kann beispielsweise eine IAM-Rolle übernehmen und diese zur Authentifizierung bei einem EKS-Cluster verwenden.
## Feature
+ **Zentralisierte Authentifizierung und Autorisierung**: Steuert den Zugriff auf Kubernetes-Cluster direkt über Amazon-EKS-APIs, sodass für Benutzerberechtigungen kein Wechsel zwischen AWS- und Kubernetes-APIs erforderlich ist.
+ **Differenzierte Berechtigungsverwaltung**: Verwendet Zugriffseinträge und Richtlinien, um differenzierte Berechtigungen für AWS-IAM-Prinzipale zu definieren, einschließlich der Änderung oder Aufhebung des Cluster-Admin-Zugriffs durch den Ersteller.
+ **IaC-Tool-Integration**: Unterstützt Infrastructure-as-Code-Tools wie AWS CloudFormation, Terraform und AWS CDK, um Zugriffskonfigurationen während der Cluster-Erstellung zu definieren.
+ **Wiederherstellung nach Fehlkonfiguration**: Ermöglicht die Wiederherstellung des Cluster-Zugriffs über die Amazon-EKS-API ohne direkten Zugriff auf die Kubernetes-API.
+ **Reduzierte Gemeinkosten und verbesserte Sicherheit**: Zentralisiert den Betrieb, um die Gemeinkosten zu senken, und nutzt gleichzeitig AWS-IAM-Features wie CloudTrail-Auditprotokollierung und Multi-Faktor-Authentifizierung.
## So fügen Sie Berechtigungen hinzu
Sie können Kubernetes-Berechtigungen für den Zugriff auf Einträge auf zwei Arten anfügen:
+ Verwenden Sie eine Zugriffsrichtlinie. Zugriffsrichtlinien sind vordefinierte Kubernetes-Berechtigungsvorlagen, die von AWS verwaltet werden. Weitere Informationen finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
+ Verweisen Sie auf eine Kubernetes-Gruppe. Wenn Sie eine IAM-Identität einer Kubernetes-Gruppe zuordnen, können Sie Kubernetes-Ressourcen erstellen, die der Gruppe Berechtigungen gewähren. Weitere Informationen finden Sie unter [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
## Überlegungen
Beachten Sie bei der Aktivierung von EKS-Zugriffseinträgen in vorhandenen Clustern Folgendes:
+ **Verhalten älterer Cluster**: Bei Clustern, die vor der Einführung von Zugriffseinträgen erstellt wurden (d. h. Clustern mit einer Plattformversion, die älter ist als in den [Anforderungen an die Plattformversion angegeben](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), erstellt EKS automatisch einen Zugriffseintrag, der die bereits vorhandenen Berechtigungen widerspiegelt. Dieser Eintrag enthält die IAM-Identität, mit welcher der Cluster ursprünglich erstellt wurde, sowie die Verwaltungsberechtigungen, die dieser Identität bei der Cluster-Erstellung gewährt wurden.
+ **Umgang mit der veralteten `aws-auth`-ConfigMap**: Wenn Ihr Cluster für die Zugriffsverwaltung auf die veraltete `aws-auth`-ConfigMap angewiesen ist, wird bei der Aktivierung von Zugriffseinträgen automatisch nur der Zugriffseintrag für den ursprünglichen Cluster-Ersteller erstellt. Zusätzliche Rollen oder Berechtigungen, die der ConfigMap hinzugefügt werden (z. B. benutzerdefinierte IAM-Rollen für Entwickler oder Services), werden nicht automatisch migriert. Um dies zu beheben, erstellen Sie manuell die entsprechenden Zugriffseinträge.
## Erste Schritte
1. Legen Sie die IAM-Identitäts- und Zugriffsrichtlinie fest, die Sie verwenden möchten.
+ [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md)
1. Aktivieren Sie EKS-Zugriffseinträge in Ihrem Cluster. Bestätigen Sie, dass Sie über eine unterstützte Plattformversion verfügen.
+ [Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden](setting-up-access-entries.md)
1. Erstellen Sie einen Zugriffseintrag, der eine IAM-Identität einer Kubernetes-Berechtigung zuordnet.
+ [Zugriffseinträge erstellen](creating-access-entries.md)
1. Authentifizieren Sie sich beim Cluster mit der IAM-Identität.
+ [AWS-CLI einrichten](install-awscli.md)
+ [`kubectl` und `eksctl` einrichten](install-kubectl.md)
# Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen
Sie können *Zugriffseinträgen* vom *Typ* `STANDARD` eine oder mehrere Zugriffsrichtlinien zuweisen. Amazon EKS erteilt den anderen Arten von Zugriffseinträgen automatisch die erforderlichen Berechtigungen, damit sie in Ihrem Cluster ordnungsgemäß funktionieren. Die Amazon-EKS-Zugriffsrichtlinien beinhalten Kubernetes-Berechtigungen, keine IAM-Berechtigungen. Machen Sie sich mit den Kubernetes-Berechtigungen vertraut, die in den einzelnen Zugriffsrichtlinien-Optionen enthalten sind, bevor Sie einem Zugriffseintrag eine Zugriffsrichtlinie zuweisen. Weitere Informationen finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md). Wenn keine der Zugriffsrichtlinien Ihre Anforderungen erfüllt, ordnen Sie einem Zugriffseintrag keine Zugriffsrichtlinie zu. Geben Sie stattdessen mindestens einen *Gruppennamen* für den Zugriffseintrag an und erstellen und verwalten Sie Kubernetes-Objekte für die rollenbasierte Zugriffskontrolle. Weitere Informationen finden Sie unter [Zugriffseinträge erstellen](creating-access-entries.md).
+ Ein vorhandener Zugriffseintrag. Informationen zum Erstellen finden Sie unter [Zugriffseinträge erstellen](creating-access-entries.md).
+ Eine Rolle oder ein entsprechender Benutzer für AWS Identity and Access Management mit folgenden Berechtigungen: `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy` und `DisassociateAccessPolicy`. Weitere Informationen finden Sie unter [Von Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) in der *Service-Autorisierungsreferenz*.
Berücksichtigen Sie die folgenden Anforderungen, bevor Sie Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen:
+ Sie können jedem Zugriffseintrag mehrere Zugriffsrichtlinien zuordnen, aber Sie können jede Richtlinie nur einmal einem Zugriffseintrag zuordnen. Wenn Sie mehrere Zugriffsrichtlinien zuordnen, verfügt der IAM-Prinzipal des Zugriffseintrags über alle Berechtigungen aus allen zugeordneten Zugriffsrichtlinien.
+ Sie können eine Zugriffsrichtlinie auf alle Ressourcen in einem Cluster ausrichten oder den Namen eines oder mehrerer Kubernetes-Namespaces angeben. Sie können Platzhalterzeichen für einen Namespace-Namen verwenden. Wenn Sie beispielsweise eine Zugriffsrichtlinie auf alle Namespaces ausrichten möchten, die mit `dev-` beginnen, können Sie `dev-*` als Namespace-Namen angeben. Stellen Sie sicher, dass die Namespaces in Ihrem Cluster vorhanden sind und dass Ihre Schreibweise dem tatsächlichen Namespace-Namen im Cluster entspricht. Amazon EKS überprüft weder die Schreibweise noch das Vorhandensein der Namespaces in Ihrem Cluster.
+ Der *Zugriffsbereich* für eine Zugriffsrichtlinie kann geändert werden, nachdem sie einem Zugriffseintrag zugeordnet wurde. Wenn Sie die Zugriffsrichtlinie auf Kubernetes-Namespaces beschränkt haben, können Sie bei Bedarf Namespaces für die Zuordnung hinzufügen und entfernen.
+ Wenn Sie eine Zugriffsrichtlinie einem Zugriffseintrag zuordnen, für den auch *Gruppennamen* angegeben sind, verfügt der IAM-Prinzipal über alle Berechtigungen in allen zugehörigen Zugriffsrichtlinien. Außerdem verfügt er über alle Berechtigungen aus jedem `Role`-Objekt vom Typ `ClusterRole` oder `Role`, das in einem beliebigen Kubernetes-Objekt vom Typ oder `RoleBinding` zum Angeben der Gruppennamen angegeben ist.
+ Wenn Sie den Befehl `kubectl auth can-i --list` ausführen, werden keine Kubernetes-Berechtigungen angezeigt, die durch Zugriffsrichtlinien zugewiesen wurden, die einem Zugriffseintrag für den IAM-Prinzipal zugeordnet sind, den Sie beim Ausführen des Befehls verwenden. Der Befehl zeigt nur Kubernetes-Berechtigungen an, wenn Sie sie in Kubernetes-Objekten vom Typ `Role` oder `ClusterRole` gewährt haben, die Sie an die Gruppennamen oder an den Benutzernamen gebunden haben, die bzw. den Sie für einen Zugriffseintrag angegeben haben.
+ Wenn Sie bei der Interaktion mit Kubernetes-Objekten in Ihrem Cluster die Identität eines Kubernetes-Benutzers oder einer Kubernetes-Gruppe annehmen, beispielsweise indem Sie den Befehl `kubectl` mit `--as username ` oder `--as-group group-name ` verwenden, erzwingen Sie die Verwendung der Kubernetes RBAC-Autorisierung. Daher werden dem IAM-Prinzipal keine Berechtigungen durch eine Zugriffsrichtlinie zugewiesen, die dem Zugriffseintrag zugeordnet ist. Die einzigen Kubernetes-Berechtigungen, über die der Benutzer oder die Gruppe verfügt, dessen bzw. deren Identität der IAM-Prinzipal angenommen hat, sind die Kubernetes-Berechtigungen, die Sie in Kubernetes-Objekten vom Typ `Role` oder `ClusterRole` gewährt haben, die von Ihnen an die Gruppennamen oder an den Benutzernamen gebunden wurden. Damit Ihr IAM-Prinzipal über die Berechtigungen in den zugehörigen Zugriffsrichtlinien verfügt, dürfen Sie sich nicht als Kubernetes-Benutzer oder -Gruppe ausgeben. Der IAM-Prinzipal verfügt auch weiterhin über alle Berechtigungen, die Sie ihm in den Kubernetes-Objekten vom Typ `Role` oder `ClusterRole` gewährt haben, die Sie an die Gruppennamen oder an den Benutzernamen gebunden haben, die bzw. den Sie für den Zugriffseintrag angegeben haben. Weitere Informationen finden Sie unter [Benutzeridentitätswechsel](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) in der Kubernetes-Dokumentation.
Sie können die AWS-Managementkonsole oder die AWS CLI verwenden, um eine Zugriffsrichtlinie einem Zugriffseintrag zuzuordnen.
## AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, der über einen Zugriffseintrag verfügt, dem Sie eine Zugriffsrichtlinien zuordnen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wenn es sich um einen Zugriffseintrag vom Typ **Standard** handelt, können Sie **Zugriffsrichtlinien** von Amazon EKS zuordnen oder deren Zuordnung aufheben. Bei Zugriffseinträgen eines anderen Typs (also nicht **Standard**) steht diese Option nicht zur Verfügung.
1. Wählen Sie **Zugriffsrichtlinie zuordnen** aus.
1. Wählen Sie unter **Richtlinienname** die Richtlinie mit den Berechtigungen aus, über die der IAM-Prinzipal verfügen soll. Informationen zu den Berechtigungen, die in der jeweiligen Richtlinie enthalten sind, finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
1. Wählen Sie unter **Zugriffsbereich** einen Zugriffsbereich aus. Bei Verwendung der Option **Cluster** werden die Berechtigungen in der Zugriffsrichtlinie dem IAM-Prinzipal für Ressourcen in allen Kubernetes-Namespaces gewährt. Bei Verwendung der Option **Kubernetes-Namespace** können Sie anschließend **Neuen Namespace hinzufügen** auswählen. In dem daraufhin angezeigten Feld **Namespace** können Sie den Namen eines Kubernetes-Namespace in Ihrem Cluster eingeben. Wenn die Berechtigungen für den IAM-Prinzipal in mehreren Namespaces gelten sollen, können Sie mehrere Namespaces eingeben.
1. Wählen Sie **Zugriffsrichtlinie hinzufügen** aus.
## AWS-CLI
1. Version `2.12.3` oder höher oder die Version `1.27.160` oder höher der AWS-Befehlszeilenschnittstelle (AWS-CLI), die auf Ihrem Gerät oder in AWS CloudShell installiert und konfiguriert sein muss. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paket-Manager wie `yum`, `apt-get` oder Homebrew für macOS sind oft mehrere Versionen hinter der neuesten Version der AWS CLI. Um die neueste Version zu installieren, lesen Sie [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle*. Die in AWS CloudShell installierte AWS-CLI-Version kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zum Aktualisieren finden Sie unter [Installieren der AWS CLI in Ihrem Stammverzeichnis](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) im * AWS-CloudShell-Benutzerhandbuch*.
1. Sehen Sie sich die verfügbaren Zugriffsrichtlinien an.
```
aws eks list-access-policies --output table
```
Eine Beispielausgabe sieht wie folgt aus.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Informationen zu den Berechtigungen, die in der jeweiligen Richtlinie enthalten sind, finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
1. Sehen Sie sich Ihre vorhandenen Zugriffseinträge an. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters.
```
aws eks list-access-entries --cluster-name my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. Ordnen Sie eine Zugriffsrichtlinie einem Zugriffseintrag zu. Im folgenden Beispiel wird die Zugriffsrichtlinie `AmazonEKSViewPolicy` einem Zugriffseintrag zugeordnet. Wenn die IAM-Rolle *my-role* versucht, auf Kubernetes-Objekte im Cluster zuzugreifen, autorisiert Amazon EKS die Rolle nur dazu, die Berechtigungen in der Richtlinie für den Zugriff auf Kubernetes-Objekte in den Kubernetes-Namespaces *my-namespace1* und *my-namespace2* zu verwenden. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *my-role* durch den Namen der IAM-Rolle, für die Amazon EKS den Zugriff auf Kubernetes-Cluster-Objekte autorisieren soll.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Wenn die Berechtigungen für den IAM-Prinzipal clusterweit gelten sollen, ersetzen Sie `type=namespace,namespaces=my-namespace1,my-namespace2 ` durch `type=cluster`. Wenn Sie dem Zugriffseintrag mehrere Zugriffsrichtlinien zuordnen möchten, führen Sie den Befehl mehrmals aus und verwenden Sie dabei jeweils eine individuelle Zugriffsrichtlinie. Jede zugeordnete Zugriffsrichtlinie hat ihren eigenen Geltungsbereich.
**Anmerkung**
Wenn Sie später den Geltungsbereich einer zugehörigen Zugriffsrichtlinie ändern möchten, können Sie den vorherigen Befehl erneut ausführen und dabei den neuen Bereich angeben. Wenn Sie also beispielsweise *my-namespace2* entfernen möchten, führen Sie den Befehl erneut aus und verwenden Sie dabei nur `type=namespace,namespaces=my-namespace1 `. Wenn Sie den Bereich von `namespace` in `cluster` ändern möchten, führen Sie den Befehl erneut aus und verwenden Sie dabei `type=cluster`, um `type=namespace,namespaces=my-namespace1,my-namespace2 ` zu entfernen.
1. Ermitteln Sie, welche Zugriffsrichtlinien einem Zugriffseintrag zugeordnet sind.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
Im vorherigen Beispiel verfügt der IAM-Prinzipal für diesen Zugriffseintrag über Leseberechtigungen für alle Namespaces im Cluster und über Administratorberechtigungen für zwei Kubernetes-Namespaces.
1. Heben Sie die Zuordnung zwischen einer Zugriffsrichtlinie und einem Zugriffseintrag auf. In diesem Beispiel wird die Zuordnung zwischen der Richtlinie `AmazonEKSAdminPolicy` und einem Zugriffseintrag aufgehoben. Die in der Zugriffsrichtlinie `AmazonEKSViewPolicy` enthaltenen Berechtigungen für Objekte in den Namespaces *my-namespace1* und *my-namespace2* bleiben für den IAM-Prinzipal allerdings erhalten, da die Zuordnung zwischen dieser Zugriffsrichtlinie und dem Zugriffseintrag nicht aufgehoben wird.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Eine Liste der verfügbaren Zugriffsrichtlinien finden Sie unter [Berechtigungen von Zugriffsrichtlinien überprüfen](access-policy-permissions.md).
# Migrieren vorhandener `aws-auth ConfigMap`-Einträge zu Zugriffseinträgen
Wenn Sie Einträge zu `aws-auth` `ConfigMap` für Ihren Cluster hinzugefügt haben, empfiehlt es sich, Zugriffseinträge für die vorhandenen Einträge in `aws-auth` `ConfigMap` zu erstellen. Nach der Erstellung der Zugriffseinträge können Sie die Einträge aus `ConfigMap` entfernen. Einträgen in `aws-auth` `ConfigMap` können keine [Zugriffsrichtlinien](access-policies.md) zugeordnet werden. Wenn Sie Ihren IAM-Prinzipalen Zugriffsrichtlinien zuordnen möchten, müssen Sie Zugriffseinträge erstellen.
**Wichtig**
Wenn sich ein Cluster im `API_AND_CONFIGMAP`-Authentifizierungsmodus befindet und sowohl in den `aws-auth` `ConfigMap`- als auch in den Zugriffseinträgen eine Zuordnung für dieselbe IAM-Rolle vorhanden ist, verwendet die Rolle die Zuordnung des Zugriffseintrags zur Authentifizierung. Zugriffseinträge haben Vorrang vor `ConfigMap`-Einträgen für denselben IAM-Prinzipal.
Bevor Sie vorhandene `aws-auth` `ConfigMap`-Einträge entfernen, die von Amazon EKS für eine [verwaltete Knotengruppe](managed-node-groups.md) oder ein [Fargate-Profil](fargate-profile.md) in Ihrem Cluster erstellt wurden, überprüfen Sie, ob die richtigen Zugriffseinträge für diese spezifischen Ressourcen in Ihrem Amazon-EKS-Cluster vorhanden sind. Wenn Sie Einträge entfernen, die Amazon EKS in `ConfigMap` erstellt hat, ohne die entsprechenden Zugriffseinträge zu haben, funktioniert Ihr Cluster nicht ordnungsgemäß.
## Voraussetzungen
+ Vertrautheit mit Zugriffseinträgen und Zugriffsrichtlinien. Weitere Informationen erhalten Sie unter [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md) und [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md).
+ Ein vorhandener Cluster mit einer Plattformversion, die den in den Voraussetzungen des [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md)-Themas aufgeführten Versionen entspricht oder höher ist.
+ Version `0.215.0` oder höher des `eksctl`-Befehlszeilen-Tools, das auf Ihrem Computer oder in der AWS CloudShell installiert ist. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
+ Kubernetes-Berechtigungen zum Ändern von `aws-auth` `ConfigMap` im `kube-system`-Namespace.
+ Eine AWS Identity and Access Management Zugriffsverwaltungsrolle oder ein Benutzer mit den folgenden Berechtigungen: `CreateAccessEntry` und`ListAccessEntries`. Weitere Informationen finden Sie in der Service-Authorization-Referenz unter [Von Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
## `eksctl`
1. Sehen Sie sich die vorhandenen Einträge in `aws-auth ConfigMap` an. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters.
```
eksctl get iamidentitymapping --cluster my-cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws: iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:user/my-user my-user
arn:aws: iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws: iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Zugriffseinträge erstellen](creating-access-entries.md) für alle von Ihnen erstellten `ConfigMap`-Einträge aus der vorherigen Ausgabe. Achten Sie beim Erstellen der Zugriffseinträge darauf, für `ARN`, `USERNAME`, `GROUPS` und `ACCOUNT` die gleichen Werte anzugeben, die in der Ausgabe zurückgegeben wurden. Im Falle der Beispielausgabe würden Sie Zugriffseinträge für alle Einträge außer den letzten beiden Einträgen erstellen, da diese von Amazon EKS für ein Fargate-Profil bzw. für eine verwaltete Knotengruppe erstellt wurden.
1. Löschen Sie die Einträge aus `ConfigMap` für alle von Ihnen erstellten Zugriffseinträge. Wenn Sie den Eintrag nicht aus `ConfigMap` löschen, wird der `ConfigMap`-Eintrag durch die Einstellungen für den Zugriffseintrag für den IAM-Prinzipal-ARN außer Kraft gesetzt. *111122223333*Ersetzen Sie es durch Ihre AWS Konto-ID und *EKS-my-cluster-my-namespace-Viewers* durch den Namen der Rolle im Eintrag in Ihrem`ConfigMap`. Wenn der Eintrag, den Sie entfernen möchten, für einen IAM-Benutzer und nicht für eine IAM-Rolle bestimmt ist, `role` ersetzen Sie ihn durch `user` und *EKS-my-cluster-my-namespace-Viewers* durch den Benutzernamen.
```
eksctl delete iamidentitymapping --arn arn:aws: iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Berechtigungen von Zugriffsrichtlinien überprüfen
Zugriffsrichtlinien beinhalten `rules`, die Kubernetes `verbs` (Berechtigungen) und `resources` enthalten. Zugriffsrichtlinien beinhalten keine IAM-Berechtigungen oder -Ressourcen. Ähnlich wie bei Kubernetes `Role` und `ClusterRole`-Objekten beinhalten Zugriffsrichtlinien nur `allow` `rules`. Der Inhalt einer Zugriffsrichtlinie kann nicht geändert werden. Sie können keine eigenen Zugriffsrichtlinien erstellen. Wenn die Berechtigungen in den Zugriffsrichtlinien Ihre Anforderungen nicht erfüllen, können Sie Kubernetes-RBAC-Objekte erstellen und *Gruppennamen* für Ihre Zugriffseinträge angeben. Weitere Informationen finden Sie unter [Zugriffseinträge erstellen](creating-access-entries.md). Die in den Zugriffsrichtlinien enthaltenen Berechtigungen ähneln den Berechtigungen in den benutzerorientierten Cluster-Rollen von Kubernetes. Weitere Informationen finden Sie unter[Benutzerorientierte Rollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) in der Kubernetes-Dokumentation.
## Alle Richtlinien auflisten
Verwenden Sie eine der auf dieser Seite aufgeführten Zugriffsrichtlinien oder rufen Sie mit der AWS CLI eine Liste aller verfügbaren Zugriffsrichtlinien ab:
```
aws eks list-access-policies
```
Die erwartete Ausgabe sollte wie folgt aussehen (der Kürze halber abgekürzt):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## EKSAdminAmazon-Richtlinie
Diese Zugriffsrichtlinie umfasst Berechtigungen, die einem IAM-Prinzipal die meisten Berechtigungen für Ressourcen erteilen. Wenn dies einem Zugriffseintrag zugeordnet ist, umfasst sein Zugriffsbereich normalerweise einen oder mehrere Kubernetes-Namespaces. Wenn ein IAM-Prinzipal über Administratorzugriff auf alle Ressourcen in Ihrem Cluster verfügen soll, ordnen Sie die Zugriffsrichtlinie [Amazon EKSCluster AdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) stattdessen Ihrem Zugriffseintrag zu.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## Amazon EKSCluster AdminPolicy
Diese Zugriffsrichtlinie umfasst Berechtigungen, die einem IAM-Prinzipaladministrator Zugriff auf einen Cluster gewähren. Wenn dies einem Zugriffseintrag zugeordnet ist, umfasst der Zugriffsbereich in der Regel keinen Kubernetes-Namespace, sondern den Cluster. Wenn Sie möchten, dass ein IAM-Prinzipal einen eingeschränkteren Verwaltungsbereich hat, sollten Sie stattdessen die [EKSAdminAmazon-Richtlinie](#access-policy-permissions-amazoneksadminpolicy)-Zugriffsrichtlinie mit Ihrem Zugriffseintrag verknüpfen.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Kubernetes-API-Gruppen | Kubernetes, keine Ressource URLs | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## Amazon EKSAdmin ViewPolicy
Diese Zugriffsrichtlinie umfasst Berechtigungen, die einem IAM-Prinzipal Zugriff auf list/view alle Ressourcen in einem Cluster gewähren. Beachten Sie, dass dies [Kubernetes-Geheimnisse](https://kubernetes.io/docs/concepts/configuration/secret/) umfasst.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## EKSEditAmazon-Richtlinie
Diese Zugriffsrichtlinie umfasst Berechtigungen, mit denen ein IAM-Prinzipal die meisten Kubernetes-Ressourcen bearbeiten kann.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## EKSViewAmazon-Richtlinie
Diese Zugriffsrichtlinie umfasst Berechtigungen, mit denen ein IAM-Prinzipal die meisten Kubernetes-Ressourcen anzeigen kann.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## Amazon EKSSecret ReaderPolicy
Diese Zugriffsrichtlinie beinhaltet Berechtigungen, die es einem IAM-Prinzipal ermöglichen, [Kubernetes](https://kubernetes.io/docs/concepts/configuration/secret/) Secrets zu lesen.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## Amazon EKSAuto NodePolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Diese Richtlinie umfasst die folgenden Berechtigungen, mit denen Amazon-EKS-Komponenten die folgenden Aufgaben ausführen können:
+ `kube-proxy` – Überwachen Sie Netzwerkendpunkte und -services und verwalten Sie zugehörige Ereignisse. Dies ermöglicht eine Cluster-weite Netzwerk-Proxy-Funktionalität.
+ `ipamd`— Verwaltung von AWS VPC-Netzwerkressourcen und Container-Netzwerkschnittstellen (CNI). Dadurch kann der IP-Adressverwaltungs-Daemon die Pod-Vernetzung verwalten.
+ `coredns` – Greifen Sie auf Ressourcen zur Serviceerkennung wie Endpunkte und Services zu. Dies ermöglicht die DNS-Auflösung innerhalb des Clusters.
+ `ebs-csi-driver` – Arbeiten Sie mit speicherbezogenen Ressourcen für Amazon-EBS-Volumes. Dies ermöglicht die dynamische Bereitstellung und Anbindung von persistenten Volumes.
+ `neuron`— Überwachen Sie Knoten und Pods für AWS Neuron-Geräte. Dies ermöglicht die Verwaltung von AWS Inferentia- und Trainium-Beschleunigern.
+ `node-monitoring-agent` – Zugriff auf Knotendiagnosen und Ereignisse. Dies ermöglicht die Überwachung des Cluster-Zustands und die Erfassung von Diagnosedaten.
Jede Komponente verwendet ein dediziertes Servicekonto und ist auf die für ihre spezifische Funktion erforderlichen Berechtigungen beschränkt.
Wenn Sie eine Node-IAM-Rolle in einem manuell angeben NodeClass, müssen Sie einen Zugriffseintrag erstellen, der die neue Node-IAM-Rolle dieser Zugriffsrichtlinie zuordnet.
## Amazon EKSBlock StoragePolicy
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Diese Richtlinie umfasst Berechtigungen, mit denen Amazon EKS die Leader-Wahl und die Koordinierung von Ressourcen für Speichervorgänge verwalten kann:
+ `coordination.k8s.io` – Erstellen und verwalten Sie Lease-Objekte für die Leader-Wahl. Dadurch können EKS-Speicherkomponenten ihre Aktivitäten über einen Mechanismus für die Leader-Wahl Cluster-weit koordinieren.
Die Richtlinie gilt für bestimmte Lease-Ressourcen, die von den EKS-Speicherkomponenten verwendet werden, um Konflikte beim Zugriff auf andere Koordinierungsressourcen im Cluster zu vermeiden.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Blockspeicherfunktion ordnungsgemäß funktioniert.
## Amazon EKSLoad BalancingPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Diese Richtlinie umfasst Berechtigungen, mit denen Amazon EKS Ressourcen für die Leader-Wahl zum Load Balancing verwalten kann:
+ `coordination.k8s.io` – Erstellen und verwalten Sie Lease-Objekte für die Leader-Wahl. Dadurch können die EKS-Komponenten für das Load Balancing durch die Leader-Wahl Aktivitäten über mehrere Replikate hinweg koordinieren.
Die Richtlinie ist speziell auf das Load Balancing von Lease-Ressourcen ausgerichtet, um eine ordnungsgemäße Koordination sicherzustellen und gleichzeitig den Zugriff auf andere Leasing-Ressourcen im Cluster zu verhindern.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Netzwerkfunktion ordnungsgemäß funktioniert.
## EKSNetworkingAmazon-Richtlinie
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Diese Richtlinie umfasst Berechtigungen, mit denen Amazon EKS Ressourcen für die Leader-Wahl für die Vernetzung verwalten kann:
+ `coordination.k8s.io` – Erstellen und verwalten Sie Lease-Objekte für die Leader-Wahl. Dadurch können EKS-Netzwerkkomponenten die Aktivitäten zur IP-Adresszuweisung durch die Leader-Wahl koordinieren.
Die Richtlinie ist speziell auf die Vernetzung von Lease-Ressourcen ausgerichtet, um eine ordnungsgemäße Koordination zu gewährleisten und gleichzeitig den Zugriff auf andere Lease-Ressourcen im Cluster zu verhindern.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Netzwerkfunktion ordnungsgemäß funktioniert.
## EKSComputeAmazon-Richtlinie
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Diese Richtlinie umfasst Berechtigungen, mit denen Amazon EKS Ressourcen für die Leader-Wahl für Rechenoperationen verwalten kann:
+ `coordination.k8s.io` – Erstellen und verwalten Sie Lease-Objekte für die Leader-Wahl. Dadurch können EKS-Rechenkomponenten die Skalierungsaktivitäten der Knoten durch die Leader-Wahl koordinieren.
Die Richtlinie ist speziell auf die Berechnung von Verwaltungs-Lease-Ressourcen ausgerichtet und ermöglicht gleichzeitig den grundlegenden Lesezugriff (`get`, `watch`) auf alle Lease-Ressourcen im Cluster.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Netzwerkfunktion ordnungsgemäß funktioniert.
## Amazon EKSBlock StorageClusterPolicy
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Diese Richtlinie gewährt die erforderlichen Berechtigungen für die Blockspeicherfunktion von Amazon EKS Auto Mode. Sie ermöglicht eine effiziente Verwaltung der Blockspeicherressourcen innerhalb von Amazon-EKS-Clustern. Die Richtlinie umfasst folgende Berechtigungen:
CSI-Treiberverwaltung:
+ Erstellen, Lesen, Aktualisieren und Löschen von CSI-Treibern, insbesondere für Blockspeicher.
Volume-Verwaltung:
+ Auflisten, Beobachten, Erstellen, Aktualisieren, Patchen und Löschen persistenter Volumes.
+ Auflisten, Überwachen und Aktualisieren von persistenten Volume-Ansprüchen.
+ Patchen Sie des Status von persistenten Volume-Ansprüchen.
Interaktion zwischen Knoten und Pods:
+ Lesen Sie Informationen zu Knoten und Pods.
+ Speichern Sie Ereignisse im Zusammenhang mit Speichervorgängen.
Speicherklassen und Attribute:
+ Lesen Sie Speicherklassen und CSI-Knoten.
+ Lesen Sie die Volume-Attributklassen.
Anhänge von Volumes:
+ Auflisten, Überwachen und Ändern von Volume-Anhängen und deren Status.
Snapshot-Vorgänge:
+ Verwalten Sie Volumen-Snapshots, Snapshot-Inhalte und Snapshot-Klassen.
+ Verwalten Sie Vorgänge für Volume-Gruppen-Snapshots und zugehörige Ressourcen.
Diese Richtlinie wurde entwickelt, um eine umfassende Verwaltung von Blockspeichern innerhalb von Amazon-EKS-Clustern zu unterstützen, die im Automatikmodus ausgeführt werden. Sie umfasst Berechtigungen für verschiedene Vorgänge, darunter die Bereitstellung, das Anfügen, die Größenänderung und die Erstellung von Snapshots von Blockspeicher-Volumes.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Blockspeicherfunktion ordnungsgemäß funktioniert.
## Amazon EKSCompute ClusterPolicy
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Diese Richtlinie gewährt die erforderlichen Berechtigungen für die Rechenmanagement-Funktionen von Amazon EKS Auto Mode. Sie ermöglicht eine effiziente Orchestrierung und Skalierung von Rechenressourcen innerhalb von Amazon-EKS-Clustern Die Richtlinie umfasst folgende Berechtigungen:
Knotenverwaltung:
+ Den Status von und erstellen, lesen, aktualisieren, löschen und verwalten. NodePools NodeClaims
+ Verwalten NodeClasses, einschließlich Erstellung, Änderung und Löschung.
Terminplanung und Ressourcenmanagement:
+ Leserechte für Pods, Knoten, persistente Volumes, persistente Volume-Ansprüche, Replikationscontroller und Namespaces.
+ Lesezugriff auf Speicherklassen, CSI-Knoten und Volume-Anhänge.
+ Auflistung und Überwachung von Bereitstellungen, Daemon-Sets, Replica-Sets und Stateful-Sets.
+ Lesen Sie die Budgets für Pod-Unterbrechungen.
Ereignisbehandlung:
+ Erstellen, Lesen und Verwalten von Cluster-Ereignissen.
Entzug der Berechtigungen für Knoten und Pod-Bereinigung:
+ Aktualisieren, patchen und löschen Sie Knoten.
+ Erstellen Sie Pod-Bereinigungen und löschen Sie Pods bei Bedarf.
Verwaltung benutzerdefinierter Ressourcendefinitionen (CRD):
+ Neues erstellen CRDs.
+ Spezifische Funktionen CRDs im Zusammenhang mit der Knotenverwaltung verwalten (NodeClasses NodePools NodeClaims,, und NodeDiagnostics).
Diese Richtlinie wurde entwickelt, um eine umfassende Datenverarbeitungsverwaltung innerhalb von Amazon-EKS-Clustern zu unterstützen, die im Automatikmodus ausgeführt werden. Es vereint Berechtigungen für verschiedene Vorgänge, darunter die Bereitstellung von Knoten, die Planung, die Skalierung und die Ressourcenoptimierung.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Datenverarbeitungsverwaltungsfunktion ordnungsgemäß funktioniert.
## Amazon EKSLoad BalancingClusterPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Diese Richtlinie gewährt die erforderlichen Berechtigungen für die Load-Balancing-Funktion von Amazon EKS Auto Mode. Es ermöglicht die effiziente Verwaltung und Konfiguration von Load-Balancing-Ressourcen innerhalb von Amazon-EKS-Clustern. Die Richtlinie umfasst folgende Berechtigungen:
Ereignis- und Ressourcenmanagement:
+ Erstellen und Patchen von Ereignissen.
+ Lesezugriff auf Pods, Knoten, Endpunkte und Namespaces.
+ Aktualisieren des Pod-Status.
Service- und Ingress-Management:
+ Vollständige Verwaltung von Services und deren Status.
+ Umfassende Kontrolle über Ingresses und deren Status.
+ Lesezugriff auf Endpunkt-Slices und Ingress-Klassen.
Zielgruppenbindungen:
+ Erstellen und Ändern von Zielgruppenbindungen und deren Status.
+ Lesezugriff auf Ingress-Klassenparameter.
Verwaltung benutzerdefinierter Ressourcendefinitionen (CRD):
+ Alles erstellen und lesen CRDs.
+ Spezifische Verwaltung von targetgroupbindings.eks.amazonaws.com und ingressclassparams.eks.amazonaws.com. CRDs
Webhook-Konfiguration:
+ Erstellen und Lesen von sich ändernden und validierenden Webhook-Konfigurationen.
+ Konfiguration verwalten eks-load-balancing-webhook.
Diese Richtlinie wurde entwickelt, um ein umfassendes Lastenausgleichsmanagement innerhalb von Amazon-EKS-Clustern zu unterstützen, die im Automatikmodus ausgeführt werden. Es kombiniert Berechtigungen für verschiedene Operationen, darunter die Bereitstellung von Diensten, das Routing eingehender Zugriffe und die Integration mit AWS Lastenausgleichsdiensten.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Load-Balancing-Funktion ordnungsgemäß funktioniert.
## Amazon EKSNetworking ClusterPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
Amazon EKSNetworking ClusterPolicy
Diese Richtlinie gewährt die erforderlichen Berechtigungen für die Netzwerkfunktionen von Amazon EKS Auto Mode. Sie ermöglicht die effiziente Verwaltung und Konfiguration von Netzwerkressourcen innerhalb von Amazon-EKS-Clustern. Die Richtlinie umfasst folgende Berechtigungen:
Knoten- und Pod-Verwaltung:
+ Lesezugriff auf NodeClasses und deren Status.
+ Lesezugriff auf NodeClaims und deren Status.
+ Lesezugriff auf Pods.
CNI-Knotenverwaltung:
+ Berechtigungen für CNINodes und deren Status, einschließlich Erstellen, Lesen, Aktualisieren, Löschen und Patchen.
Verwaltung benutzerdefinierter Ressourcendefinitionen (CRD):
+ Alles CRDs erstellen und lesen.
+ Spezifische Verwaltung (Aktualisieren, Patchen, Löschen) des CRD cninodes.eks.amazonaws.com.
Ereignis-Management:
+ Erstellen und Patchen von Ereignissen.
Diese Richtlinie wurde entwickelt, um ein umfassendes Netzwerkmanagement innerhalb von Amazon-EKS-Clustern zu unterstützen, die im Automatikmodus ausgeführt werden. Sie kombiniert Berechtigungen für verschiedene Vorgänge, einschließlich Knoten-Netzwerkkonfiguration, CNI-Verwaltung (Container Network Interface) und zugehörige benutzerdefinierte Ressourcenverwaltung.
Die Richtlinie ermöglicht es den Netzwerkkomponenten, mit knotenbezogenen Ressourcen zu interagieren, CNI-spezifische Knotenkonfigurationen zu verwalten und benutzerdefinierte Ressourcen zu verarbeiten, die für den Netzwerkbetrieb im Cluster von entscheidender Bedeutung sind.
Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Cluster-IAM-Rolle, wenn der Automatikmodus aktiviert ist. Dadurch wird sichergestellt, dass die erforderlichen Berechtigungen vorhanden sind, damit die Netzwerkfunktion ordnungsgemäß funktioniert.
## EKSHybridAmazon-Richtlinie
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
Diese Zugriffsrichtlinie umfasst Berechtigungen, die EKS Zugriff auf die Knoten eines Clusters gewähren. Wenn dies einem Zugriffseintrag zugeordnet ist, umfasst der Zugriffsbereich in der Regel keinen Kubernetes-Namespace, sondern den Cluster. Diese Richtlinie wird von Amazon-EKS-Hybridknoten verwendet.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Kubernetes-API-Gruppen | Kubernetes, keine Ressource URLs | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## Amazon EKSCluster InsightsPolicy
**Anmerkung**
Diese Richtlinie ist nur für AWS dienstbezogene Rollen vorgesehen und kann nicht für vom Kunden verwaltete Rollen verwendet werden.
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Diese Richtlinie gewährt Lesezugriffsberechtigungen für Erkenntnisfunktionalität von Amazon-EKS-Cluster Die Richtlinie umfasst folgende Berechtigungen:
Knoten-Zugriff: – Cluster-Knoten auflisten und anzeigen – Knotenstatusinformationen lesen
DaemonSet Zugriff: — Lesezugriff auf die Kube-Proxy-Konfiguration
Diese Richtlinie wird automatisch vom EKS-Service für Cluster-Ereignisse verwaltet. Weitere Informationen finden Sie unter [Vorbereitung auf Kubernetes-Versionsupgrades und Beheben von Fehlkonfigurationen mit Cluster-Einblicken](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Diese Richtlinie gewährt die Berechtigungen, die AWS Backup benötigt, um Backups des EKS-Clusters zu verwalten und zu erstellen. Diese Richtlinie umfasst die folgenden Berechtigungen:
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Diese Richtlinie gewährt die Berechtigungen, die AWS Backup benötigt, um Backups des EKS-Clusters zu verwalten und wiederherzustellen. Diese Richtlinie umfasst die folgenden Berechtigungen:
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## Amazon EKSACKPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Diese Richtlinie gewährt die erforderlichen Berechtigungen, damit die Funktionen von AWS Controllers for Kubernetes (ACK) AWS Ressourcen von Kubernetes verwalten können. Die Richtlinie umfasst folgende Berechtigungen:
Benutzerdefiniertes ACK-Ressourcenmanagement:
+ Voller Zugriff auf alle benutzerdefinierten Ressourcen des ACK-Dienstes für mehr als 50 AWS Dienste, darunter S3, RDS, DynamoDB, Lambda, EC2 und mehr.
+ Benutzerdefinierte ACK-Ressourcendefinitionen erstellen, lesen, aktualisieren und löschen.
Namespace-Zugriff:
+ Lesezugriff auf Namespaces für die Ressourcenorganisation.
Wahl des Vorsitzenden:
+ Erstellen und lesen Sie Koordinationsverträge für die Wahl des Vorsitzenden.
+ Aktualisieren und löschen Sie bestimmte ACK Service Controller-Leases.
Ereignis-Management:
+ Ereignisse für ACK-Operationen erstellen und patchen.
Diese Richtlinie wurde entwickelt, um ein umfassendes AWS Ressourcenmanagement über APIs Kubernetes zu unterstützen. Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Capability IAM-Rolle, die Sie bei der Erstellung der ACK-Fähigkeit angeben.
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(Nur für bestimmte ACK-Service-Controller-Leases) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## EKSArgoCDClusterAmazon-Richtlinie
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Diese Richtlinie gewährt Berechtigungen auf Clusterebene, die für die Argo-CD-Funktion erforderlich sind, um Ressourcen zu erkennen und Objekte im Clusterbereich zu verwalten. Die Richtlinie umfasst folgende Berechtigungen:
Namespace-Verwaltung:
+ Namespaces für die Namespace-Verwaltung von Anwendungen erstellen, lesen, aktualisieren und löschen.
Verwaltung benutzerdefinierter Ressourcendefinitionen:
+ Argo CD-spezifisch verwalten CRDs (Anwendungen, AppProjects, ApplicationSets).
API-Erkennung:
+ Lesezugriff auf Kubernetes-API-Endpunkte zur Ressourcenerkennung.
Diese Richtlinie wurde entwickelt, um Argo-CD-Operationen auf Clusterebene zu unterstützen, einschließlich Namespace-Verwaltung und CRD-Installation. Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Capability IAM-Rolle, die Sie bei der Erstellung der Argo-CD-Funktion angeben.
| Kubernetes-API-Gruppen | Kubernetes, keine Ressource URLs | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions`(Nur Argo-CD) CRDs | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## Amazon EKSArgo CDPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Diese Richtlinie gewährt Berechtigungen auf Namespace-Ebene, die für die Argo-CD-Funktion zur Bereitstellung und Verwaltung von Anwendungen erforderlich sind. Die Richtlinie umfasst folgende Berechtigungen:
Geheime Verwaltung:
+ Voller Zugriff auf Geheimnisse für Git-Anmeldeinformationen und Clustergeheimnisse.
ConfigMap Zugriff:
+ Lesezugriff auf, um Warnungen ConfigMaps zu senden, wenn Kunden versuchen, Argo CD zu verwenden, die nicht unterstützt wird. ConfigMaps
Ereignis-Management:
+ Lesen und erstellen Sie Ereignisse für die Überwachung des Anwendungslebenszyklus.
Argo CD Ressourcenmanagement:
+ Voller Zugriff auf Anwendungen ApplicationSets, und AppProjects.
+ Verwalten Sie die Finalizer und den Status der Argo-CD-Ressourcen.
Diese Richtlinie wurde entwickelt, um Argo-CD-Operationen auf Namespace-Ebene zu unterstützen, einschließlich der Anwendungsbereitstellung und -verwaltung. Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Capability IAM-Rolle, die Sie angeben, wenn die Argo-CD-Funktion erstellt wird, und zwar für den Argo-CD-Namespace.
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## Amazon EKSKROPolicy
**ARN** – ` arn:aws: eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Diese Richtlinie gewährt Berechtigungen, die für die Kro-Funktion (Kube Resource Orchestrator) erforderlich sind, um benutzerdefinierte Kubernetes zu erstellen und zu verwalten. APIs Die Richtlinie umfasst folgende Berechtigungen:
Kro-Ressourcenverwaltung:
+ Voller Zugriff auf alle Kro-Ressourcen, einschließlich ResourceGraphDefinitions benutzerdefinierter Ressourceninstanzen.
Verwaltung benutzerdefinierter Ressourcendefinitionen:
+ APIs Benutzerdefiniert von erstellen, lesen, aktualisieren und löschen CRDs ResourceGraphDefinitions.
Wahl des Vorsitzenden:
+ Erstellen und lesen Sie Koordinationsverträge für die Wahl des Vorsitzenden.
+ Aktualisieren und löschen Sie den Kro-Controller-Lease.
Ereignis-Management:
+ Ereignisse für Kro-Operationen erstellen und patchen.
Diese Richtlinie wurde entwickelt, um eine umfassende Ressourcenzusammenstellung und ein benutzerdefiniertes API-Management über Kro zu unterstützen. Amazon EKS erstellt automatisch einen Zugriffseintrag mit dieser Zugriffsrichtlinie für die Capability IAM-Rolle, die Sie bei der Erstellung der Kro-Fähigkeit angeben.
| Kubernetes-API-Gruppen | Kubernetes-Ressourcen | Kubernetes-Verben (Berechtigungen) |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases`(Nur Kro-Controller-Lease) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Aktualisierungen für Zugriffsrichtlinien
Sehen Sie sich an, welche Aktualisierungen für Zugriffsrichtlinien seit ihrer Einführung vorgenommen wurden. Abonnieren Sie den RSS-Feed in [Dokumentverlauf](doc-history.md), um automatische Benachrichtigungen über Änderungen an dieser Seite zu erhalten.
| Änderungen | Beschreibung | Date |
| --- | --- | --- |
| Fügen Sie Richtlinien für EKS-Funktionen hinzu | Veröffentlichen`AmazonEKSACKPolicy`, `AmazonEKSArgoCDClusterPolicy``AmazonEKSArgoCDPolicy`, und `AmazonEKSKROPolicy` für die Verwaltung von EKS-Funktionen | 22. November 2025 |
| Add `AmazonEKSSecretReaderPolicy` | Fügen Sie eine neue Richtlinie für den schreibgeschützten Zugriff auf geheime Daten hinzu | 6. November 2025 |
| Richtlinie für EKS-Cluster-Erkenntnisse hinzufügen | `AmazonEKSClusterInsightsPolicy` veröffentlichen | 2. Dezember 2024 |
| Richtlinien für Amazon EKS Hybrid hinzufügen | `AmazonEKSHybridPolicy` veröffentlichen | 2. Dezember 2024 |
| Richtlinien für Amazon EKS Auto Mode hinzufügen | Diese Zugriffsrichtlinien gewähren der Cluster-IAM-Rolle und der Node-IAM-Rolle die Erlaubnis, Kubernetes aufzurufen. APIs AWS verwendet diese, um Routineaufgaben für Speicher-, Rechen- und Netzwerkressourcen zu automatisieren. | 2. Dezember 2024 |
| Add `AmazonEKSAdminViewPolicy` | Fügen Sie eine neue Richtlinie für erweiterten Zugriff auf Ansichten hinzu, einschließlich Ressourcen wie Geheimnisse. | 23. April 2024 |
| Zugriffsrichtlinien wurden eingeführt. | In Amazon EKS wurden Zugriffsrichtlinien eingeführt. | 29. Mai 2023 |
# Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden
Wenn Sie Zugriffseinträge verwenden möchten, müssen Sie zunächst den Authentifizierungsmodus des Clusters in `API_AND_CONFIG_MAP` oder `API` ändern. Dadurch wird die API für Zugriffseinträge hinzugefügt.
## AWS-Konsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, in dem Sie einen Zugriffseintrag erstellen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Der **Authentifizierungsmodus** zeigt den aktuellen Authentifizierungsmodus des Clusters. Wenn der Modus EKS-API lautet, können Sie bereits Zugriffseinträge hinzufügen und die restlichen Schritte überspringen.
1. Wählen Sie **Zugriff verwalten** aus.
1. Wählen Sie für den **Cluster-Authentifizierungsmodus** einen Modus mit der EKS-API aus. Beachten Sie, dass der Authentifizierungsmodus nicht mehr in einen Modus geändert werden kann, in dem die EKS-API und die Zugriffseinträge entfernt werden.
1. Wählen Sie **Änderungen speichern ** aus. Amazon EKS beginnt mit der Aktualisierung des Clusters, der Status des Clusters ändert sich in „Wird aktualisiert“ und die Änderung wird auf der Registerkarte **Aktualisierungsverlauf** erfasst.
1. Warten Sie, bis der Status des Clusters wieder zu „Aktiv“ wechselt. Wenn der Cluster aktiv ist, können Sie die Schritte unter [Zugriffseinträge erstellen](creating-access-entries.md) befolgen, um IAM-Prinzipalen Zugriff auf den Cluster zu gewähren.
## AWS-CLI
1. Installieren Sie die AWS-CLI wie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im * Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle* beschrieben.
1. Führen Sie den folgenden Befehl aus. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters. Wenn Sie die `ConfigMap`-Methode dauerhaft deaktivieren möchten, ersetzen Sie `API_AND_CONFIG_MAP` durch `API`.
Amazon EKS beginnt mit der Aktualisierung des Clusters, der Status des Clusters ändert sich in „WIRD AKTUALISIERT“ und die Änderung wird in der ** aws eks list-updates ** aufgezeichnet.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Warten Sie, bis der Status des Clusters wieder zu „Aktiv“ wechselt. Wenn der Cluster aktiv ist, können Sie die Schritte unter [Zugriffseinträge erstellen](creating-access-entries.md) befolgen, um IAM-Prinzipalen Zugriff auf den Cluster zu gewähren.
## Erforderliche Plattformversion
Um *Zugriffseinträge* verwenden zu können, muss der Cluster über eine Plattformversion verfügen, die mit der in der folgenden Tabelle aufgeführten Version identisch oder höher ist, oder über eine Kubernetes-Version, die höher ist als die in der Tabelle aufgeführten Versionen. Wenn Ihre Kubernetes-Version nicht aufgeführt ist, unterstützen alle Plattformversionen Zugriffseinträge.
| Kubernetes-Version | Plattformversion |
| --- | --- |
| Nicht aufgelistet | Alle unterstützt |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Weitere Informationen finden Sie unter [platform-versions](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Zugriffseinträge erstellen
Berücksichtigen Sie Folgendes, bevor Sie Zugriffseinträge erstellen:
+ Ein ordnungsgemäß eingerichteter Authentifizierungsmodus. Siehe [Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden](setting-up-access-entries.md).
+ Ein *Zugriffseintrag* enthält den Amazon-Ressourcennamen (ARN) genau eines vorhandenen IAM-Prinzipals. Ein IAM-Prinzipal kann nicht in mehreren Zugriffseinträgen enthalten sein. Zusätzliche Überlegungen zu dem von Ihnen angegebenen ARN:
+ In den bewährten Methoden für IAM wird empfohlen, für den Zugriff auf Ihren Cluster IAM-*Rollen* mit kurzfristigen Anmeldeinformationen zu verwenden anstatt IAM-*Benutzer* mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
+ Ein ARN für eine IAM-Rolle *kann* einen Pfad enthalten. ARNs in `aws-auth` `ConfigMap`-Einträgen können *keinen* Pfad enthalten. Ihr ARN kann beispielsweise ` arn:aws:iam::<111122223333>:role/` oder ` arn:aws:iam::<111122223333>:role/` lauten.
+ Wenn der Typ des Zugriffseintrags nicht `STANDARD` ist (siehe nächste Überlegung zu Typen), muss sich der ARN im gleichen AWS-Region befinden wie Ihr Cluster. Wenn der Typ `STANDARD` ist, kann sich der ARN im gleichen oder in einem anderen AWS-Region befinden wie der Cluster.
+ Nach der Erstellung des Zugriffseintrags kann der IAM-Prinzipal nicht mehr geändert werden.
+ Sollten Sie den IAM-Prinzipal mit diesem ARN löschen, wird der Zugriffseintrag nicht automatisch gelöscht. Es empfiehlt sich, den Zugriffseintrag mit einem ARN für einen gelöschten IAM-Prinzipal zu löschen. Wenn Sie den Zugriffseintrag nicht löschen und den IAM-Prinzipal erneut erstellen, funktioniert der Zugriffseintrag nicht, selbst wenn er dieselbe ARN aufweist. Dies liegt daran, dass, obwohl die ARN für den neu erstellten IAM-Prinzipal dieselbe ist, die `roleID` oder `userID` (Sie können dies mit dem AWS-CLI-Befehl `aws sts get-caller-identity` sehen) für den neu erstellten IAM-Prinzipal anders ist als für den ursprünglichen IAM-Prinzipal. Auch wenn Sie das `roleID` oder `userID` des IAM-Prinzipals für einen Zugriffseintrag nicht sehen, speichert Amazon EKS es mit dem Zugriffseintrag.
+ Jeder Zugriffseintrag hat einen *Typ*. Der Typ des Zugriffseintrags hängt vom Typ der Ressource ab, der er zugeordnet ist, und definiert nicht die Berechtigungen. Wenn Sie keinen Typ angeben, wird er von Amazon EKS automatisch auf `STANDARD` festgelegt
+ `EC2_LINUX` – Für eine IAM-Rolle, die mit selbstverwalteten Linux- oder Bottlerocket-Knoten verwendet wird
+ `EC2_WINDOWS` – Für eine IAM-Rolle, die mit selbstverwalteten Windows-Knoten verwendet wird
+ `FARGATE_LINUX` – Für eine mit AWS Fargate verwendete IAM-Rolle (Fargate)
+ `HYBRID_LINUX` – Für eine IAM-Rolle, die mit Hybridknoten verwendet wird
+ `STANDARD` – Standardtyp, falls keiner angegeben ist
+ `EC2` – Für benutzerdefinierte Knotenklassen im EKS Auto Mode. Weitere Informationen finden Sie unter [Knotenklassen-Zugriffseintrag erstellen](create-node-class.md#auto-node-access-entry).
+ Nach der Erstellung des Zugriffseintrags ist es nicht möglich, den Typ zu ändern.
+ Es ist nicht erforderlich, einen Zugriffseintrag für eine IAM-Rolle zu erstellen, die für eine verwaltete Knotengruppe oder ein Fargate-Profil verwendet wird. EKS erstellt Zugriffseinträge (sofern aktiviert) oder aktualisiert die Konfigurationszuordnung der Authentifizierung (sofern keine Zugriffseinträge verfügbar sind).
+ Wenn der Typ des Zugriffseintrags `STANDARD` lautet, können Sie einen *Benutzernamen* für den Zugriffseintrag angeben. Wenn Sie keinen Wert für den Benutzernamen angeben, legt Amazon EKS einen der folgenden Werte für Sie fest, abhängig vom Typ des Zugriffseintrags und davon, ob es sich bei dem von Ihnen angegebenen IAM-Prinzipal um eine IAM-Rolle oder um einen IAM-Benutzer handelt. Sofern Sie keinen spezifischen Grund für die Angabe eines eigenen Benutzernamens haben, empfehlen wir, keinen anzugeben und ihn automatisch von Amazon EKS generieren zu lassen. Beachten Sie bei Angabe eines eigenen Benutzernamens Folgendes:
+ Er darf nicht mit `system:`, `eks:`, `aws:`, `amazon:` oder `iam:` beginnen.
+ Bei einem Benutzername für eine IAM-Rolle empfiehlt es sich, am Ende des Benutzernamens `{{SessionName}}` oder `{{SessionNameRaw}}` hinzuzufügen. Wenn Sie Ihrem Benutzernamen `{{SessionName}}` oder `{{SessionNameRaw}}` hinzufügen, muss der Benutzername *vor* \$1\$1SessionName\$1\$1 einen Doppelpunkt enthalten. Wenn diese Rolle übernommen wird, wird der Name der AWS-STS-Sitzung, der bei der Übernahme der Rolle angegeben wurde, automatisch an den Cluster übergeben und in den CloudTrail-Protokollen angezeigt. Der Benutzername `john{{SessionName}}` ist beispielsweise nicht zulässig. Er müsste `:john{{SessionName}}` oder `jo:hn{{SessionName}}` lauten. Der Doppelpunkt muss sich nur vor `{{SessionName}}` befinden. Der von Amazon EKS generierte Benutzername in der folgenden Tabelle enthält einen ARN. Da ein ARN Doppelpunkte enthält, erfüllt er diese Anforderung. Der Doppelpunkt ist nicht erforderlich, wenn Sie `{{SessionName}}` nicht in Ihren Benutzernamen einschließen. Beachten Sie, dass in `{{SessionName}}` das Sonderzeichen „@“ im Sitzungsnamen durch „-“ ersetzt wird. `{{SessionNameRaw}}` behält alle Sonderzeichen im Sitzungsnamen bei.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/eks/latest/userguide/creating-access-entries.html)
Sie können den Benutzernamen ändern, nachdem der Zugriffseintrag erstellt wurde.
+ Wenn der Typ eines Zugriffseintrags `STANDARD` ist und Sie die Kubernetes-RBAC-Autorisierung verwenden möchten, können Sie dem Zugriffseintrag einen oder mehrere *Gruppennamen* hinzufügen. Gruppennamen können nach der Erstellung eines Zugriffseintrags hinzugefügt und entfernt werden. Damit der IAM-Prinzipal Zugriff auf Kubernetes-Objekte in Ihrem Cluster hat, müssen Sie rollenbasierte Autorisierungsobjekte (RBAC) für Kubernetes erstellen und verwalten. Erstellen Sie Kubernetes `RoleBinding` oder `ClusterRoleBinding`-Objekte in Ihrem Cluster, die den Gruppennamen als `subject` für `kind: Group` angeben. Kubernetes autorisiert den IAM-Prinzipalzugriff auf alle Cluster-Objekte, die Sie in einem Kubernetes `Role`- oder `ClusterRole`-Objekt angegeben haben, das Sie auch in der `roleRef` Ihrer Bindung angegeben haben. Wenn Sie Gruppennamen angeben, empfehlen wir Ihnen, sich mit den rollenbasierten Autorisierungsobjekten (RBAC) von Kubernetes vertraut zu machen. Weitere Informationen finden Sie unter [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
**Wichtig**
Amazon EKS überprüft nicht, ob die in Ihrem Cluster vorhandenen Kubernetes-RBAC-Objekte die von Ihnen angegebenen Gruppennamen enthalten. Wenn Sie beispielsweise einen Zugriffseintrag für eine Gruppe erstellen, die derzeit nicht vorhanden ist, erstellt EKS die Gruppe, anstatt eine Fehlermeldung auszugeben.
Anstelle oder zusätzlich zur Autorisierung des IAM-Prinzips für den Zugriff auf Kubernetes-Objekte in Ihrem Cluster durch Kubernetes können Sie Amazon-EKS-*Zugriffsrichtlinien* einem Zugriffseintrag zuordnen. Amazon EKS autorisiert für IAM-Prinzipale den Zugriff auf Kubernetes-Objekte in Ihrem Cluster mit den in der Zugriffsrichtlinie festgelegten Berechtigungen. Sie können die Berechtigungen einer Zugriffsrichtlinie auf von Ihnen angegebene Kubernetes-Namespaces beschränken. Für die Verwendung von Zugriffsrichtlinien ist keine Verwaltung von Kubernetes RBAC-Objekten erforderlich. Weitere Informationen finden Sie unter [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md).
+ Wenn Sie einen Zugriffseintrag mit dem Typ `EC2_LINUX` oder `EC2_Windows` erstellen, muss der IAM-Prinzipal, der den Zugriffseintrag erstellt, über die Berechtigung `iam:PassRole` verfügen. Weitere Informationen finden Sie unter [Erteilen von Berechtigungen, mit denen ein Benutzer eine Rolle an einen AWS-Service übergeben kann](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) im *IAM-Benutzerhandbuch*.
+ Ähnlich wie beim standardmäßigen [IAM-Verhalten](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency) sind die Erstellung und Aktualisierung von Zugriffseinträgen letztlich konsistent und es kann mehrere Sekunden dauern, bis sie wirksam werden, nachdem der erste API-Aufruf erfolgreich abgeschlossen wurde. Sie müssen Ihre Anwendungen unter Berücksichtigung dieser potenziellen Verzögerungen konzipieren. Es empfiehlt sich, in die kritischen, hochverfügbaren Code-Pfade Ihrer Anwendung keine Erstellungen oder Aktualisierungen von Zugriffseinträgen einzuschließen. Nehmen Sie -Änderungen stattdessen in einer separaten Initialisierungs- oder Einrichtungsroutine vor, die seltener ausgeführt wird. Vergewissern Sie sich auch, dass die Änderungen weitergegeben wurden, bevor die Produktionsarbeitsabläufe davon abhängen.
+ Zugriffseinträge unterstützen keine [serviceverknüpften Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Sie können keine Zugriffseinträge erstellen, bei denen die Haupt-ARN eine serviceverknüpfte Rolle ist. Sie können serviceverknüpfte Rollen anhand ihrer ARN im Format ` arn:aws:iam::*:role/aws-service-role/*` identifizieren.
Sie können einen Zugriffseintrag über die AWS-Managementkonsole oder mithilfe der AWS CLI erstellen.
## AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, in dem Sie einen Zugriffseintrag erstellen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie **Zugriffseintrag erstellen** aus.
1. Wählen Sie unter **IAM-Prinzipal** eine bereits vorhandene IAM-Rolle oder einen bereits vorhandenen IAM-Benutzer aus. In den bewährten Methoden für IAM wird empfohlen, für den Zugriff auf Ihren Cluster IAM-*Rollen* mit kurzfristigen Anmeldeinformationen zu verwenden anstatt IAM-*Benutzer* mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
1. Wählen Sie unter **Typ** die Option **EC2 Linux** oder **EC2 Windows** aus, wenn sich der Zugriffseintrag auf die Knotenrolle bezieht, die für selbstverwaltete Amazon-EC2-Knoten verwendet wird. Übernehmen Sie andernfalls die Standardeinstellung (**Standard**).
1. Wenn Sie unter **Typ** die Option **Standard** ausgewählt haben, können Sie bei Bedarf unter **Benutzername** einen Benutzernamen angeben.
1. Wenn Sie unter **Typ** die Option **Standard** ausgewählt haben und die Kubernetes-RBAC-Autorisierung für den IAM-Prinzipal verwenden möchten, können Sie unter **Gruppen** einen oder mehrere Namen angeben. Wenn Sie keine Gruppennamen angeben und die Amazon-EKS-Autorisierung verwenden möchten, können Sie in einem späteren Schritt (oder nach der Erstellung des Zugriffseintrags) eine Zugriffsrichtlinie zuordnen.
1. (Optional) Weisen Sie dem Zugriffseintrag unter **Tags** Beschriftungen zu. So können Sie beispielsweise ganz einfach nach allen Ressourcen mit dem gleichen Tag suchen.
1. Wählen Sie **Weiter** aus.
1. Wenn Sie auf der Seite **Zugriffsrichtlinie hinzufügen** den Typ **Standard** ausgewählt haben und Amazon EKS dem IAM-Prinzipal Berechtigungen für die Kubernetes-Objekte in Ihrem Cluster gewähren soll, führen Sie die folgenden Schritte aus. Klicken Sie andernfalls auf **Next** (Weiter).
1. Wählen Sie unter **Richtlinienname** eine Zugriffsrichtlinie aus. Sie können die Berechtigungen der Zugriffsrichtlinien nicht anzeigen, sie enthalten jedoch ähnliche Berechtigungen wie die benutzerorientierten `ClusterRole`-Objekte von Kubernetes. Weitere Informationen finden Sie unter[Benutzerorientierte Rollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) in der Kubernetes-Dokumentation.
1. Wählen Sie eine der folgenden Optionen:
+ **Cluster** – Wählen Sie diese Option aus, wenn Amazon EKS den IAM-Prinzipal so autorisieren soll, dass er für alle Kubernetes-Objekte in Ihrem Cluster über die in der Zugriffsrichtlinie festgelegten Berechtigungen verfügt.
+ **Kubernetes-Namespace** – Wählen Sie diese Option aus, wenn Amazon EKS den IAM-Prinzipal so autorisieren soll, dass er für alle Kubernetes-Objekte in einem spezifischen Kubernetes-Namespace Ihres Clusters über die in der Zugriffsrichtlinie festgelegten Berechtigungen verfügt. Geben Sie unter **Namespace** den Namen des Kubernetes-Namespace in Ihrem Cluster ein. Wenn Sie zusätzliche Namespaces hinzufügen möchten, wählen Sie **Neuen Namespace hinzufügen** aus und geben Sie den Namespace-Namen ein.
1. Wenn Sie weitere Richtlinien hinzufügen möchten, wählen Sie **Richtlinie hinzufügen** aus. Sie können für jede Richtlinie unterschiedliche Geltungsbereiche festlegen, aber jede Richtlinie kann nur einmal hinzugefügt werden.
1. Wählen Sie **Weiter** aus.
1. Überprüfen Sie die Konfiguration für Ihren Zugriffseintrag. Sollten Sie einen Fehler entdecken, wählen Sie **Zurück** aus, um schrittweise zurück zu navigieren und den Fehler zu korrigieren. Ist die Konfiguration korrekt, wählen Sie **Erstellen** aus.
## AWS-CLI
1. Installieren Sie die AWS-CLI wie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle beschrieben.
1. Um einen Zugriffseintrag zu erstellen, können Sie eines der folgenden Beispiele verwenden:
+ Erstellen Sie einen Zugriffseintrag für eine selbstverwaltete Amazon-EC2-Linux-Knotengruppe. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *EKS-my-cluster-self-managed-ng-1* durch den Namen Ihrer [Knoten-IAM-Rolle](create-node-role.md). Wenn es sich bei Ihrer Knotengruppe um eine Windows-Knotengruppe handelt, ersetzen Sie *EC2\$1Linux* durch `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Bei Angabe eines anderen Typs als `STANDARD` kann die Option `--kubernetes-groups` nicht verwendet werden. Sie können diesem Zugriffseintrag keine Zugriffsrichtlinie zuordnen, da der Typ nicht den Wert `STANDARD` hat.
+ Erstellen Sie einen Zugriffseintrag, der eine IAM-Rolle zulässt, die nicht für eine selbstverwaltete Amazon-EC2-Knotengruppe verwendet wird, mit der Kubernetes den Zugriff auf Ihren Cluster autorisieren soll. Ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *my-role* durch den Namen Ihrer IAM-Rolle. Ersetzen Sie *Betrachter* durch den Namen einer Gruppe, die Sie in Kubernetes `RoleBinding` oder einem `ClusterRoleBinding`-Objekt in Ihrem Cluster angegeben haben.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Erstellen Sie einen Zugriffseintrag, der es einem IAM-Benutzer ermöglicht, sich bei Ihrem Cluster zu authentifizieren. Dieses Beispiel soll zeigen, dass es diese Möglichkeit gibt. In den bewährten Methoden für IAM wird empfohlen, für den Zugriff auf Ihren Cluster IAM-*Rollen* mit kurzfristigen Anmeldeinformationen zu verwenden anstatt IAM-*Benutzer* mit langfristigen Anmeldeinformationen. Weitere Informationen finden Sie unter [Menschliche Benutzer auffordern, den Verbund mit einem Identitätsanbieter zu verwenden, um mit temporären Anmeldeinformationen auf AWS zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) im *IAM-Benutzerhandbuch*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Wenn dieser Benutzer mehr Zugriff auf Ihren Cluster haben soll als ihm durch die Berechtigungen in den Kubernetes-API-Erkennungsrollen gewährt wird, müssen Sie dem Zugriffseintrag eine Zugriffsrichtlinie zuordnen, da die Option `--kubernetes-groups` nicht verwendet wird. Weitere Informationen finden Sie unter [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md) und [API-Erkennungsrollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) in der Kubernetes-Dokumentation.
# Zugriffseinträge aktualisieren
Sie können einen Zugriffseintrag über die AWS-Managementkonsole oder mithilfe der AWS-CLI aktualisieren.
## AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, in dem Sie einen Zugriffseintrag erstellen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie den Zugriffseintrag aus, den Sie aktualisieren möchten.
1. Wählen Sie **Bearbeiten** aus.
1. Unter **Benutzername** können Sie den vorhandenen Wert ändern.
1. Unter **Gruppen** können Sie Gruppennamen entfernen oder neue Gruppennamen hinzufügen. Die Gruppennamen **system:nodes** und **system:bootstrappers** dürfen nicht entfernt werden, sofern vorhanden. Wenn Sie diese Gruppen entfernen, funktioniert Ihr Cluster unter Umständen nicht mehr ordnungsgemäß. Wenn Sie keine Gruppennamen angeben und die Amazon-EKS-Autorisierung verwenden möchten, ordnen Sie in einem späteren Schritt eine [Zugriffsrichtlinie](access-policies.md) zu.
1. Unter **Tags** können Sie dem Zugriffseintrag Beschriftungen zuweisen. So können Sie beispielsweise ganz einfach nach allen Ressourcen mit dem gleichen Tag suchen. Außerdem können Sie vorhandene Tags entfernen.
1. Wählen Sie **Änderungen speichern ** aus.
1. Informationen zum Zuordnen einer Zugriffsrichtlinie zu dem Eintrag finden Sie unter [Zugriffsrichtlinien mit Zugriffseinträgen verknüpfen](access-policies.md).
## AWS-CLI
1. Installieren Sie die AWS-CLI wie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle beschrieben.
1. Um einen Zugriffseintrag zu aktualisieren, ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-Konto-ID und *EKS-my-cluster-my-namespace-Viewers* durch den Namen einer IAM-Rolle.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
Die Option `--kubernetes-groups` kann nur verwendet werden, wenn der Zugriffseintrag den Typ `STANDARD` hat. Auch kann eine Zugriffsrichtlinie nur einem Zugriffseintrag mit dem Typ `STANDARD` zugeordnet werden.
# Zugriffseinträge löschen
Wenn Sie einen Zugriffseintrag versehentlich gelöscht haben, können Sie ihn jederzeit erneut erstellen. Wenn dem zu löschenden Zugriffseintrag Zugriffsrichtlinien zugeordnet sind, werden die Zuordnungen automatisch gelöscht. Es ist nicht erforderlich, die Zuordnung von Zugriffsrichtlinien zu einem Zugriffseintrag vor dem Löschen aufzuheben.
Sie können einen Zugriffseintrag über die AWS-Managementkonsole oder mithilfe der AWS-CLI löschen.
## AWS-Managementkonsole
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie den Namen des Clusters aus, aus dem Sie einen Zugriffseintrag löschen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie in der Liste **Zugriffseinträge** den Zugriffseintrag aus, den Sie löschen möchten.
1. Wählen Sie Delete.
1. Wählen Sie im Bestätigungs-Dialogfeld die Option **Delete** (Löschen).
## AWS-CLI
1. Installieren Sie die AWS-CLI wie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle beschrieben.
1. Um einen Zugriffseintrag zu löschen, ersetzen Sie *my-cluster* durch den Namen Ihres Clusters, *111122223333* durch Ihre AWS-ID und *my-role* durch den Namen der IAM-Rolle, die keinen Zugriff mehr auf Ihren Cluster haben soll.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# Festlegen eines benutzerdefinierten Benutzernamens für EKS-Zugriffseinträge
Beim Erstellen von Zugriffseinträgen für Amazon EKS können Sie entweder den automatisch generierten Benutzernamen verwenden oder einen benutzerdefinierten Benutzernamen angeben. Auf dieser Seite werden beide Optionen erläutert und Sie werden durch die Einrichtung eines benutzerdefinierten Benutzernamens geführt.
## -Übersicht
Der Benutzername in einem Zugriffseintrag wird verwendet, um den IAM-Prinzipal in Kubernetes-Protokollen und Prüfpfaden zu identifizieren. Standardmäßig generiert Amazon EKS einen Benutzernamen basierend auf der ARN der IAM-Identität. Sie können bei Bedarf jedoch einen benutzerdefinierten Benutzernamen angeben.
## Generierung des Standard-Benutzernamens
Wenn Sie keinen Wert für den Benutzernamen angeben, generiert Amazon EKS automatisch einen Benutzernamen basierend auf der IAM-Identität:
+ **Für IAM-Benutzer**:
+ EKS legt den Kubernetes-Benutzernamen auf die ARN des IAM-Benutzers fest
+ Beispiel:
```
{arn-aws}iam::<111122223333>:user/
```
+ **Für IAM-Rollen**:
+ EKS legt den Kubernetes-Benutzernamen basierend auf der ARN der IAM-Rolle fest
+ Der STS-ARN der Rolle, wenn sie angenommen wird. Amazon EKS fügt am Ende der Rolle `{{SessionName}}` hinzu. Wenn der ARN der von Ihnen angegebenen Rolle einen Pfad enthalten hat, wird dieser von Amazon EKS im generierten Benutzernamen entfernt.
+ Beispiel:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
Sofern Sie keinen bestimmten Grund haben, Ihren eigenen Benutzernamen anzugeben, empfehlen wir Ihnen, keinen anzugeben und ihn von Amazon EKS automatisch für Sie generieren zu lassen.
## Festlegen eines benutzerdefinierten Benutzernamens
Beim Erstellen eines Zugriffseintrags können Sie mithilfe des `--username`-Parameters einen benutzerdefinierten Benutzernamen angeben:
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Anforderungen für benutzerdefinierte Benutzernamen
Wenn Sie einen benutzerdefinierten Benutzernamen angeben:
+ Der Benutzername darf nicht mit `system:`, `eks:`, `aws:`, `amazon:` oder `iam:` beginnen.
+ Bei einem Benutzername für eine IAM-Rolle empfiehlt es sich, am Ende des Benutzernamens `{{SessionName}}` oder `{{SessionNameRaw}}` hinzuzufügen.
+ Wenn Sie Ihrem Benutzernamen eines `{{SessionName}}` oder `{{SessionNameRaw}}` hinzufügen, muss der Benutzername einen Doppelpunkt *vor* \$1\$1SessionName\$1\$1 enthalten.
# Erstellen Sie mithilfe einer Zugriffsrichtlinie und der AWS-CLI einen Zugriffseintrag für eine IAM-Rolle oder einen IAM-Benutzer
Erstellen Sie Amazon-EKS-Zugriffseinträge, die von AWS verwaltete EKS-Zugriffsrichtlinien verwenden, um IAM-Identitäten standardisierte Berechtigungen für den Zugriff auf und die Verwaltung von Kubernetes-Clustern zu gewähren.
## Übersicht
Zugriffseinträge in Amazon EKS legen fest, wie IAM-Identitäten (Benutzer und Rollen) auf Ihre Kubernetes-Cluster zugreifen und mit diesen interagieren können. Durch die Erstellung von Zugriffseinträgen mit EKS-Zugriffsrichtlinien können Sie:
+ Bestimmten IAM-Benutzern oder -Rollen die Berechtigung zum Zugriff auf Ihren EKS-Cluster gewähren
+ Berechtigungen mithilfe von AWS-verwalteten EKS-Zugriffsrichtlinien steuern, die standardisierte, vordefinierte Berechtigungssätze bieten
+ Berechtigungen auf bestimmte Namespaces oder clusterweit beschränken
+ Zugriffsverwaltung vereinfachen, ohne die `aws-auth` ConfigMap zu ändern oder Kubernetes-RBAC-Ressourcen zu erstellen
+ AWS-integrierten Ansatz für die Kubernetes-Zugriffskontrolle verwenden, der gängige Anwendungsfälle abdeckt und gleichzeitig bewährte Sicherheitsmethoden einhält
Dieser Ansatz wird für die meisten Anwendungsfälle empfohlen, da er von AWS verwaltete, standardisierte Berechtigungen bietet, ohne dass eine manuelle Kubernetes-RBAC-Konfiguration erforderlich ist. EKS-Zugriffsrichtlinien machen die manuelle Konfiguration von Kubernetes-RBAC-Ressourcen überflüssig und bieten vordefinierte Berechtigungssätze, die gängige Anwendungsfälle abdecken.
## Voraussetzungen
+ Der *Authentifizierungsmodus* Ihres Clusters muss konfiguriert sein, um *Zugriffseinträge* zu ermöglichen. Weitere Informationen finden Sie unter [Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden](setting-up-access-entries.md).
+ Installieren und konfigurieren Sie die AWS CLI wie im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle unter [Installieren](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) beschrieben.
## Schritt 1: Zugriffseintrag definieren
1. Suchen Sie die ARN der IAM-Identität, z. B. eines Benutzers oder einer Rolle, der Sie Berechtigungen gewähren möchten.
+ Jede IAM-Identität kann nur einen EKS-Zugriffseintrag haben.
1. Legen Sie fest, ob die Berechtigungen der Amazon-EKS-Zugriffsrichtlinie nur für einen bestimmten Kubernetes-Namespace oder für den gesamten Cluster gelten sollen.
+ Wenn Sie die Berechtigungen auf einen bestimmten Namespace beschränken möchten, notieren Sie sich den Namen des Namespace.
1. Wählen Sie die gewünschte EKS-Zugriffsrichtlinie für die IAM-Identität aus. Diese Richtlinie gewährt Berechtigungen innerhalb des Clusters. Notieren Sie sich die ARN der Richtlinie.
+ Eine Liste der Richtlinien finden Sie unter [Verfügbare Zugriffsrichtlinien](access-policy-permissions.md).
1. Prüfen Sie, ob der automatisch generierte Benutzername für den Zugriffseintrag geeignet ist oder ob Sie einen Benutzernamen manuell angeben müssen.
+ AWS generiert diesen Wert automatisch basierend auf der IAM-Identität. Sie können einen benutzerdefinierten Benutzernamen festlegen. Dieser wird in den Kubernetes-Protokollen angezeigt.
+ Weitere Informationen finden Sie unter [Festlegen eines benutzerdefinierten Benutzernamens für EKS-Zugriffseinträge](set-custom-username.md).
## Schritt 2: Zugriffseintrag erstellen
Nachdem Sie den Zugriffseintrag geplant haben, erstellen Sie ihn mithilfe der AWS-CLI.
Das folgende Beispiel deckt die meisten Anwendungsfälle ab. [Sehen Sie sich die CLI-Referenz für alle Konfigurationsoptionen an](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Im nächsten Schritt fügen Sie die Zugriffsrichtlinie hinzu.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Schritt 3: Zugriffsrichtlinie zuordnen
Der Befehl unterscheidet sich je nachdem, ob Sie die Richtlinie auf einen bestimmten Kubernetes-Namespace beschränken möchten.
Sie benötigen die ARN der Zugriffsrichtlinie. Überprüfen Sie die [verfügbaren Zugriffsrichtlinien](access-policy-permissions.md).
### Erstellung einer Richtlinie ohne Namespace-Gültigkeitsbereich
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Mit Namespace-Gültigkeitsbereich erstellen
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Nächste Schritte
+ [Erstellung einer kubeconfig für die Verwendung von kubectl mit einer IAM-Identität](create-kubeconfig.md)
# Erstellung eines Zugriffseintrags mithilfe von Kubernetes-Gruppen über die AWS CLI
Erstellen Sie Amazon-EKS-Zugriffseinträge, die Kubernetes-Gruppen zur Autorisierung verwenden und eine manuelle RBAC-Konfiguration erfordern.
**Anmerkung**
Für die meisten Anwendungsfälle empfehlen wir die Verwendung von EKS-Zugriffsrichtlinien anstelle des auf dieser Seite beschriebenen Ansatzes mit Kubernetes-Gruppen. EKS-Zugriffsrichtlinien bieten eine einfachere, besser in AWS integrierte Möglichkeit zur Zugriffsverwaltung ohne manuelle RBAC-Konfiguration. Verwenden Sie den Kubernetes-Gruppenansatz nur, wenn Sie eine detailliertere Steuerung benötigen, als die EKS-Zugriffsrichtlinien bieten.
## Übersicht
Zugriffseinträge definieren, wie IAM-Identitäten (Benutzer und Rollen) auf Ihre Kubernetes-Cluster zugreifen. Der Kubernetes-Gruppenansatz gewährt IAM-Benutzern oder -Rollen die Berechtigung, über standardmäßige Kubernetes-RBAC-Gruppen auf Ihren EKS-Cluster zuzugreifen. Diese Methode erfordert die Erstellung und Verwaltung von Kubernetes-RBAC-Ressourcen (Roles, RoleBindings, ClusterRoles und ClusterRoleBindings). Sie wird empfohlen, wenn Sie stark angepasste Berechtigungssätze und komplexe Autorisierungsanforderungen benötigen oder konsistente Zugriffskontrollmuster in hybriden Kubernetes-Umgebungen beibehalten möchten.
Dieses Thema behandelt nicht das Erstellen von Zugriffseinträgen für IAM-Identitäten, die für Amazon-EC2-Instances zum Beitritt zu EKS-Clustern verwendet werden.
## Voraussetzungen
+ Der *Authentifizierungsmodus* Ihres Clusters muss konfiguriert sein, um *Zugriffseinträge* zu ermöglichen. Weitere Informationen finden Sie unter [Ändern des Authentifizierungsmodus, um Zugriffseinträge zu verwenden](setting-up-access-entries.md).
+ Installieren und konfigurieren Sie die AWS CLI wie im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle unter [Installieren](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) beschrieben.
+ Vertrautheit mit Kubernetes RBAC wird empfohlen. Weitere Informationen finden Sie unter [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
## Schritt 1: Zugriffseintrag definieren
1. Suchen Sie die ARN der IAM-Identität, beispielsweise eines Benutzers oder einer Rolle, der bzw. der Sie Berechtigungen gewähren möchten.
+ Jede IAM-Identität kann nur einen EKS-Zugriffseintrag haben.
1. Legen Sie fest, welche Kubernetes-Gruppen Sie dieser IAM-Identität zuordnen möchten.
+ Sie müssen vorhandene Kubernetes-`Role`/`ClusterRole` und `RoleBinding`/`ClusterRoleBinding`-Ressourcen erstellen oder verwenden, die auf diese Gruppen verweisen.
1. Prüfen Sie, ob der automatisch generierte Benutzername für den Zugriffseintrag geeignet ist oder ob Sie einen Benutzernamen manuell angeben müssen.
+ AWS generiert diesen Wert automatisch basierend auf der IAM-Identität. Sie können einen benutzerdefinierten Benutzernamen festlegen. Dieser wird in den Kubernetes-Protokollen angezeigt.
+ Weitere Informationen finden Sie unter [Festlegen eines benutzerdefinierten Benutzernamens für EKS-Zugriffseinträge](set-custom-username.md).
## Schritt 2: Zugriffseintrag mit Kubernetes-Gruppen erstellen
Nachdem Sie den Zugriffseintrag geplant haben, erstellen Sie ihn mithilfe der AWS CLI mit den entsprechenden Kubernetes-Gruppen.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Ersetzen Sie:
+ `` durch den Namen Ihres EKS-Clusters
+ `` durch die ARN des IAM-Benutzers oder der IAM-Rolle
+ `` durch eine durch Kommas getrennte Liste von Kubernetes-Gruppen (z. B. „system:developers,system:readers“).
[Sehen Sie sich die CLI-Referenz für alle Konfigurationsoptionen an](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Schritt 3: Kubernetes-RBAC konfigurieren
Damit der IAM-Prinzipal Zugriff auf Kubernetes-Objekte in Ihrem Cluster hat, müssen Sie rollenbasierte Zugriffskontrollobjekte (RBAC) für Kubernetes erstellen und verwalten:
1. Erstellen Sie Kubernetes `Role` oder `ClusterRole`-Objekte, welche die Berechtigungen definieren.
1. Erstellen Sie Kubernetes `RoleBinding` oder `ClusterRoleBinding`-Objekte in Ihrem Cluster, die den Gruppennamen als `subject` für `kind: Group` angeben.
Ausführliche Informationen zum Konfigurieren von Gruppen und Berechtigungen in Kubernetes finden Sie unter [Verwendung der RBAC-Autorisierung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
## Nächste Schritte
+ [Erstellung einer kubeconfig für die Verwendung von kubectl mit einer IAM-Identität](create-kubeconfig.md)
# Gewähren Sie IAM-Benutzern Zugriff auf Kubernetes mit einem ConfigMap
**Wichtig**
Der `aws-auth ConfigMap` ist veraltet. Die empfohlene Methode zur Verwaltung des Zugriffs auf Kubernetes finden Sie unter. APIs [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md)
Zugriff auf Ihren Cluster mit einem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) wird durch [AWS IAM Authenticator für Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) aktiviert, das in der Amazon-EKS-Steuerebene ausgeführt wird. Der Authenticator erhält seine Konfigurationsinformationen von `aws-auth` `ConfigMap`. Alle `aws-auth` `ConfigMap`-Einstellungen finden Sie unter [Vollständiges Konfigurationsformat](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) auf GitHub.
## Hinzufügen von IAM-Prinzipal zu Ihrem Amazon EKS-Cluster
Wenn Sie einen Amazon-EKS-Cluster erstellen, werden dem [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal), der den Cluster erstellt, automatisch `system:masters`-Berechtigungen in der rollenbasierten Konfiguration für Zugriffskontrolle (RBAC) des Clusters in der Amazon-EKS-Steuerebene gewährt. Dieser Prinzipal wird in keiner sichtbaren Konfiguration angezeigt. Achten Sie daher darauf, welcher Prinzipal den Cluster ursprünglich erstellt hat. Um zusätzlichen IAM-Prinzipalen die Möglichkeit zu geben, mit Ihrem Cluster zu interagieren, bearbeiten Sie den `aws-auth ConfigMap` in Kubernetes und erstellen Sie ein Kubernetes-`rolebinding` oder -`clusterrolebinding` mit dem Namen eines `group`, das Sie im `aws-auth ConfigMap` angeben.
**Anmerkung**
Weitere Informationen zur Konfiguration der rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes finden Sie unter [Verwendung der RBAC-Autorisierung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
1. Bestimmen Sie, welche Anmeldeinformationen `kubectl` für den Zugriff auf Ihren Cluster verwendet. Amazon Resource Name (ARN)Auf Ihrem Computer können Sie mit dem folgenden Befehl sehen, welche Anmeldeinformationen `kubectl` verwendet. *\$1/.kube/config*Ersetzen Sie ihn durch den Pfad zu Ihrer `kubeconfig` Datei, wenn Sie nicht den Standardpfad verwenden.
```
cat ~/.kube/config
```
Eine Beispielausgabe sieht wie folgt aus.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
In der vorherigen Beispielausgabe werden die Anmeldeinformationen für einen Benutzer mit dem Namen *admin* für einen Cluster mit dem Namen *my-cluster* konfiguriert. Wenn dies der Benutzer ist, der den Cluster erstellt hat, hat er bereits Zugriff auf Ihren Cluster. Wenn es nicht der Benutzer ist, der den Cluster erstellt hat, müssen Sie die verbleibenden Schritte ausführen, um den Cluster-Zugriff für andere IAM-Prinzipale zu aktivieren. [Bewährte Methoden für IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) empfehlen, dass Sie Rollen statt Benutzern Berechtigungen gewähren. Mit dem folgenden Befehl können Sie sehen, welche anderen Prinzipale derzeit Zugriff auf Ihren Cluster haben:
```
kubectl describe -n kube-system configmap/aws-auth
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
Das vorherige Beispiel ist eine standardmäßige `aws-auth`-`ConfigMap`. Nur die Knoten-Instance-Rolle hat Zugriff auf den Cluster.
1. Stellen Sie sicher, dass `roles` und `rolebindings` oder `clusterroles` und `clusterrolebindings` vorhanden sind, denen Sie IAM-Prinzipale zuordnen können. Weitere Informationen über diese Ressourcen finden Sie unter [RBAC-Autorisierung verwenden](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
1. Zeigen Sie Ihre vorhandenen Kubernetes `roles` oder `clusterroles` an. `Roles` sind auf einen `namespace` ausgelegt, aber `clusterroles` sind auf den Cluster ausgelegt.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Zeigen Sie die Details einer beliebigen `role` oder `clusterrole` an, die in der vorherigen Ausgabe zurückgegeben wurden, und bestätigen Sie, dass Sie die Berechtigungen (`rules`) hat, die Ihre IAM-Prinzipale in Ihrem Cluster haben sollen.
Ersetzen Sie *role-name* durch einen `role`-Namen, den der vorherige Befehl zurückgegeben hat. Ersetzen Sie *kube-system* durch den Namespace der `role`.
```
kubectl describe role role-name -n kube-system
```
Ersetzen Sie *cluster-role-name* durch einen `clusterrole`-Namen, den der vorherige Befehl zurückgegeben hat.
```
kubectl describe clusterrole cluster-role-name
```
1. Zeigen Sie Ihre vorhandenen Kubernetes `rolebindings` oder `clusterrolebindings` an. `Rolebindings` sind auf einen `namespace` ausgelegt, aber `clusterrolebindings` sind auf den Cluster ausgelegt.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Zeigen Sie die Details einer beliebigen `rolebinding` oder `clusterrolebinding` an und bestätigen Sie, dass sie eine `role` oder `clusterrole` aus dem vorherigen Schritt hat, die als `roleRef` aufgeführt wird, und einen Gruppennamen, der für `subjects` aufgeführt wird.
Ersetzen Sie *role-binding-name* durch einen `rolebinding`-Namen, den der vorherige Befehl zurückgegeben hat. Ersetzen SIe *kube-system* mit dem `namespace` der `rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
Eine Beispielausgabe sieht wie folgt aus.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Ersetzen Sie *cluster-role-binding-name* durch einen `clusterrolebinding`-Namen, den der vorherige Befehl zurückgegeben hat.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
Eine Beispielausgabe sieht wie folgt aus.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Bearbeiten Sie die `aws-auth`-`ConfigMap`. Sie können ein Tool wie `eksctl` verwenden, um die `ConfigMap` zu aktualisieren, oder Sie können sie durch manuelle Bearbeitung aktualisieren.
**Wichtig**
Wir empfehlen die Verwendung von `eksctl` oder einem anderen Tool, um die `ConfigMap` zu bearbeiten. Informationen zu anderen Tools, die Sie verwenden können, finden Sie unter [Use tools to make changes to the aws- authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) in den Amazon EKS-Best-Practices-Leitfäden. Ist `aws-auth`-`ConfigMap` falsch formatiert, können Sie den Zugriff auf Ihren Cluster verlieren.
+ Schritte zum [Bearbeiten der Konfigurationszuordnung mit eksctl](#configmap-eksctl) anzeigen.
+ Schritte zum [manuellen Bearbeiten der Konfigurationszuordnung](#configmap-manual) anzeigen.
### Configmap mit Eksctl bearbeiten
1. Sie benötigen eine Version `0.215.0` oder eine neuere Version des `eksctl` Befehlszeilentools, das auf Ihrem Gerät installiert ist oder AWS CloudShell. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Zeigen Sie die aktuellen Mappings in der `ConfigMap` an. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. *region-code*Ersetzen Sie es durch die AWS Region, in der sich Ihr Cluster befindet.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Eine Beispielausgabe sieht wie folgt aus.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Fügen Sie ein Mapping für eine Rolle hinzu. Ersetzen Sie *my-role* durch den Namen Ihrer Rolle. *eks-console-dashboard-full-access-group*Ersetzen Sie durch den Namen der Gruppe, die in Ihrem Kubernetes `RoleBinding` oder `ClusterRoleBinding` Objekt angegeben ist. Ersetzen Sie *111122223333* durch Ihre Konto-ID. Sie können *admin* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**Wichtig**
Der Rollen-ARN darf keinen Pfad wie `role/my-team/developers/my-role` enthalten. Das Format des ARN muss ` arn:aws: iam::111122223333:role/my-role ` sein. In diesem Beispiel muss `my-team/developers/` entfernt werden.
Eine Beispielausgabe sieht wie folgt aus.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Fügen Sie ein Mapping für einen Benutzer hinzu. [Bewährte Methoden für IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) empfehlen, dass Sie Rollen statt Benutzern Berechtigungen gewähren. Ersetzen Sie *my-user* durch den Benutzernamen. *eks-console-dashboard-restricted-access-group*Ersetzen Sie es durch den Namen der Gruppe, die in Ihrem `RoleBinding` Kubernetes oder Objekt angegeben ist. `ClusterRoleBinding` Ersetzen Sie *111122223333* durch Ihre Konto-ID. Sie können *my-user* mit einem beliebigen Namen ersetzen, den Sie wählen.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws: iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
Eine Beispielausgabe sieht wie folgt aus.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws: iam::111122223333:user/my-user" to auth ConfigMap
```
1. Zeigen Sie wieder die Mappings in der `ConfigMap` an.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Eine Beispielausgabe sieht wie folgt aus.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws: iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws: iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws: iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Configmap manuell bearbeiten
1. Öffnen Sie `ConfigMap` zum Bearbeiten.
```
kubectl edit -n kube-system configmap/aws-auth
```
**Anmerkung**
Wenn Sie eine Fehlermeldung mit der Angabe "`Error from server (NotFound): configmaps "aws-auth" not found`" erhalten, wenden Sie das Verfahren unter [AWS-Auth auf Ihren Cluster anwenden ConfigMap an, um den](#aws-auth-configmap) Bestand anzuwenden. `ConfigMap`
1. Fügen Sie Ihre IAM-Prinzipale zu der `ConfigMap` hinzu. Eine IAM-Gruppe ist kein IAM-Prinzipal und kann daher nicht zu `ConfigMap` hinzugefügt werden.
+ **So fügen Sie eine IAM-Rolle hinzu (z. B. für [Verbundbenutzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)):** Fügen Sie die Rollendetails zum Abschnitt `mapRoles` der `ConfigMap` unter `data` hinzu. Fügen Sie diesen Abschnitt hinzu, wenn er nicht bereits in der Datei vorhanden sind. Jeder Eintrag unterstützt die folgenden Parameter:
+ **rolearn**: Der ARN der IAM-Rolle, den Sie hinzufügen möchten. Dieser Wert darf keinen Pfad enthalten. Sie können beispielsweise keinen ARN wie ` arn:aws: iam::111122223333:role/my-team/developers/role-name ` angeben. Der ARN muss stattdessen ` arn:aws: iam::111122223333:role/role-name ` sein.
+ **username**: Der Benutzername in Kubernetes für die Zuweisung zur IAM-Rolle.
+ **Gruppen**: Die Gruppe oder Liste der Kubernetes-Gruppen, denen die Rolle zugeordnet werden soll. Die Gruppe kann eine Standardgruppe oder eine Gruppe sein, die in einer `clusterrolebinding` oder `rolebinding` angegeben ist. Weitere Informationen finden Sie unter [Standardrollen und Rollenbindungen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in der Kubernetes-Dokumentation.
+ **Um einen IAM-Benutzer hinzuzufügen:** [Bewährte Methoden von IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) empfehlen, dass Sie Rollen statt Benutzern Berechtigungen gewähren. Fügen Sie die Benutzerdetails zum `mapUsers`-Abschnitt der `ConfigMap` unter `data` hinzu. Fügen Sie diesen Abschnitt hinzu, wenn er nicht bereits in der Datei vorhanden sind. Jeder Eintrag unterstützt die folgenden Parameter:
+ **userarn**: Die ARN des IAM-Benutzers, den Sie hinzufügen möchten.
+ **username**: Der Benutzername in Kubernetes für die Zuweisung zum IAM-Benutzer.
+ **Gruppen**: Die Gruppe oder Liste der Kubernetes-Gruppen, denen der Benutzer zugeordnet werden soll. Die Gruppe kann eine Standardgruppe oder eine Gruppe sein, die in einer `clusterrolebinding` oder `rolebinding` angegeben ist. Weitere Informationen finden Sie unter [Standardrollen und Rollenbindungen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) in der Kubernetes-Dokumentation.
1. Beispiel: Der folgende YAML-Block enthält:
+ Einen `mapRoles`-Abschnitt, der die IAM-Knoten-Instance Kubernetes-Gruppen zuordnet, sodass sich Knoten selbst bei dem Cluster und der `my-console-viewer-role`-IAM-Rolle registrieren können, die einer Kubernetes-Gruppe zugeordnet ist, die alle Kubernetes-Ressourcen für alle Cluster anzeigen kann. Eine Liste der erforderlichen IAM- und Kubernetes-Gruppenberechtigungen für die `my-console-viewer-role`-IAM-Rolle finden Sie unter [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Ein `mapUsers` Abschnitt, der den `admin` IAM-Benutzer aus dem AWS Standardkonto der `system:masters` Kubernetes-Gruppe und den `my-user` Benutzer aus einem anderen AWS Konto zuordnet, das einer Kubernetes-Gruppe zugeordnet ist, die Kubernetes-Ressourcen für einen bestimmten Namespace anzeigen kann. Eine Liste der erforderlichen IAM- und Kubernetes-Gruppenberechtigungen für die `my-user`-IAM-Benutzer finden Sie unter [Erforderliche Berechtigungen](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
Fügen Sie nach Bedarf Zeilen hinzu oder entfernen Sie sie und ersetzen Sie alle Beispielwerte durch Ihre eigenen Werte.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws: iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws: iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws: iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws: iam::444455556666:user/my-user
username: my-user
```
1. Speichern Sie die Datei und beenden Sie den Text-Editor.
## Anwenden von `aws-auth` `ConfigMap` auf Ihren Cluster
`aws-auth` `ConfigMap` wird automatisch erstellt und auf Ihren Cluster angewendet, wenn Sie eine verwaltete Knotengruppe erstellen oder wenn Sie eine Knotengruppe mit `eksctl` erstellen. Sie wird anfänglich erstellt, um Knoten zu erlauben, Ihrem Cluster beizutreten, aber Sie verwenden diese `ConfigMap` auch, um rollenbasierten Zugriffssteuerungs(RBAC)-Zugriff auf IAM-Prinzipale hinzuzufügen. Wenn Sie keine selbstverwalteten Knoten gestartet und `aws-auth` `ConfigMap` nicht auf Ihren Cluster angewendet haben, können Sie das folgende Verfahren dafür verwenden.
1. Überprüfen Sie, ob Sie `aws-auth` `ConfigMap` bereits angewendet haben.
```
kubectl describe configmap -n kube-system aws-auth
```
Wenn die Fehlermeldung „ `Error from server (NotFound): configmaps "aws-auth" not found` “ angezeigt wird, fahren Sie mit den folgenden Schritten fort, um die Standard-`ConfigMap` anzuwenden.
1. Laden Sie die Authenticator-Konfigurationsübersicht herunter, bearbeiten Sie sie und wenden Sie sie an. AWS
1. Laden Sie die Konfigurationszuordnung herunter.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Stellen Sie in der Datei `aws-auth-cm.yaml` `rolearn` auf den Amazon-Ressourcennamen (ARN) der IAM-Rolle ein, die Ihren Knoten zugeordnet ist. Hierzu können Sie einen Texteditor verwenden oder *my-node-instance-role* ersetzen und den folgenden Befehl ausführen:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
Ändern Sie keine weiteren Zeilen in dieser Datei.
**Wichtig**
Der Rollen-ARN darf keinen Pfad wie `role/my-team/developers/my-role` enthalten. Das Format des ARN muss ` arn:aws: iam::111122223333:role/my-role ` sein. In diesem Beispiel muss `my-team/developers/` entfernt werden.
Sie können die AWS CloudFormation Stack-Ausgaben für Ihre Knotengruppen überprüfen und nach den folgenden Werten suchen:
+ **InstanceRoleARN** — Für Knotengruppen, die erstellt wurden mit `eksctl`
+ **NodeInstanceRole**— Für Knotengruppen, die mit von Amazon EKS bereitgestellten AWS CloudFormation Vorlagen erstellt wurden, im AWS-Managementkonsole
1. Wenden Sie die Konfiguration an. Die Ausführung dieses Befehls kann einige Minuten dauern.
```
kubectl apply -f aws-auth-cm.yaml
```
**Anmerkung**
Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung.
1. Sehen Sie sich den Status Ihrer Knoten an und warten Sie, bis diese in den `Ready`-Status eintreten.
```
kubectl get nodes --watch
```
Geben Sie `Ctrl`\$1`C` ein, um zum Shell-Prompt zurückzukehren.
# Benutzern Zugriff auf Kubernetes mit einem externen OIDC-Anbieter gewähren
Amazon EKS unterstützt die Verwendung von OpenID-Connect(OIDC)-Identitätsanbietern als Methode zur Authentifizierung von Benutzern bei Ihrem Cluster. OIDC-Identitätsanbieter können zusammen mit oder als Alternative zu AWS Identity and Access Management (IAM) verwendet werden. Weitere Informationen zur Verwendung von IAM finden Sie unter [Gewähren Sie IAM-Benutzern und -Rollen Zugriff auf Kubernetes APIs](grant-k8s-access.md). Nachdem Sie die Authentifizierung für Ihren Cluster konfiguriert haben, können Sie Kubernetes `roles` und `clusterroles` erstellen, um den Rollen Berechtigungen zuzuweisen, und dann die Rollen mithilfe von Kubernetes `rolebindings` und `clusterrolebindings` an die Identitäten binden. Weitere Informationen finden Sie unter [Verwendung der RBAC-Autorisierung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
+ Sie können Ihrem Cluster einen OIDC-Identitätsanbieter zuordnen.
+ Kubernetes stellt keinen OIDC-Identitätsanbieter bereit. Sie können einen vorhandenen öffentlichen OIDC-Identitätsanbieter verwenden oder Ihren eigenen Identitätsanbieter ausführen. Eine Liste zertifizierter Anbieter finden Sie unter [OpenID-Zertifizierung](https://openid.net/certification/) auf der OpenID-Website.
+ Die Aussteller-URL des OIDC-Identitätsanbieters muss öffentlich zugänglich sein, damit Amazon EKS die Signaturschlüssel erkennen kann. Amazon EKS unterstützt keine OIDC-Identitätsanbieter mit selbstsignierten Zertifikaten.
+ Sie können die IAM-Authentifizierung in Ihrem Cluster nicht deaktivieren, da sie weiterhin erforderlich ist, um einem Cluster Knoten hinzufügen zu können.
+ Ein Amazon EKS-Cluster muss weiterhin von einem AWS [-IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) erstellt werden und nicht von einem OIDC-Identitätsanbieter-Benutzer. Das liegt daran, dass der Cluster-Ersteller mit Amazon EKS APIs und nicht mit APIs Kubernetes interagiert.
+ Benutzer, die vom OIDC-Identitätsanbieter authentifiziert wurden, werden im Auditprotokoll des Clusters aufgeführt, wenn die CloudWatch Protokolle für die Kontrollebene aktiviert sind. Weitere Informationen finden Sie unter [Aktivierung oder Deaktivierung der Steuerebenen-Protokolle](control-plane-logs.md#enabling-control-plane-log-export).
+ Sie können sich nicht AWS-Managementkonsole mit einem Konto eines OIDC-Anbieters bei der anmelden. Sie können dies nur [Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole](view-kubernetes-resources.md) tun, indem Sie sich AWS-Managementkonsole mit einem AWS Identity and Access Management-Konto anmelden.
## Verknüpfen Sie einen OIDC-Identitätsanbieter
Bevor Sie Ihrem Cluster einen OIDC-Identitätsanbieter zuordnen können, benötigen Sie die folgenden Informationen von Ihrem Anbieter:
**URL des Ausstellers**
Die URL des OIDC-Identitätsanbieters, die es dem API-Server ermöglicht, öffentliche Signierschlüssel zur Verifizierung von Token zu ermitteln. Die URL muss mit `https://` beginnen und sollte dem `iss`-Anspruch in den OIDC-ID-Token des Anbieters entsprechen. Gemäß dem OIDC-Standard sind Pfadkomponenten erlaubt, Abfrageparameter jedoch nicht. Normalerweise besteht die URL nur aus einem Hostnamen wie `https://server.example.org` oder `https://example.com`. Diese URL sollte auf die Ebene unterhalb von `.well-known/openid-configuration` verweisen und muss über das Internet öffentlich zugänglich sein.
**Client-ID (auch als *Zielgruppe* bezeichnet)**
Die ID für die Client-Anwendung, die Authentifizierungsanforderungen an den OIDC-Identitätsanbieter stellt.
Sie können einen Identitätsanbieter mit `eksctl` oder AWS-Managementkonsole zuordnen.
### Identitätsanbieter mit eksctl zuordnen
1. Erstellen Sie eine Datei mit dem Namen `associate-identity-provider.yaml` und dem folgenden Inhalt. Ersetzen Sie die Beispielwerte durch Ihre eigenen Werte. Die Werte im Abschnitt `identityProviders` erhalten Sie von Ihrem OIDC-Identitätsanbieter. Werte werden nur für die `name`-, `type`-, `issuerUrl`- und `clientId`-Einstellungen unter `identityProviders` benötigt.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**Wichtig**
Geben Sie weder `system:` noch einen Teil dieser Zeichenfolge für `groupsPrefix` oder `usernamePrefix` an.
1. Erstellen Sie den Anbieter.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Informationen zum Verwenden von `kubectl` für die Arbeit mit Ihrem Cluster und OIDC-Identitätsanbieter finden Sie unter [Verwendung von kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) in der Kubernetes-Dokumentation.
### Ordnen Sie mithilfe der Konsole einen Identitätsanbieter zu AWS
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie Ihren Cluster aus und anschließend die Registerkarte **Zugriff**.
1. Wählen Sie im Abschnitt **OIDC-Identitätsanbieter** die Option „Identitätsanbieter zuordnen“ aus.
1. Geben Sie auf der Seite **OIDC-Identitätsanbieter zuordnen** die folgenden Optionen ein oder wählen Sie sie aus, und wählen Sie dann **Zuordnen** aus.
+ Geben Sie für **Name** einen eindeutigen Namen für den Anbieter ein.
+ Geben Sie für **Aussteller-URL** die URL Ihres Anbieters ein. Diese URL muss über das Internet zugänglich sein.
+ Geben Sie für **Client-ID** die Client-ID des OIDC-Identitätsanbieters (auch als **Zielgruppe** bezeichnet) ein.
+ Geben Sie für **Benutzernamenanspruch** den Anspruch ein, der als Benutzername verwendet werden soll.
+ Geben Sie für **Gruppenanspruch** den Anspruch ein, der als Benutzergruppe verwendet werden soll.
+ (Optional) Wählen Sie **Erweiterte Optionen**, geben Sie die folgenden Informationen ein oder wählen Sie sie aus.
+ **Benutzernamen-Präfix** – Geben Sie ein Präfix ein, das den Benutzernamenansprüchen vorangestellt wird. Das Präfix wird den Benutzernamensansprüchen vorangestellt, um Konflikte mit bestehenden Namen zu vermeiden. Wenn Sie keinen Wert angeben und der Benutzername ein anderer Wert als `email` ist, wird als Präfix standardmäßig der Wert für die **Aussteller-URL** verwendet. Sie können den Wert ` -` verwenden, um alle Präfixe zu deaktivieren. Geben Sie weder `system:`, noch einen Teil dieser Zeichenfolge an.
+ **Gruppen-Präfix** – Geben Sie ein Präfix ein, das den Gruppenansprüchen vorangestellt werden soll. Das Präfix wird Gruppenansprüchen vorangestellt, um Konflikte mit vorhandenen Namen (wie beispielsweise ` system: groups`) zu vermeiden. Der Wert `oidc:` erstellt beispielsweise Gruppennamen wie `oidc:engineering` und `oidc:infra`. Geben Sie weder `system:`, noch einen Teil dieser Zeichenfolge an.
+ **Erforderliche Ansprüche** – Wählen Sie **Anspruch hinzufügen** aus, und geben Sie ein oder mehrere Schlüsselwertpaare ein, die erforderliche Ansprüche im Client-ID-Token beschreiben. Die Paare beschreiben erforderliche Ansprüche im ID-Token. Wenn festgelegt, wird überprüft, ob jeder Anspruch im ID-Token mit einem übereinstimmenden Wert vorhanden ist.
1. Informationen zum Verwenden von `kubectl` für die Arbeit mit Ihrem Cluster und OIDC-Identitätsanbieter finden Sie unter [Verwendung von kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) in der Kubernetes-Dokumentation.
## Beispiel für eine IAM-Richtlinie
Wenn Sie verhindern möchten, dass ein OIDC-Identitätsanbieter mit einem Cluster verknüpft wird, erstellen Sie die folgende IAM-Richtlinie und verknüpfen Sie sie mit den IAM-Konten Ihrer Amazon-EKS-Administratoren. Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) und [Hinzufügen von IAM-Identitätsberechtigungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) im *IAM-Benutzerhandbuch* sowie unter [Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) in der Referenz zur Service-Autorisierung.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
Die folgende Beispielrichtlinie lässt die Zuordnung von OIDC-Identitätsanbietern zu, wenn `clientID` `kubernetes` und `issuerUrl` `https://cognito-idp.us-west-2amazonaws.com/*` ist.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Trennen Sie einen OIDC-Identitätsanbieter von Ihrem Cluster
Wenn Sie einen OIDC-Identitätsanbieter von Ihrem Cluster trennen, können Benutzer, die im Anbieter enthalten sind, nicht mehr auf den Cluster zugreifen. Sie können jedoch weiterhin mit [IAM-Prinzipalen](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) auf den Cluster zugreifen.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im Abschnitt **OIDC-Identitätsanbieter** die Option **Zuordnung aufheben**, geben Sie den Namen des Identitätsanbieters ein und wählen Sie dann `Disassociate` aus.
# Kubernetes-Ressourcen anzeigen in der AWS-Managementkonsole
Mit der AWS-Managementkonsole können Sie die Kubernetes-Ressourcen anzeigen, die in Ihrem Cluster bereitgestellt sind. [Sie können Kubernetes-Ressourcen nicht mit der AWS CLI oder eksctl anzeigen.](https://eksctl.io/) Um Kubernetes-Ressourcen mit einem Befehlszeilen-Tool anzuzeigen, verwenden Sie [kubectl](install-kubectl.md).
**Anmerkung**
Um die Registerkarte **Ressourcen** und den Abschnitt **Knoten** auf der Registerkarte **Compute** in der anzeigen zu können AWS-Managementkonsole, muss der von Ihnen verwendete [IAM-Prinzipal über bestimmte IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) - und Kubernetes-Berechtigungen verfügen. Weitere Informationen finden Sie unter [Erforderliche Berechtigungen](#view-kubernetes-resources-permissions).
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie in der Liste **Cluster** den Cluster aus, der die Kubernetes-Ressourcen enthält, die Sie anzeigen möchten.
1. Wählen Sie die Registerkarte für **Resources (Ressourcen)**.
1. Wählen Sie eine **Resource type**-Gruppe (Ressourcentyp) aus, für die Sie Ressourcen anzeigen möchten, z. B. **Workloads**. Ihnen wird eine Liste der Ressourcentypen in dieser Gruppe angezeigt.
1. Wählen Sie einen Ressourcentyp aus, z. B. **Deployments** (Bereitstellungen) in der Gruppe **Workloads**. Sie sehen eine Beschreibung des Ressourcentyps, einen Link zur Kubernetes-Dokumentation für weitere Informationen über den Ressourcentyp und eine Liste der Ressourcen dieses Typs, die in Ihrem Cluster bereitgestellt werden. Wenn die Liste leer ist, werden keine Ressourcen dieses Typs in Ihrem Cluster bereitgestellt.
1. Wählen Sie eine Ressource aus, um weitere Informationen dazu anzuzeigen. Probieren Sie die folgenden Beispiele aus:
+ Wählen Sie die Gruppe **Workloads** aus, dann den Ressourcentyp **Deployments** (Bereitstellungen) gefolgt von der Ressource **coredns**. Wenn Sie eine Ressource auswählen, befinden Sie sich standardmäßig in der **strukturierten Ansicht**. Für einige Ressourcentypen wird in der **strukturierten Ansicht** der Abschnitt **Pods** angezeigt. In diesem Abschnitt sind die Pods aufgeführt, die von der Workload verwaltet werden. Sie können jeden aufgelisteten Pod auswählen, um Informationen zu dem Pod anzuzeigen. Nicht für alle Ressourcentypen werden Informationen in der **strukturierten Ansicht** angezeigt. Wenn Sie die Ansicht **Raw** in der oberen rechten Ecke der Seite für die Ressource auswählen, sehen Sie die vollständige JSON-Antwort von der Kubernetes-API für die Ressource.
+ Wählen Sie die **Cluster**-Gruppe aus und dann den Ressourcentyp **Nodes** (Knoten). Eine Liste aller Knoten in Ihrem Cluster wird angezeigt. Die Knoten können von jedem [Amazon-EKS-Knoten-Typ](eks-compute.md) sein. Das ist die gleiche Liste, die Sie im Abschnitt **Nodes** (Knoten) sehen, wenn Sie die Registerkarte **Compute** (Datenverarbeitung) für Ihren Cluster auswählen. Wählen Sie eine Knotenressource aus der Liste aus. In der **strukturierten Ansicht** sehen Sie ebenfalls einen Abschnitt **Pods**. Dieser Abschnitt zeigt Ihnen alle in dem Knoten ausgeführten Pods.
## Erforderliche Berechtigungen
Um die Registerkarte **Ressourcen** und den Abschnitt **Knoten** auf der Registerkarte **Compute** in der anzeigen zu können AWS-Managementkonsole, muss der von Ihnen verwendete [IAM-Prinzipal über bestimmte Mindestberechtigungen für IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) und Kubernetes verfügen. Sie müssen sowohl die IAM- als auch die Kubernetes-RBAC-Berechtigungen korrekt konfiguriert haben. Führen Sie die folgenden Schritte aus, um Ihren IAM-Prinzipalen die erforderlichen Berechtigungen zuzuweisen.
1. Stellen Sie sicher, dass `eks:AccessKubernetesApi` und andere erforderliche IAM-Berechtigungen zum Anzeigen von Kubernetes-Ressourcen dem von Ihnen verwendeten IAM-Prinzipal zugewiesen sind. Weitere Informationen zum Bearbeiten von Berechtigungen für einen IAM-Prinzipal finden Sie unter [Zugriff für Prinzipale steuern](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) und im IAM-Benutzerhandbuch. Weitere Informationen zum Bearbeiten von Rollenberechtigungen finden Sie unter [Modifying a role permissions policy (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy) (Ändern einer Rollenberechtigungsrichtlinie (Konsole)) im IAM-Benutzerhandbuch.
Die folgende Beispielrichtlinie enthält die erforderlichen Berechtigungen für einen Prinzipal zum Anzeigen von Kubernetes-Ressourcen für alle Cluster in Ihrem Konto. Ersetzen Sie *111122223333* es durch Ihre Konto-ID. AWS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Um Knoten in [verbundenen Clustern](eks-connector.md) anzuzeigen, sollte die [IAM-Rolle des Amazon-EKS-Connectors](connector-iam-role.md) in der Lage sein, den Prinzipal im Cluster anzunehmen. Dadurch kann [Amazon EKS Connector](eks-connector.md) den Prinzipal einem Kubernetes-Benutzer zuordnen.
1. Konfigurieren Sie Kubernetes-RBAC-Berechtigungen mithilfe von EKS-Zugriffseinträgen.
**Was sind EKS-Zugriffseinträge?**
EKS-Zugriffseinträge sind eine optimierte Methode, um IAM-Prinzipalen (Benutzern und Rollen) Zugriff auf Ihren Kubernetes-Cluster zu gewähren. Anstatt die Kubernetes-RBAC-Ressourcen und die manuell zu verwalten `aws-auth` ConfigMap, übernehmen die Zugriffseinträge automatisch die Zuordnung zwischen IAM- und Kubernetes-Berechtigungen mithilfe der verwalteten Richtlinien von. AWS Ausführliche Informationen zu Zugriffseinträgen finden Sie unter. [IAM-Benutzern mit EKS-Zugriffseinträgen Zugriff auf Kubernetes gewähren](access-entries.md) Informationen zu verfügbaren Zugriffsrichtlinien und deren Berechtigungen finden Sie unter [Zugriffsrichtlinienberechtigungen](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
Sie können Kubernetes-Berechtigungen für den Zugriff auf Einträge auf zwei Arten anfügen:
+ **Verwenden Sie eine Zugriffsrichtlinie:** Zugriffsrichtlinien sind vordefinierte Kubernetes-Berechtigungsvorlagen, die von verwaltet werden. AWS Diese bieten standardisierte Berechtigungssätze für gängige Anwendungsfälle.
+ **Verweisen Sie auf eine Kubernetes-Gruppe:** Wenn Sie einer Kubernetes-Gruppe eine IAM-Identität zuordnen, können Sie Kubernetes-Ressourcen erstellen, die der Gruppe Berechtigungen gewähren. Weitere Informationen finden Sie unter [Verwendung der RBAC-Autorisierung](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) in der Kubernetes-Dokumentation.
1. Erstellen Sie mit der AWS CLI einen Zugriffseintrag für Ihren IAM-Prinzipal. Ersetzen Sie *my-cluster* mit dem Namen Ihres Clusters. Ersetzen Sie *111122223333* durch Ihre Konto-ID.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws: eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Ordnen Sie dem Zugriffseintrag eine Richtlinie zu. Verwenden Sie zum Anzeigen von Kubernetes-Ressourcen den: `AmazonEKSViewPolicy`
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws: iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Für namespace-spezifischen Zugriff können Sie die Richtlinie auf bestimmte Namespaces beschränken:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Stellen Sie sicher, dass der Zugriffseintrag erfolgreich erstellt wurde:
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
1. Führen Sie die zugehörigen Richtlinien auf, um die Richtlinienverknüpfung zu bestätigen:
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws: iam::111122223333:role/my-console-viewer-role
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws: eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## CloudTrail Sichtbarkeit
Bei der Anzeige von Kubernetes-Ressourcen wird in Ihren CloudTrail Protokollen der folgende Operationsname angezeigt:
+ `AccessKubernetesApi`- Beim Lesen oder Anzeigen von Ressourcen
Dieses CloudTrail Ereignis bietet einen Prüfpfad für den Lesezugriff auf Ihre Kubernetes-Ressourcen.
**Anmerkung**
Dieser Vorgangsname erscheint in den CloudTrail Protokollen nur zu Prüfungszwecken. Es handelt sich nicht um eine IAM-Aktion und kann nicht in IAM-Richtlinienerklärungen verwendet werden. Verwenden Sie die im Abschnitt beschriebene `eks:AccessKubernetesApi` Berechtigung, um den Lesezugriff auf Kubernetes-Ressourcen mithilfe von IAM-Richtlinien zu steuern. [Erforderliche Berechtigungen](#view-kubernetes-resources-permissions)
# AWS Diensten Schreibzugriff auf Kubernetes gewähren APIs
## Erforderliche Berechtigungen
Damit AWS Services Schreibvorgänge auf Kubernetes-Ressourcen in Ihrem Amazon EKS-Cluster ausführen können, müssen Sie `eks:AccessKubernetesApi` sowohl die als auch die `eks:MutateViaKubernetesApi` IAM-Berechtigungen gewähren.
Amazon SageMaker HyperPod verwendet diese Berechtigungen beispielsweise, um die Modellbereitstellung von SageMaker AI Studio aus zu ermöglichen. Weitere Informationen finden Sie unter [Optionale JavaScript SDK-Berechtigungen einrichten](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) im Amazon SageMaker AI Developer Guide.
**Wichtig**
Schreibvorgänge wie Erstellen, Aktualisieren und Löschen erfordern beide Berechtigungen. Fehlt eine der Berechtigungen, schlagen Schreibvorgänge fehl.
## CloudTrail Sichtbarkeit
Während Sie Schreibvorgänge auf Kubernetes-Ressourcen ausführen, werden Sie in Ihren CloudTrail Protokollen bestimmte Operationsnamen sehen:
+ `createKubernetesObject`- Beim Erstellen neuer Ressourcen
+ `updateKubernetesObject`- Beim Ändern vorhandener Ressourcen
+ `deleteKubernetesObject`- Beim Entfernen von Ressourcen
Diese CloudTrail Ereignisse bieten detaillierte Prüfprotokolle aller Änderungen, die an Ihren Kubernetes-Ressourcen vorgenommen wurden.
**Anmerkung**
Diese Vorgangsnamen werden in den CloudTrail Protokollen nur zu Prüfungszwecken angezeigt. Sie sind keine IAM-Aktionen und können nicht in IAM-Richtlinienerklärungen verwendet werden. Verwenden Sie die im Abschnitt beschriebene `eks:MutateViaKubernetesApi` Berechtigung, um den Schreibzugriff auf Kubernetes-Ressourcen über IAM-Richtlinien zu steuern. [Erforderliche Berechtigungen](#mutate-kubernetes-resources-permissions)
# kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) für bevorstehende Amazon EKS-Workshops an.
In diesem Thema erstellen Sie eine `kubeconfig`-Datei für Ihren Cluster (oder aktualisieren eine vorhandene).
Das `kubectl`-Befehlszeilentool verwendet Konfigurationsinformationen in `kubeconfig`-Dateien für die Kommunikation mit dem API-Server eines Clusters. Weitere Informationen finden Sie unter [Organisieren des Cluster-Zugriffs mit kubeconfig-Dateien](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) in der Kubernetes-Dokumentation.
Amazon EKS verwendet den Befehl `aws eks get-token` mit `kubectl` für die Cluster-Authentifizierung. Standardmäßig verwendet die AWS CLI dieselben Anmeldeinformationen, die mit dem folgenden Befehl zurückgegeben werden:
```
aws sts get-caller-identity
```
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Erste Schritte mit Amazon EKS](getting-started.md).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Ein IAM-Benutzer oder eine Rolle mit Berechtigung zur Verwendung der API-Aktion `eks:DescribeCluster` für den angegebenen Cluster. Weitere Informationen finden Sie unter [Beispiele für identitätsbasierte Amazon-EKS-Richtlinien](security-iam-id-based-policy-examples.md). Wenn Sie für den Zugriff auf Ihren Cluster eine Identität Ihres eigenen OpenID-Connect-Anbieters verwenden, lesen Sie den Abschnitt [Verwendung von kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) in der Kubernetes-Dokumentation, um Ihre `kube config`-Datei zu erstellen oder zu aktualisieren.
## `kubeconfig`-Datei automatisch erstellen
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Berechtigung zur Nutzung der `eks:DescribeCluster`-API-Aktion für den Cluster, den Sie angeben. Weitere Informationen finden Sie unter [Beispiele für identitätsbasierte Amazon-EKS-Richtlinien](security-iam-id-based-policy-examples.md).
1. Erstellen oder aktualisieren Sie eine `kubeconfig`-Datei für Ihren Cluster. *region-code*Ersetzen Sie es durch die AWS Region, in der sich Ihr Cluster befindet, und *my-cluster* ersetzen Sie es durch den Namen Ihres Clusters.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Standardmäßig wird die resultierende Konfigurationsdatei im Standard `kubeconfig`-Pfad (`.kube`) in Ihrem Stammverzeichnis erstellt oder mit einer vorhandenen `config`-Datei an diesem Speicherort zusammengeführt. Sie können mit der Option `--kubeconfig` einen anderen Pfad angeben.
Sie können einen IAM-Rollen-ARN mit der Option `--role-arn` für die Authentifizierung verwenden, wenn Sie `kubectl`-Befehle ausgeben. Andernfalls wird der [IAM-Prinzipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) in Ihrer standardmäßigen AWS CLI- oder SDK-Anmeldeinformationskette verwendet. Sie können Ihre AWS Standard-CLI- oder SDK-Identität anzeigen, indem `aws sts get-caller-identity` Sie den Befehl ausführen.
*Für alle verfügbaren Optionen führen Sie den `aws eks update-kubeconfig help` Befehl aus oder sehen Sie sich [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) in der AWS CLI-Befehlsreferenz an.*
1. Testen Sie Ihre Konfiguration.
```
kubectl get svc
```
Eine Beispielausgabe sieht wie folgt aus.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Wenn Sie Autorisierungs- oder Ressourcenfehler erhalten, finden Sie weitere Informationen unter [Nicht autorisiert oder Zugriff verweigert (`kubectl`)](troubleshooting.md#unauthorized) im Thema zur Fehlerbehebung.
# Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren
[Verwaltung von Servicekonten](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md)[Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md)
## Servicekonto-Tokens
Das Feature [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) ist in Kubernetes-Versionen standardmäßig aktiviert. Die Funktion verbessert die Sicherheit von Servicekonto-Tokens, indem sie es auf Kubernetes ausgeführten Workloads ermöglicht, JSON-Web-Tokens, die an Zielgruppen, Zeit und Schlüssel gebunden sind, anzufordern. Die Ablaufzeit für Servicekonto-Tokens beträgt eine Stunde. In früheren Kubernetes-Versionen hatten Token kein Ablaufdatum. Clients, die diese Tokens verwenden, müssen die Tokens nun also innerhalb einer Stunde aktualisieren. Die folgenden [Kubernetes-Client-SKDs](https://kubernetes.io/docs/reference/using-api/client-libraries/) aktualisieren Tokens automatisch im erforderlichen Zeitrahmen:
+ Go-Version `0.15.7` und höher
+ Python-Version `12.0.0` und höher
+ Java-Version `9.0.0` und höher
+ JavaScript-Version `0.10.3` und höher
+ Ruby `master`-Branch
+ Haskell-Version `0.3.0.0`
+ C\$1-Version `7.0.5` und höher
Wenn Ihre Workload eine frühere Client-Version verwendet, ist eine Aktualisierung erforderlich. Um Clients reibungslos zu neueren zeitlich begrenzten Servicekonto-Tokens zu migrieren, fügt Kubernetes eine verlängerte Ablaufzeit für Servicekonto-Tokens, welche die standardmäßige Stunde übersteigt. Für Amazon-EKS-Cluster gilt eine verlängerte Ablaufzeit von 90 Tagen. Der Kubernetes-API-Server Ihres Amazon-EKS-Clusters lehnt Anfragen mit Token ab, die älter als 90 Tage sind. Sie sollten Ihre Anwendungen und ihre Abhängigkeiten überprüfen, um sicherzustellen, dass die Kubernetes-Client-SDKs mit den zuvor aufgeführten Versionen identisch oder höher sind.
Wenn der API-Server Anfragen mit Token erhält, die älter als eine Stunde sind, kommentiert er das Audit-Protokollereignis der API mit `annotations.authentication.k8s.io/stale-token`. Die Anmerkung sieht zum Beispiel wie folgt aus:
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
Wenn für Ihren Cluster die [Steuerebenen-Protokollierung](control-plane-logs.md) aktiviert ist, dann befinden sich die Anmerkungen in den Überwachungsprotokollen. Sie können die folgende Abfrage mit [CloudWatch Logs Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) verwenden, um alle Pods in Ihrem Amazon-EKS-Cluster zu identifizieren, die veraltete Token verwenden:
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
`subject` bezieht sich auf das Servicekonto, das der Pod verwendet hat. `elapsedtime` gibt die verstrichene Zeit (in Sekunden) nach dem Lesen des neuesten Tokens an. Die Anfragen an den API-Server werden abgelehnt, wenn `elapsedtime` 90 Tage (7 776 000 Sekunden) überschreitet. Sie sollten das Kubernetes-Client-SDK Ihrer Anwendungen proaktiv aktualisieren, um eine der zuvor aufgeführten Versionen zu verwenden, die das Token automatisch aktualisiert. Wenn das verwendete Servicekonto-Token fast 90 Tage erreicht hat, und Sie nicht genügend Zeit haben, Ihre Client-SDK-Versionen vor dem Ablauf des Tokens zu aktualisieren, können Sie die vorhandenen Pods beenden und neue erstellen. Dadurch wird das Servicekonto-Token erneut abgerufen, sodass Sie weitere 90 Tage Zeit haben, die SDKs Ihrer Client-Version zu aktualisieren.
Wenn der Pod Teil einer Bereitstellung ist, besteht die empfohlene Vorgehensweise zum Beenden der Pods und gleichzeitigen Aufrechterhaltung hoher Verfügbarkeit darin, mit dem folgenden Befehl eine Einführung durchzuführen. Ersetzen Sie *my-deployment* mit dem Namen Ihrer Bereitstellung.
```
kubectl rollout restart deployment/my-deployment
```
## Cluster-Add-ons
Die folgenden Cluster-Add-Ons wurden für die Verwendung der Kubernetes-Client-SDKs aktualisiert, die Servicekonto-Token automatisch neu abrufen können. Wir empfehlen Ihnen, sicherzustellen, dass die aufgeführten Versionen oder neuere Versionen auf Ihrem Cluster installiert sind.
+ Amazon-VPC-CNI-Plugin für Kubernetes und Metrik-Hilfs-Plugins Version `1.8.0` und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Pods mit dem Amazon VPC CNI zuweisen IPs](managing-vpc-cni.md) und [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md).
+ CoreDNS-Version `1.8.4` und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [CoreDNS für DNS in Amazon EKS-Clustern verwalten](managing-coredns.md).
+ Version `2.0.0` von AWS Load Balancer Controller und höher. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Internetverkehr mit AWS Load Balancer Controller weiterleiten](aws-load-balancer-controller.md).
+ Eine aktuelle `kube-proxy`-Version. Zum Überprüfen oder Aktualisieren Ihrer aktuellen Version siehe [Verwaltung von `kube-proxy` in Amazon-EKS-Clustern](managing-kube-proxy.md).
+ AWS für Fluent Bit-Version `2.25.0` oder höher. Informationen zum Aktualisieren Ihrer aktuellen Version finden Sie unter [Releases](https://github.com/aws/aws-for-fluent-bit/releases) auf GitHub:
+ Fluentd-Imageversion [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) oder höher und Fluentd-Filter-Plugin für Kubernetes-Metadatenversion [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) oder höher.
## Gewährung von AWS Identity and Access Management für Workloads in Clustern von Amazon Elastic Kubernetes Service
Amazon EKS bietet zwei Möglichkeiten, um Workloads, die in Amazon-EKS-Clustern ausgeführt werden, Berechtigungen für AWS Identity and Access Management zu gewähren: *IAM-Rollen für Servicekonten* und *EKS Pod Identities*.
**IAM-Rollen für Servicekonten**
*IAM-Rollen für Servicekonten (IRSA)* konfiguriert Kubernetes-Anwendungen, die in AWS ausgeführt werden, mit detaillierten IAM-Berechtigungen für den Zugriff auf verschiedene andere AWS-Ressourcen wie Amazon S3-Buckets, Amazon DynamoDB-Tabellen und mehr. Sie können mehrere Anwendungen zusammen in demselben Amazon EKS-Cluster ausführen und sicherstellen, dass jede Anwendung nur über die erforderlichen Mindestberechtigungen verfügt. IRSA wurde entwickelt, um verschiedene von AWS unterstützte Kubernetes-Bereitstellungsoptionen zu unterstützen, wie z. B. Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service in AWS und selbstverwaltete Kubernetes-Cluster auf Amazon-EC2-Instances. Daher wurde IRSA mithilfe grundlegender AWS-Services wie IAM erstellt und war nicht direkt vom Amazon EKS-Service und der EKS-API abhängig. Weitere Informationen finden Sie unter [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md).
**EKS Pod Identities**
EKS Pod Identity bietet Cluster-Administratoren einen vereinfachten Workflow zur Authentifizierung von Anwendungen für den Zugriff auf verschiedene andere AWS-Ressourcen wie Amazon S3-Buckets, Amazon DynamoDB-Tabellen und mehr. EKS Pod Identity ist nur für EKS vorgesehen und vereinfacht Cluster-Administratoren so die Konfiguration von Kubernetes-Anwendungen, um IAM-Berechtigungen zu erhalten. Diese Berechtigungen können jetzt direkt über die AWS-Managementkonsole, die EKS-API und AWS CLI ganz einfach mit weniger Schritten konfiguriert werden und es müssen keine Maßnahmen innerhalb des Clusters von Kubernetes-Objekten ergriffen werden. Cluster-Administratoren müssen nicht zwischen den EKS- und IAM-Services wechseln oder privilegierte IAM-Operationen verwenden, um die für Ihre Anwendungen erforderlichen Berechtigungen zu konfigurieren. IAM-Rollen können jetzt in mehreren Clustern verwendet werden, ohne dass bei der Erstellung neuer Cluster die Rollenvertrauensrichtlinie aktualisiert werden muss. Die von EKS Pod Identity bereitgestellten IAM-Anmeldeinformationen umfassen Rollensitzungs-Tags mit Attributen wie Cluster-Name, Namespace und dem Namen des Servicekontos. Rollensitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die für alle Servicekonten verwendet werden kann, indem sie den Zugriff auf AWS-Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht. Weitere Informationen finden Sie unter [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md).
### Vergleich von EKS Pod Identity und IRSA
Ganz allgemein ermöglichen es Ihnen sowohl EKS Pod Identity als auch IRSA, Anwendungen, die auf Kubernetes-Clustern ausgeführt werden, IAM-Berechtigungen zu gewähren. Sie unterscheiden sich jedoch grundlegend in ihrer Konfiguration, den unterstützten Grenzwerten und den aktivierten Features. Nachfolgend vergleichen wir einige der wichtigsten Aspekte beider Lösungen.
**Anmerkung**
AWS empfiehlt die Verwendung von EKS Pod Identities, um Ihren Pods nach Möglichkeit Zugriff auf AWS-Ressourcen zu gewähren. Weitere Informationen finden Sie unter [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md).
| Attribut | EKS Pod Identity | IRSA |
| --- | --- | --- |
| Erweiterbarkeit von Rollen | Sie müssen jede Rolle einmal einrichten, um das Vertrauen des neu eingeführten Amazon EKS-Service-Prinzipal zu erhalten `pods.eks.amazonaws.com`. Nach diesem einmaligen Schritt müssen Sie die Vertrauensrichtlinie der Rolle nicht jedes Mal aktualisieren, wenn sie in einem neuen Cluster verwendet wird. | Sie müssen die Vertrauensrichtlinie der IAM-Rolle jedes Mal mit dem neuen Endpunkt des EKS-Cluster-OIDC-Anbieters aktualisieren, wenn Sie die Rolle in einem neuen Cluster verwenden möchten. |
| Skalierbarkeit von Clustern | Bei EKS Pod Identity müssen Benutzer keinen IAM-OIDC-Anbieter einrichten. Dieses Limit gilt also nicht. | Jedem EKS-Cluster ist eine OpenID Connect (OIDC)-Aussteller-URL zugeordnet. Um IRSA zu verwenden, muss für jeden EKS-Cluster in IAM ein eindeutiger OpenID-Connect-Anbieter erstellt werden. IAM hat ein globales Standardlimit von 100 OIDC-Anbietern für jedes AWS-Konto. Wenn Sie planen, mehr als 100 EKS-Cluster pro AWS-Konto mit IRSA zu haben, erreichen Sie das IAM-OIDC-Anbieterlimit. |
| Skalierbarkeit von Rollen | Bei EKS Pod Identity müssen Benutzer in der Vertrauensrichtlinie keine Vertrauensbeziehung zwischen der IAM-Rolle und dem Servicekonto definieren. Dieses Limit gilt also nicht. | In IRSA muss die Vertrauensbeziehung zwischen einer IAM-Rolle und einem Servicekonto in der Vertrauensrichtlinie der Rolle definiert werden. Standardmäßig beträgt die Größe der Vertrauensrichtlinie `2048`. Das bedeutet, dass Sie in der Regel vier Vertrauensbeziehungen in einer Vertrauensrichtlinie definieren können. Sie können zwar das Limit für die maximale Größe der Vertrauensrichtlinie erhöhen, sind jedoch in der Regel auf maximal acht Vertrauensbeziehungen innerhalb einer Vertrauensrichtlinie beschränkt. |
| STS-API-Kontingentnutzung | EKS Pod Identity vereinfacht die Übermittlung von AWS-Anmeldeinformationen an Ihre Pods und erfordert nicht, dass Ihr Code direkt Aufrufe mit dem AWS Security Token Service (STS) durchführt. Der EKS-Service übernimmt die Rollenübernahme und übermittelt Anmeldeinformationen an Anwendungen, die mit dem AWS-SDK in Ihren Pods geschrieben wurden, ohne dass Ihre Pods mit AWS STS kommunizieren oder STS-API-Kontingente verwenden müssen. | In IRSA verwenden Anwendungen, die mit dem AWS-SDK in Ihren Pods geschrieben wurden, Tokens, um die `AssumeRoleWithWebIdentity`-API auf dem AWS Security Token Service (STS) aufzurufen. Abhängig von der Logik Ihres Codes im AWS-SDK ist es möglich, dass Ihr Code unnötige Aufrufe an AWS STS tätigt und Drosselungsfehler erhält. |
| Wiederverwendbarkeit von Rollen | Die von EKS Pod Identity bereitgestellten, temporären AWS-STS-Anmeldeinformationen umfassen Rollensitzungs-Tags wie Cluster-Name, Namespace und den Namen des Servicekontos. Mithilfe von Rollensitzungs-Tags können Administratoren eine einzelne IAM-Rolle erstellen, die von mehreren Servicekonten mit unterschiedlichen effektiven Berechtigungen verwendet werden kann, indem auf Grundlage der ihnen zugewiesenen Tags Zugriff auf AWS-Ressourcen ermöglicht wird. Dies wird auch als attributbasierte Zugriffskontrolle (ABAC) bezeichnet. Weitere Informationen finden Sie unter [Pods Zugriff auf AWS Ressourcen basierend auf Tags gewähren](pod-id-abac.md). | AWS-STS-Sitzungs-Tags werden nicht unterstützt. Sie können eine Rolle in verschiedenen Clustern wiederverwenden, aber jeder Pod erhält alle Berechtigungen der Rolle. |
| Unterstützte Umgebungen | EKS Pod Identity ist nur in Amazon EKS verfügbar. | IRSA kann beispielsweise für Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service in AWS und selbstverwaltete Kubernetes-Cluster in Amazon-EC2-Instances verwendet werden. |
| Unterstützte EKS-Versionen | Alle unterstützten EKS-Cluster-Versionen. Informationen über die jeweiligen Plattformversionen finden Sie unter [Cluster-Versionen von EKS Pod Identity](pod-identities.md#pod-id-cluster-versions). | Alle unterstützten EKS-Cluster-Versionen. |
# IAM-Rollen für Servicekonten
**Tipp**
[Melden Sie sich](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) 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](eks-outposts-local-cluster-overview.md) 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)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) 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](create-node-role.md) 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](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**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](enable-iam-roles-for-service-accounts.md) – 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](https://github.com/aws/containers-roadmap/issues/2038) unter. GitHub
1. [IAM-Rollen Kubernetes-Servicekonten zuweisen](associate-service-account-role.md) – Führen Sie diesen Vorgang für jede einzelne Berechtigungsgruppe durch, über die eine Anwendung verfügen soll.
1. [Pods so konfigurieren, dass sie ein Kubernetes-Dienstkonto verwenden](pod-configuration.md) — Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf Dienste benötigt. AWS
1. [IRSA mit dem AWS SDK verwenden](iam-roles-for-service-accounts-minimum-sdk.md) — 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](irsa-fetch-keys.md).
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.
# Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster
Ihrem Cluster ist eine [OpenID Connect](https://openid.net/connect/) (OIDC)-Aussteller-URL zugeordnet. Um AWS Identity and Access Management (IAM) -Rollen für Dienstkonten verwenden zu können, muss ein IAM-OIDC-Anbieter für die OIDC-Aussteller-URL Ihres Clusters vorhanden sein.
## Voraussetzungen
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Erste Schritte mit Amazon EKS](getting-started.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
Sie können einen IAM-OIDC-Anbieter für Ihren Cluster mit `eksctl` oder AWS-Managementkonsole erstellen.
## OIDC-Anbieter erstellen (eksctl)
1. Version `0.215.0` oder höher des `eksctl`-Befehlszeilen-Tools, das auf Ihrem Computer oder in der AWS CloudShell installiert ist. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
1. Ermitteln Sie die OIDC-Aussteller-ID für Ihren Cluster.
Rufen Sie die OIDC-Aussteller-ID Ihres Clusters ab und speichern Sie sie in einer Variable. Ersetzen Sie `` durch Ihren eigenen Wert.
```
cluster_name=
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
echo $oidc_id
```
1. Bestimmen Sie, ob ein IAM-OIDC-Anbieter mit der Aussteller-ID Ihres Clusters bereits in Ihrem Konto vorhanden ist.
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
Wenn die Ausgabe zurückgegeben wird, verfügen Sie bereits über einen IAM-OIDC-Anbieter für Ihren Cluster und können den nächsten Schritt überspringen. Wenn keine Ausgabe erfolgt, müssen Sie einen IAM-OIDC-Anbieter für Ihr Cluster erstellen.
1. Erstellen Sie einen IAM-OIDC-Identitätsanbieter für Ihren Cluster mit dem folgenden Befehl.
```
eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
```
**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. Es folgt ein Beispiel für eine Fehlermeldung:
```
** server cant find oidc.eks..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](https://github.com/aws/containers-roadmap/issues/2038) unter. GitHub
## OIDC-Anbieter erstellen (Konsole)AWS
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Bereich **Cluster** aus und wählen Sie dann den Namen Ihres Clusters auf der Seite **Cluster**.
1. Notieren Sie im Abschnitt **Details** der Registerkarte **Overview** (Übersicht) den Wert der **OpenID-Connect-Provider-URL**.
1. Öffnen Sie die IAM-Konsole unter. https://console.aws.amazon.com/iam/
1. Wählen Sie im linken Navigationsbereich **Identity Providers** (Identitätsanbieter) unter **Access management** (Zugriffsverwaltung) aus. Wenn ein **Anbieter** aufgeführt ist, der mit der URL für Ihren Cluster übereinstimmt, haben Sie bereits einen Anbieter für Ihren Cluster. Wenn kein Anbieter aufgeführt ist, der mit der URL für Ihren Cluster übereinstimmt, müssen Sie einen erstellen.
1. Um einen Anbieter zu erstellen, wählen Sie **Add provider** (Anbieter hinzufügen) aus.
1. Wählen Sie als **Anbietertyp** die Option **OpenID Connect** aus.
1. Geben Sie für **Anbieter URL** die OIDC-Anbieter-URL für Ihren Cluster ein.
1. Geben Sie für **Zielgruppe** `sts.amazonaws.com` ein
1. (Optional) Fügen Sie beliebige Tags hinzu, beispielsweise ein Tag, um zu identifizieren, welcher Cluster für diesen Anbieter ist.
1. Wählen Sie **Add provider** (Anbieter hinzufügen) aus.
Nächster Schritt: [IAM-Rollen Kubernetes-Servicekonten zuweisen](associate-service-account-role.md)
# IAM-Rollen Kubernetes-Servicekonten zuweisen
In diesem Thema wird beschrieben, wie Sie ein Kubernetes-Dienstkonto so konfigurieren, dass es eine AWS Identity and Access Management (IAM) -Rolle übernimmt. Alle Pods, die für die Verwendung des Dienstkontos konfiguriert sind, können dann auf jeden AWS Dienst zugreifen, für den die Rolle Zugriffsberechtigungen besitzt.
## Voraussetzungen
+ Einen vorhandenen -Cluster. Falls Sie noch kein Service-Konto haben, können Sie eines erstellen, indem Sie einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) folgen.
+ Ein vorhandener Anbieter für IAM OpenID Connect (OIDC) für Ihren Cluster. Informationen zum Feststellen, ob Sie bereits einen haben oder wie Sie einen erstellen können, finden Sie unter [Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster](enable-iam-roles-for-service-accounts.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
## Schritt 1: IAM-Richtlinie erstellen
Wenn Sie Ihrer IAM-Rolle eine vorhandene IAM-Richtlinie zuordnen möchten, fahren Sie mit dem nächsten Schritt fort.
1. Erstellen Sie eine IAM-Richtlinie. Sie können Ihre eigene Richtlinie erstellen oder eine AWS verwaltete Richtlinie kopieren, die bereits einige der benötigten Berechtigungen gewährt, und sie an Ihre spezifischen Anforderungen anpassen. Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
1. Erstellen Sie eine Datei, die die Berechtigungen für die AWS Dienste enthält, auf die Ihre Pods zugreifen sollen. Eine Liste aller Aktionen für alle AWS Dienste finden Sie in der [Referenz zur Dienstautorisierung](https://docs.aws.amazon.com/service-authorization/latest/reference/).
Sie können den folgenden Befehl ausführen, um eine Beispiel-Richtliniendatei zu erstellen, die schreibgeschützten Zugriff auf einen Amazon-S3-Bucket gewährt. Sie können optional Konfigurationsinformationen oder ein Bootstrap-Skript in diesem Bucket speichern und die Container in Ihrem Pod können die Datei aus dem Bucket lesen und in Ihre Anwendung laden. Wenn Sie diese Beispielrichtlinie erstellen möchten, kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-pod-secrets-bucket*Ersetzen Sie es durch Ihren Bucket-Namen und führen Sie den Befehl aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Erstellen Sie die IAM-Richtlinie.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
## Schritt 2: IAM-Rolle erstellen und zuordnen
Erstellen Sie eine IAM-Rolle und ordnen Sie diese einem Kubernetes-Servicekonto zu. Sie können entweder `eksctl` oder die AWS CLI verwenden.
### Rolle erstellen und zuordnen (eksctl)
Dieser `eksctl`-Befehl erstellt ein Kubernetes-Servicekonto im angegebenen Namespace, erstellt eine IAM-Rolle (sofern diese nicht bereits vorhanden ist) mit dem angegebenen Namen, fügt der Rolle eine vorhandene IAM-Richtlinie-ARN hinzu und annotiert das Servicekonto mit der IAM-Rollen-ARN. Denken Sie daran, die Beispiel-Platzhalterwerte in diesem Befehl durch Ihre spezifischen Werte zu ersetzen. Informationen zum Installieren und Aktualisieren von `eksctl` finden Sie in der Dokumentation zu `eksctl` unter [Installation](https://eksctl.io/installation).
```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
--attach-policy-arn arn:aws: iam::111122223333:policy/my-policy --approve
```
**Wichtig**
Wenn die Rolle oder das Servicekonto bereits vorhanden ist, schlägt der vorherige Befehl möglicherweise fehl. `eksctl` hat verschiedene Optionen, die Sie in diesen Situationen angeben können. Führen Sie `eksctl create iamserviceaccount --help` aus, um weitere Informationen zu erhalten.
### Rolle erstellen und zuordnen (AWS CLI)
Wenn Sie ein vorhandenes Kubernetes-Servicekonto haben, das eine IAM-Rolle annehmen soll, können Sie diesen Schritt überspringen.
1. Erstellen Sie ein Kubernetes-Servicekonto. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-service-account*Ersetzen Sie ihn durch Ihren gewünschten Namen und gegebenenfalls *default* durch einen anderen Namespace. Wenn Sie eine Änderung vornehmen*default*, muss der Namespace bereits existieren.
```
cat >my-service-account.yaml <
1. Stellen Sie sicher, dass die Vertrauensrichtlinie der IAM-Rolle korrekt konfiguriert ist.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Stellen Sie sicher, dass die Richtlinie, die Sie in einem vorherigen Schritt an Ihre Rolle angehängt haben, an die Rolle angehängt ist.
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
Eine Beispielausgabe sieht wie folgt aus.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Legen Sie eine Variable fest, um den Amazon-Ressourcennamen (ARN) der Richtlinie zu speichern, die Sie verwenden möchten. *my-policy*Ersetzen Sie ihn durch den Namen der Richtlinie, für die Sie Berechtigungen bestätigen möchten.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Zeigen Sie die Standardversion der Richtlinie an.
```
aws iam get-policy --policy-arn $policy_arn
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Überprüfen Sie den Inhalt der Richtlinie, um sicherzustellen, dass sie alle Berechtigungen enthält, die Ihr Pod benötigt. Falls erforderlich, ersetzen Sie *1* den folgenden Befehl durch die Version, die in der vorherigen Ausgabe zurückgegeben wurde.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Wenn Sie die Beispielrichtlinie in einem vorherigen Schritt erstellt haben, ist Ihre Ausgabe dieselbe. Wenn Sie eine andere Richtlinie erstellt haben, ist der *example* Inhalt anders.
1. Stellen Sie sicher, dass das Kubernetes-Servicekonto mit der Rolle annotiert ist.
```
kubectl describe serviceaccount my-service-account -n default
```
Eine Beispielausgabe sieht wie folgt aus.
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws: iam::111122223333:role/my-role
Image pull secrets:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## Nächste Schritte
+ [Konfiguration von Pods für die Verwendung eines Kubernetes-Servicekontos](pod-configuration.md)
# Konfiguration von Pods für die Verwendung eines Kubernetes-Servicekontos
Wenn ein Pod auf AWS Dienste zugreifen muss, müssen Sie ihn für die Verwendung eines Kubernetes-Dienstkontos konfigurieren. Das Dienstkonto muss einer AWS Identity and Access Management (IAM) -Rolle zugeordnet sein, die über Berechtigungen für den Zugriff auf die AWS Dienste verfügt.
+ Einen vorhandenen -Cluster. Wenn Sie keine Rolle haben, können Sie sie mithilfe einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen.
+ Ein vorhandener Anbieter für IAM OpenID Connect (OIDC) für Ihren Cluster. Informationen zum Feststellen, ob Sie bereits einen haben oder wie Sie einen erstellen können, finden Sie unter [Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster](enable-iam-roles-for-service-accounts.md).
+ Ein vorhandenes Kubernetes-Servicekonto, das einer IAM-Rolle zugeordnet ist. Das Servicekonto muss mit dem Amazon-Ressourcennamen (ARN) der IAM-Rolle versehen sein. Der Rolle muss eine IAM-Richtlinie zugeordnet sein, die die Berechtigungen enthält, die Ihre Pods für die Nutzung AWS von Diensten haben sollen. Weitere Informationen zu Rollen, ihren Vorteilen sowie zu ihrer Erstellung und Konfiguration finden Sie unter [IAM-Rollen Kubernetes-Servicekonten zuweisen](associate-service-account-role.md).
+ Version `2.12.3` oder höher oder Version `1.27.160` oder höher der auf Ihrem Gerät installierten und konfigurierten AWS Befehlszeilenschnittstelle (AWS CLI) oder AWS CloudShell. Um Ihre aktuelle Version zu überprüfen, verwenden Sie `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im *Benutzerhandbuch für die AWS Befehlszeilenschnittstelle*. Die AWS CLI-Version, in der installiert ist, AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im * AWS CloudShell Benutzerhandbuch* unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
1. Verwenden Sie den folgenden Befehl, um ein Bereitstellungs-Manifest zu erstellen, mit dem Sie einen Pod bereitstellen können, um die Konfiguration zu bestätigen. Ersetzen Sie die Beispielwerte durch eigene Werte.
```
cat >my-deployment.yaml <
Wenn Sie ein Kubernetes-Servicekonto mit [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) verwenden, können Sie den Typ des AWS-Sicherheitstoken-Service-Endpunkts konfigurieren, der vom Servicekonto verwendet wird.
AWS empfiehlt die Verwendung der regionalen AWS-STS-Endpunkte statt des globalen Endpunkts. Dies reduziert die Latenz, bietet integrierte Redundanz und erhöht die Gültigkeit der Sitzungstoken. Der AWS-Sicherheitstoken-Service muss in der AWS-Region, in welcher der Pod ausgeführt wird, aktiv sein. Ihre Anwendung muss außerdem über integrierte Redundanz verfügen, um bei Ausfall des Service in der AWS-Region eine andere AWS-Region auszuwählen. Weitere Informationen finden Sie unter [Verwaltung von AWS STS in einer AWS-Region](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html) im IAM-Benutzerhandbuch.
+ Einen vorhandenen -Cluster. Wenn Sie keine Rolle haben, können Sie sie mithilfe einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen.
+ Ein vorhandener IAM-OIDC-Anbieter für Ihren Cluster. Weitere Informationen finden Sie unter [Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster](enable-iam-roles-for-service-accounts.md).
+ Ein vorhandenes Kubernetes-Servicekonto, das für die Verwendung mit der Funktion [Amazon-EKS-IAM für Servicekonten](iam-roles-for-service-accounts.md).
Die folgenden Beispiele verwenden alle das vom [Amazon-VPC-CNI-Plugin](cni-iam-role.md) verwendete Kubernetes-Servicekonto aws-node. Sie können die *Beispielwerte* durch eigene Servicekonten, Pods, Namespaces und anderen Ressourcen ersetzen.
1. Wählen Sie einen Pod aus, der ein Servicekonto verwendet, für das Sie den Endpunkt ändern möchten. Bestimmen Sie, in welcher AWS-Region der Pod ausgeführt wird. Ersetzen Sie *aws-node-6mfgv* durch den Namen Ihres Pods und *kube-system* mit dem Namespace Ihres Pods.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
Eine Beispielausgabe sieht wie folgt aus.
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
In der vorherigen Ausgabe wird der Pod in einem Knoten in der AWS-Region us-west-2 ausgeführt.
1. Ermitteln Sie den Endpunkt-Typ, den das Servicekonto des Pods verwendet.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Eine Beispielausgabe sieht wie folgt aus.
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
Wenn der aktuelle Endpunkt global ist, dann wird `global` in der Ausgabe zurückgegeben. Wenn keine Ausgabe zurückgegeben wird, wird der Standard-Endpunkttyp verwendet und wurde nicht überschrieben.
1. Wenn Ihre Cluster- oder Plattformversion dieselbe oder höher ist als die in der Tabelle aufgeführten, können Sie den von Ihrem Servicekonto verwendeten Endpunkttyp mit einem der folgenden Befehle vom Standardtyp in einen anderen Typ ändern. Ersetzen Sie *aws-node* durch den Namen Ihres Servicekontos und *kube-system* durch den Namespace Ihres Servicekontos.
+ Wenn Ihr Standard- oder aktueller Endpunkttyp global ist und Sie ihn in regional ändern möchten:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
Wenn Sie [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) verwenden, um vorsignierte S3-URLs in Ihrer Anwendung zu generieren, die in Pods-Containern ausgeführt wird, ähnelt das Format der URL für regionale Endpunkte dem folgenden Beispiel:
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ Wenn Ihr Standard- oder aktueller Endpunkttyp regional ist und Sie ihn in global ändern möchten:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
Wenn Ihre Anwendung explizit Anfragen an globale AWS-STS-Endpunkte stellt und Sie das Standardverhalten der Verwendung regionaler Endpunkte in Amazon-EKS-Clustern nicht außer Kraft setzen, werden Anfragen mit einem Fehler fehlschlagen. Weitere Informationen finden Sie unter [Pod-Container erhalten folgenden Fehler: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).
Wenn Sie [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) verwenden, um vorsignierte S3-URLs in Ihrer Anwendung zu generieren, die in Pods-Containern ausgeführt wird, entspricht das Format der URL für globale Endpunkte in etwa dem folgenden Beispiel:
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
Wenn Sie über eine Automatisierung verfügen, welche die vorsignierte URL in einem bestimmten Format erwartet, oder wenn Ihre Anwendung oder Downstream-Abhängigkeiten, die vorsignierte URLs verwenden, eine bestimmte AWS-Region als Ziel erwarten, nehmen Sie die notwendigen Änderungen vor, um den entsprechenden AWS-sTS-Endpunkt zu verwenden.
1. Löschen Sie alle vorhandenen Pods, die dem Servicekonto zugeordnet sind, und erstellen Sie sie neu, um die Umgebungsvariablen für Anmeldeinformationen anzuwenden. Der mutierende Webhook wendet sie nicht auf Pods an, die bereits ausgeführt werden. Sie können *Pods*, *kube-system*, und*-l k8s-app=aws-Knoten* mit den Informationen für die Pods, für die Sie Ihre Annotation festlegen, ersetzen.
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Bestätigen Sie, dass alle Pods neu gestartet wurden.
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. Zeigen Sie die Umgebungsvariablen für einen der Pods an. Stellen Sie sicher, dass der `AWS_STS_REGIONAL_ENDPOINTS`-Wert der ist, den Sie im vorherigen Schritt festgelegt haben.
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Eine Beispielausgabe sieht wie folgt aus.
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# Authentifizierung bei einem anderen Konto mit IRSA
Sie können kontoübergreifende IAM-Berechtigungen konfigurieren, indem Sie entweder einen Identitätsanbieter aus dem Cluster eines anderen Kontos erstellen oder verkettete `AssumeRole`-Operationen verwenden. In den folgenden Beispielen besitzt *Konto A* einen Amazon-EKS-Cluster, der IAM-Rollen für Servicekonten unterstützt. Pods, die in diesem Cluster ausgeführt werden, müssen IAM-Berechtigungen von *Konto B* annehmen.
+ **Option 1** ist einfacher, erfordert jedoch, dass Konto B einen OIDC-Identitätsanbieter für den Cluster von Konto A erstellt und verwaltet.
+ **Option 2** behält die OIDC-Verwaltung in Konto A bei, erfordert jedoch eine Rollenverkettung über zwei Aufrufe. `AssumeRole`
## Option 1: Erstellen Sie einen Identitätsanbieter aus dem Cluster eines anderen Kontos
In diesem Beispiel stellt Konto A dem Konto B die OpenID Connect (OIDC)-Aussteller-URL aus seinem Cluster bereit. Konto B befolgt die Anweisungen unter [Erstellen eines IAM-OIDC-Anbieters für Ihren Cluster](enable-iam-roles-for-service-accounts.md) und [IAM-Rollen Kubernetes-Servicekonten zuweisen](associate-service-account-role.md) unter Verwendung der OIDC-Aussteller-URL aus dem Cluster von Konto A. Anschließend fügt ein Clusteradministrator dem Dienstkonto im Cluster von Konto A Anmerkungen hinzu, um die Rolle von Konto B (*444455556666*) zu verwenden.
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws: iam::444455556666:role/account-b-role
```
## Option 2: Verwenden Sie verkettete Operationen `AssumeRole`
Bei diesem Ansatz erstellt jedes Konto eine IAM-Rolle. Die Rolle von Konto B vertraut Konto A, und die Rolle von Konto A verwendet den OIDC-Verbund, um Anmeldeinformationen vom Cluster abzurufen. Der Pod verkettet dann die beiden Rollen mithilfe von AWS CLI-Profilen miteinander.
### Schritt 1: Erstellen Sie die Zielrolle in Konto B
Konto B (*444455556666*) erstellt eine IAM-Rolle mit den Berechtigungen, die Pods im Cluster von Konto A benötigen. Konto B fügt dieser Rolle die gewünschte Berechtigungsrichtlinie hinzu und fügt dann die folgende Vertrauensrichtlinie hinzu.
**Vertrauensrichtlinie für die Rolle von Konto B** — Diese Richtlinie ermöglicht es der spezifischen IRSA-Rolle von Konto A, diese Rolle zu übernehmen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**Wichtig**
Für geringste Rechte ersetzen Sie den `Principal` ARN durch den spezifischen Rollen-ARN von Konto A, anstatt das Konto root (`arn:aws:iam::111122223333:root`) zu verwenden. Wenn Sie den Kontostamm verwenden, kann *jeder* IAM-Prinzipal in Konto A diese Rolle übernehmen.
### Schritt 2: Erstellen Sie die IRSA-Rolle in Konto A
Konto A (*111122223333*) erstellt eine Rolle mit einer Vertrauensrichtlinie, die Anmeldeinformationen von dem Identitätsanbieter erhält, der mit der OIDC-Ausstelleradresse des Clusters erstellt wurde.
**Vertrauensrichtlinie für die Rolle von Konto A (OIDC-Verbund)** — Diese Richtlinie ermöglicht es dem OIDC-Anbieter des EKS-Clusters, Anmeldeinformationen für diese Rolle auszustellen.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**Wichtig**
Fügen Sie für geringste Rechte eine `StringEquals` Bedingung für den `sub` Anspruch hinzu, diese Rolle auf ein bestimmtes Kubernetes-Dienstkonto zu beschränken. Ohne eine `sub` Bedingung kann jedes Dienstkonto im Cluster diese Rolle übernehmen. Der `sub` Wert verwendet das Format`system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Um beispielsweise auf ein `my-service-account` im `default` Namespace benanntes Dienstkonto zu beschränken:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Schritt 3: Hängen Sie die AssumeRole Berechtigung an die Rolle von Konto A an
Konto A fügt der in Schritt 2 erstellten Rolle eine Berechtigungsrichtlinie hinzu. Diese Richtlinie ermöglicht es der Rolle, die Rolle von Konto B zu übernehmen.
**Berechtigungsrichtlinie für die Rolle von Konto A** — Diese Richtlinie gewährt `sts:AssumeRole` dem Konto B die Zielrolle.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Schritt 4: Konfigurieren Sie den Pod so, dass er Rollen verkettet
Der Anwendungscode für Pods, welche die Rolle von Konto B übernehmen sollen, verwendet zwei Profile: `account_b_role` und `account_a_role`. Das `account_b_role`-Profil verwendet das `account_a_role`-Profil als Quelle. Für die AWS CLI ähnelt die `~/.aws/config` Datei der folgenden.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws: iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws: iam::111122223333:role/account-a-role
```
Informationen zur Angabe verketteter Profile für andere AWS SDKs finden Sie in der Dokumentation für das SDK, das Sie verwenden. Weitere Informationen finden Sie unter [Tools, auf AWS denen Sie aufbauen können](https://aws.amazon.com/developer/tools/).
# IRSA mit dem AWS-SDK verwenden
**Verwenden von Anmeldeinformationen**
Um die Anmeldeinformationen von IAM-Rollen für Servicekonten (IRSA) zu verwenden, kann Ihr Code ein beliebiges AWS-SDK verwenden, um einen Client für einen AWS-Service mit einem SDK zu erstellen. Standardmäßig sucht das SDK in einer Kette von Speicherorten nach zu verwendenden Anmeldeinformationen für AWS. Die IAM-Rollen für Anmeldeinformationen für Servicekonten werden verwendet, wenn Sie bei der Erstellung des Clients keinen Anmeldeinformationsanbieter angeben oder Sie das SDK anderweitig initialisiert haben.
Das funktioniert, weil IAM-Rollen für Servicekonten als Schritt in der standardmäßigen Anmeldeinformationskette hinzugefügt wurden. Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die sich an früherer Stelle in der Anmeldeinformationskette befinden, werden diese Anmeldeinformationen auch dann weiterhin verwendet, wenn Sie IAM-Rollen für Servicekonten für dieselbe Workload konfigurieren.
Mithilfe der `AssumeRoleWithWebIdentity`-Aktion tauscht das SDK das OIDC-Token des Servicekontos automatisch gegen temporäre Anmeldeinformationen vom AWS-Sicherheits-Token-Service aus. Amazon EKS und diese SDK-Aktion rotieren weiterhin die temporären Anmeldeinformationen, indem sie erneuert werden, bevor sie ablaufen.
Wenn Sie [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md) benutzen, müssen die Container in Ihren eine AWS-SDK-Version verwenden, welche die Annahme einer IAM-Rolle über eine Token-Datei für OpenID-Connect-Webidentitäts unterstützt. Stellen Sie sicher, dass Sie die folgenden Versionen oder höher für Ihr AWS-SDK verwenden:
+ Java (Version 2) – [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Java – [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ AWS SDK für Go v1 – [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ AWS SDK für Go v2 – Support für alle Versionen
+ Python (Boto3) — [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ Python (botocore) —[1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ Knoten – [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) und [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ Ruby – [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ C\$1\$1 – [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET – [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) – Sie müssen auch `AWSSDK.SecurityToken` angeben.
+ PHP – [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
Viele gängige Kubernetes- Add-Ons, wie beispielsweise der [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), das [Routing des Internet-Datenverkehrs mit AWS Load Balancer Controller](aws-load-balancer-controller.md) und das [Amazon-VPC-CNI-Plugin für Kubernetes](cni-iam-role.md), unterstützen IAM-Rollen für Servicekonten.
Um sicherzustellen, dass Sie ein unterstütztes SDK verwenden, befolgen Sie die Installationsanweisungen für Ihr bevorzugtes SDK unter [Tools für die Entwickelung in AWS](https://aws.amazon.com/tools/), wenn Sie Ihre Container entwickeln.
## Überlegungen
### Java
Wenn Sie Java verwenden, *müssen* Sie das `sts`-Modul in den Klassenpfad aufnehmen. Weitere Informationen finden Sie unter [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html) in den Java SDK-Dokumenten.
# Signaturschlüssel zur Validierung von OIDC-Token abrufen
Kubernetes vergibt einen `ProjectedServiceAccountToken` an jedes Kubernetes-Servicekonto. Dieser Token ist ein OIDC-Token, bei dem es wiederum um eine Art JSON-Web-Token (JWT) handelt. Amazon EKS Hostet für jeden Cluster einen öffentlichen OIDC-Endpunkt, der die Signaturschlüssel für das Token enthält, sodass externe Systeme es validieren können.
Um einen `ProjectedServiceAccountToken` zu validieren, müssen Sie die öffentlichen OIDC-Signaturschlüssel abrufen, die auch als JSON Web Key Set (JWKS) bezeichnet werden. Verwenden Sie diese Schlüssel in Ihrer Anwendung, um das Token zu validieren. Sie können beispielsweise die [Python-Bibliothek PyJWT](https://pyjwt.readthedocs.io/en/latest/) verwenden, um Token mit diesen Schlüsseln zu validieren. Weitere Informationen zu `ProjectedServiceAccountToken` finden Sie unter [Hintergrundinformationen zu IAM, Kubernetes und OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).
## Voraussetzungen
+ Ein vorhandener Anbieter für AWS Identity and Access Management (IAM) OpenID Connect (OIDC) für Ihren Cluster. Informationen zum Feststellen, ob Sie bereits über einen verfügen oder einen erstellen müssen, finden Sie unter [Erstellen Sie einen IAM-OIDC-Anbieter für Ihren Cluster](enable-iam-roles-for-service-accounts.md).
+ ** AWS-CLI** – Ein Befehlszeilen-Tool für die Arbeit mit AWS-Services, einschließlich Amazon EKS. Weitere Informationen finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) im Benutzerhandbuch der AWS-Befehlszeilenschnittstelle. Nach der Installation der AWS-CLI empfehlen wir, sie auch zu konfigurieren. Weitere Informationen finden Sie unter [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im Benutzerhandbuch zur AWS-Befehlszeilenschnittstelle.
## Verfahren
1. Rufen Sie die OIDC-URL für Ihren Amazon-EKS-Cluster mithilfe der AWS-CLI ab.
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. Rufen Sie den öffentlichen Signaturschlüssel mit curl oder einem ähnlichen Tool ab. Das Ergebnis ist ein [JSON Web Key Set (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5).
**Wichtig**
Amazon EKS drosselt das Aufrufen des OIDC-Endpunkts. Es wird empfohlen, den öffentlichen Signaturschlüssel zwischenzuspeichern. Beachten Sie die in der Antwort enthaltene `cache-control`-Kopfzeile.
**Wichtig**
Amazon EKS rotiert den OIDC-Signaturschlüssel alle sieben Tage.
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt
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.
*EKS-Pod-Identitäten* 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.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
Jede EKS-Pod-Identity-Zuordnung ordnet einem Servicekonto in einem Namespace im angegebenen Cluster eine Rolle zu. Wenn Sie dieselbe Anwendung in mehreren Clustern haben, können Sie in jedem Cluster identische Zuordnungen vornehmen, ohne die Vertrauensrichtlinie der Rolle zu ändern.
Wenn ein Pod ein Servicekonto mit einer Zuordnung verwendet, legt Amazon EKS Umgebungsvariablen in den Containern des Pods fest. Die Umgebungsvariablen konfigurieren die AWS-SDKs, einschließlich der AWS-CLI, für die Verwendung der Anmeldeinformationen für EKS Pod Identity.
## Vorteile von EKS-Pod-Identitäten
EKS-Pod-Identitäten bieten 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)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) 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](create-node-role.md) 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](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**Anmerkung**
Mit `hostNetwork: true` konfigurierte Pods haben immer IMDS-Zugriff, aber die AWS-SDKs und die CLI verwenden bei Aktivierung die Pod-Identity-Anmeldeinformationen.
+ **Überprüfbarkeit** – Die Zugriffs- und Ereignisprotokollierung ist über AWS CloudTrail verfügbar, um eine nachträgliche Überprüfung zu vereinfachen.
**Wichtig**
Container stellen keine Sicherheitsgrenze dar und die Verwendung von Pod Identity ä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.
EKS Pod Identity ist eine einfachere Methode als [IAM-Rollen für Servicekonten](iam-roles-for-service-accounts.md), da diese keine OIDC-Identitätsanbieter nutzt. EKS Pod Identity bietet die folgenden Verbesserungen:
+ **Unabhängiger Betrieb** – In vielen Organisationen liegt die Verantwortung für die Erstellung von OIDC-Identitätsanbietern bei anderen Teams als für die Verwaltung der Kubernetes-Cluster. EKS Pod Identity hat eine klare Aufgabentrennung: Die gesamte Konfiguration der EKS-Pod-Identity-Zuordnungen erfolgt in Amazon EKS und die gesamte Konfiguration der IAM-Berechtigungen erfolgt in IAM.
+ **Wiederverwendbarkeit** – EKS Pod Identity verwendet einen einzigen IAM-Prinzipal anstelle der separaten Prinzipale für jeden Cluster, den IAM-Rollen für Servicekonten verwenden. Ihr IAM-Administrator fügt der Vertrauensrichtlinie jeder Rolle den folgenden Prinzipal hinzu, damit sie von EKS-Pod-Identitäten verwendet werden kann.
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **Skalierbarkeit** – Jeder Satz temporärer Anmeldeinformationen wird vom EKS-Service in EKS Pod Identity angenommen statt von jedem AWS-SDK, das Sie in jedem Pod ausführen. Anschließend stellt der Amazon EKS Pod Identity Agent, der auf jedem Knoten ausgeführt wird, die Anmeldeinformationen an die SDKs aus. Dadurch wird die Last für jeden Knoten reduziert und nicht in jedem Pod dupliziert. Weitere Details zu diesem Prozess finden Sie unter [Funktionsweise von EKS Pod Identity verstehen](pod-id-how-it-works.md).
Weitere Informationen zum Vergleich der beiden Alternativen finden Sie unter [Kubernetes-Workloads Zugriff auf AWS mithilfe von Kubernetes-Servicekonten gewähren](service-accounts.md).
## Übersicht über die Einrichtung von EKS-Pod-Identitäten
Aktivieren Sie EKS-Pod-Identitäten, indem Sie die folgenden Verfahren ausführen:
1. [Einrichtung des Amazon-EKS-Pod-Identity-Agenten](pod-id-agent-setup.md) – Sie führen diesen Vorgang für jeden Cluster nur einmal durch. Sie müssen diesen Schritt nicht ausführen, wenn EKS Auto Mode in Ihrem Cluster aktiviert ist.
1. [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md) – Führen Sie dieses Verfahren für jeden einzelnen Berechtigungssatz durch, den eine Anwendung haben soll.
1. [Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren](pod-id-configure-pods.md) – Führen Sie dieses Verfahren für jeden Pod durch, der Zugriff auf AWS-Services benötigt.
1. [Verwendung der Pod Identity mit dem AWS-SDK](pod-id-minimum-sdk.md) – Stellen Sie sicher, dass der Workload ein AWS-SDK einer unterstützten Version verwendet und dass der Workload die Kette standardmäßiger Anmeldeinformationen verwendet.
## Grenzwerte
+ Pro Cluster werden bis zu 5 000 EKS-Pod-Identity-Zuordnungen unterstützt, um IAM-Rollen Kubernetes-Servicekonten zuzuordnen.
## Überlegungen
+ **IAM-Rollenzuordnung**: Jedes Kubernetes-Servicekonto in einem Cluster kann einer IAM-Rolle aus demselben AWS-Konto wie das Cluster zugeordnet werden. Sie ändern die Rolle, indem Sie die EKS-Pod-Identity-Zuordnung bearbeiten. Für den kontenübergreifenden Zugriff delegieren Sie den Zugriff auf die Rolle mithilfe von IAM-Rollen. Weitere Informationen finden Sie unter [Delegieren des Zugriffs über alle AWS-Konten hinweg mithilfe von IAM-Rollen](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) im *IAM-Benutzerhandbuch*.
+ **EKS-Pod-Identity-Agent**: Der Pod-Identity-Agent ist zur Verwendung von EKS Pod Identity erforderlich. Der Agent wird als Kubernetes `DaemonSet` in Cluster-Knoten ausgeführt und stellt Anmeldeinformationen nur für Pods auf demselben Knoten bereit. Er verwendet das `hostNetwork` des Knotens und belegt die Ports `80` und `2703` auf der link-lokalen Adresse (`169.254.170.23` für IPv4, `[fd00:ec2::23]` für IPv6). Wenn IPv6 in Ihrem Cluster deaktiviert ist, deaktivieren Sie IPv6 für den Pod-Identity-Agent. Weitere Informationen finden Sie unter [IPv6 im EKS-Pod-Identity-Agent deaktivieren](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+ **Eventuelle Konsistenz**: EKS-Pod-Identity-Zuordnungen sind letztendlich konsistent, mit möglichen Verzögerungen von mehreren Sekunden nach API-Aufrufen. Vermeiden Sie die Erstellung oder Aktualisierung von Verknüpfungen in kritischen Code-Pfaden mit hoher Verfügbarkeit. Führen Sie diese Aktionen stattdessen in separaten, weniger häufigen Initialisierungs- oder Einrichtungsroutinen durch. Weitere Informationen finden Sie unter [Sicherheitsgruppen pro Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) im *EKS-Leitfaden für bewährte Methoden*.
+ **Überlegungen zu Proxy und Sicherheitsgruppe**: Bei Pods, die einen Proxy verwenden, fügen Sie `169.254.170.23` (IPv4) und `[fd00:ec2::23]` (IPv6) zu den `no_proxy/NO_PROXY`-Umgebungsvariablen hinzu, um fehlgeschlagene Anfragen an den EKS-Pod-Identity-Agent zu vermeiden. Wenn Sie Sicherheitsgruppen für Pods mit AWS VPC CNI verwenden, setzen Sie das `ENABLE_POD_ENI`-Flag auf „true“ und das `POD_SECURITY_GROUP_ENFORCING_MODE`-Flag auf „standard“. Weitere Informationen finden Sie unter [Zuweisen von Sicherheitsgruppen zu einzelnen Pods](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).
### Cluster-Versionen von EKS Pod Identity
Um EKS Pod Identity nutzen zu können, muss der Cluster über eine Plattformversion verfügen, die mindestens der in der folgenden Tabelle aufgeführten Version entspricht, oder über eine Kubernetes-Version, die neuer ist als die in der Tabelle aufgeführten Versionen. Die empfohlene Version des Amazon-EKS-Pod-Identity-Agent für eine Kubernetes-Version finden Sie unter [Kompatibilität der Add-On-Version von Amazon EKS mit einem Cluster überprüfen](addon-compat.md).
| Kubernetes-Version | Plattformversion |
| --- | --- |
| Nicht aufgeführte Kubernetes-Versionen | Alle Plattformversionen werden unterstützt |
| `1.28` | `eks.4` |
### Einschränkungen von EKS Pod Identity
EKS-Pod-Identitäten sind auf folgenden Plattformen verfügbar:
+ Amazon-EKS-Cluster-Versionen, die im vorherigen Thema ([Cluster-Versionen von EKS Pod Identity](#pod-id-cluster-versions)) aufgeführt wurden.
+ Worker-Knoten im Cluster, die Linux-Amazon-EC2-Instances sind.
EKS Pod Identities sind auf folgenden Plattformen nicht verfügbar:
+ AWS Outposts
+ Amazon EKS Anywhere.
+ Kubernetes-Cluster, die Sie in Amazon EC2 erstellen und ausführen. Die EKS-Pod-Identity-Komponenten sind nur in Amazon EKS verfügbar.
Sie können EKS Pod Identities nicht verwenden mit:
+ Pods, die nicht auf Linux-Amazon-EC2-Instances ausgeführt werden. Linux- und Windows-Pods, die in AWS Fargate (Fargate) ausgeführt werden, werden nicht unterstützt. In Windows-Amazon-EC2-Instances ausgeführte Pods werden nicht unterstützt.
# Funktionsweise von EKS Pod Identity verstehen
Amazon-EKS-Pod-Identity-Zuordnungen bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie Amazon-EC2-Instance-Profile Anmeldeinformationen für Amazon-EC2-Instances bereitstellen.
Amazon EKS Pod Identity bietet Anmeldeinformationen für Ihre Workloads mit einer zusätzlichen *EKS-Auth-API* und einem Agent-Pod, der auf jedem Knoten ausgeführt wird.
In Ihren Add-ons, z. B. *Amazon-EKS-Add-ons* und Add-ons für selbstverwaltete Controller und Operatoren, muss der Autor seine Software aktualisieren, um die neuesten AWS-SDKs verwenden zu können. Die Liste der Kompatibilität zwischen EKS Pod Identity und den von Amazon EKS produzierten Add-ons finden Sie im vorherigen Abschnitt ([Einschränkungen von EKS Pod Identity](pod-identities.md#pod-id-restrictions)).
## Verwenden von EKS-Pod-Identitäten in Ihrem Code
In Ihrem Code können Sie die AWS-SDKs verwenden, um auf AWS-Services zuzugreifen. Sie schreiben Code, um einen Client für einen AWS-Service mit einem SDK zu erstellen. Standardmäßig sucht das SDK in einer Kette von Speicherorten nach zu verwendenden Anmeldeinformationen für AWS-Identitäts- und Zugriffsverwaltung. Nachdem gültige Anmeldeinformationen gefunden wurden, wird die Suche beendet. Weitere Informationen zu den verwendeten Standardspeicherorten finden Sie unter [Anbieterkette von Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) im Referenzhandbuch für AWS-SDKs und -Tools.
EKS-Pod-Identitäten wurden dem *Anbieter für Container-Anmeldeinformationen* hinzugefügt, der in einem Schritt in der standardmäßigen Anmeldeinformationskette durchsucht wird. Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren. Auf diese Weise können Sie sicher von anderen Anmeldeinformationstypen migrieren, indem Sie die Zuordnung erstellen, bevor Sie die alten Anmeldeinformationen entfernen.
Der Anbieter für Container-Anmeldeinformationen stellt temporäre Anmeldeinformationen über einen Agent bereit, der auf jedem Knoten ausgeführt wird. In Amazon EKS ist dies der Amazon EKS Pod Identity Agent und bei Amazon Elastic Container Service ist es der `amazon-ecs-agent`. Die SDKs verwenden Umgebungsvariablen, um den Agent zu finden, zu dem eine Verbindung hergestellt werden soll.
Im Gegensatz dazu stellen *IAM-Rollen für Servicekonten* ein Token für *Web-Identität* bereit, welches das AWS-SDK mithilfe von `AssumeRoleWithWebIdentity` mit dem AWS-Sicherheitstoken-Service austauschen muss.
## Funktionsweise von EKS-Pod-Identity-Agent mit einem Pod
1. Wenn Amazon EKS einen neuen Pod startet, der ein Servicekonto mit einer EKS-Pod-Identity-Zuordnung verwendet, fügt der Cluster dem Pod-Manifest den folgenden Inhalt hinzu:
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. Kubernetes wählt aus, auf welchem Knoten der Pod ausgeführt werden soll. Anschließend verwendet der Amazon EKS Pod Identity Agent im Knoten die Aktion [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html), um von der EKS-Auth-API temporäre Anmeldeinformationen abzurufen.
1. Der EKS Pod Identity Agent stellt diese Anmeldeinformationen für die AWS-SDKs zur Verfügung, die Sie in Ihren Containern ausführen.
1. Sie nutzen das SDK in Ihrer Anwendung, ohne einen Anmeldeinformationsanbieter für die Verwendung der standardmäßigen Anmeldeinformationskette anzugeben. Oder Sie geben den Anbieter für Container-Anmeldeinformationen an. Weitere Informationen zu den verwendeten Standardspeicherorten finden Sie unter [Anbieterkette von Anmeldeinformationen](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) im Referenzhandbuch für AWS-SDKs und -Tools.
1. Das SDK verwendet die Umgebungsvariablen, um eine Verbindung zum EKS Pod Identity Agent herzustellen und die Anmeldeinformationen abzurufen.
**Anmerkung**
Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren.
# Einrichtung des Amazon-EKS-Pod-Identity-Agenten
Amazon EKS Pod Identity-Zuordnungen bieten die Möglichkeit, Anmeldeinformationen für Ihre Anwendungen zu verwalten, ähnlich wie EC2 Amazon-Instance-Profile Anmeldeinformationen für EC2 Amazon-Instances bereitstellen.
Amazon EKS Pod Identity bietet Anmeldeinformationen für Ihre Workloads mit einer zusätzlichen *EKS-Auth-API* und einem Agent-Pod, der auf jedem Knoten ausgeführt wird.
**Tipp**
Es ist nicht erforderlich, den EKS-Pod-Identity-Agent auf EKS-Auto-Mode-Clustern zu installieren. Diese Funktion ist in EKS Auto Mode integriert.
## Überlegungen
+ Standardmäßig ist der EKS-Pod-Identity-Agent auf EKS-Auto-Mode-Clustern vorinstalliert. Weitere Informationen hierzu finden Sie unter [Automatisieren der Cluster-Infrastruktur mit dem EKS-Automatikmodus](automode.md).
+ Standardmäßig überwacht der EKS-Pod-Identity-Agent eine `IPv4`- und `IPv6`-Adresse auf Pods, die Anmeldeinformationen anfordern. Der Agent verwendet die Loopback-IP-Adresse (localhost) `169.254.170.23` für `IPv4` und die localhost-IP-Adresse `[fd00:ec2::23]` für `IPv6`.
+ Wenn Sie `IPv6`-Adressen deaktivieren oder localhost-IP-Adressen `IPv6` anderweitig verhindern, kann der Agent nicht gestartet werden. Um den Agenten auf Knoten zu starten, die `IPv6` nicht verwenden können, befolgen Sie die Schritte unter [Deaktivierung von `IPv6` im EKS-Pod-Identity-Agent](pod-id-agent-config-ipv6.md), um die `IPv6`-Konfiguration zu deaktivieren.
## Erstellen des Amazon EKS Pod Identity Agent
### Voraussetzungen für den Agent
+ Ein vorhandener Amazon-EKS-Cluster. Informationen zum Bereitstellen finden Sie unter [Erste Schritte mit Amazon EKS](getting-started.md). Die Cluster-Version und die Plattformversion müssen mit den in den [EKS-Pod-Identity-Cluster-Versionen](pod-identities.md#pod-id-cluster-versions) aufgeführten Versionen übereinstimmen oder höher sein.
+ Die Knotenrolle verfügt über Berechtigungen für den Agent, um die `AssumeRoleForPodIdentity`-Aktion in der EKS-Auth-API auszuführen. Sie können die [AWS verwaltete Richtlinie verwenden: Amazon EKSWorker NodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) oder eine benutzerdefinierte Richtlinie hinzufügen, die der folgenden ähnelt:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
Diese Aktion kann durch Tags beschränkt werden, um einzuschränken, welche Rollen von Pods übernommen werden können, die den Agent verwenden.
+ Die Knoten können auf Amazon ECR zugreifen und Images von Amazon ECR herunterladen. Das Container-Image für das Add-On befindet sich in den Registies, die unter [Amazon-Container-Image-Registries für Amazon-EKS-Add-Ons anzeigen](add-ons-images.md) aufgeführt sind.
Beachten Sie, dass Sie den Speicherort des Images ändern und EKS-Add-Ons in den **optionalen Konfigurationseinstellungen** in der AWS-Managementkonsole und `--configuration-values` in der AWS CLI bereitstellen `imagePullSecrets` können.
+ Die Knoten können die Amazon-EKS-Auth-API erreichen. Für private Cluster ist der `eks-auth` AWS PrivateLink Endpunkt-Eingang erforderlich.
### Agent mit AWS Konsole einrichten
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-on „EKS Pod Identity Agent“ konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Wählen Sie **Weitere Add-Ons erhalten**.
1. Wählen Sie das Kästchen oben rechts im Add-on-Bereich für EKS Pod Identity Agent aus und gehen Sie dann auf **Bearbeiten**.
1. Wählen Sie auf der Seite **Konfigurieren ausgewählter Add-ons-Einstellungen** eine beliebige Version in der Dropdown-Liste **Version** aus.
1. (Optional) Erweitern Sie **Optionale Konfigurationseinstellungen**, um eine zusätzliche Konfiguration einzugeben. Sie können beispielsweise einen alternativen Speicherort für das Container-Image und `ImagePullSecrets` angeben. Das JSON-Schema mit den akzeptierten Schlüsseln wird im **Add-On-Konfigurationsschema** angezeigt.
Geben Sie die Konfigurationsschlüssel und Werte in das Feld **Konfigurationswerte** ein
1. Wählen Sie **Weiter** aus.
1. Vergewissern Sie sich, dass die EKS-Pod-Identity-Pods auf Ihrem Cluster ausgeführt werden.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Eine Beispielausgabe sieht wie folgt aus.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Sie können jetzt EKS-Pod-Identity-Zuordnungen in Ihrem Cluster verwenden. Weitere Informationen finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).
### Agent mit AWS CLI einrichten
1. Führen Sie den folgenden AWS CLI-Befehl aus. Ersetzen Sie `my-cluster` mit dem Namen Ihres Clusters.
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**Anmerkung**
Der EKS-Pod-Identity-Agent verwendet den `service-account-role-arn` nicht für *IAM-Rollen für Servicekonten*. Sie müssen dem EKS Pod Identity Agent Berechtigungen für die Knotenrolle gewähren.
1. Vergewissern Sie sich, dass die EKS-Pod-Identity-Pods auf Ihrem Cluster ausgeführt werden.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Eine Beispielausgabe sieht wie folgt aus.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Sie können jetzt EKS-Pod-Identity-Zuordnungen in Ihrem Cluster verwenden. Weitere Informationen finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).
# Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto
In diesem Thema wird beschrieben, wie Sie ein Kubernetes-Dienstkonto so konfigurieren, dass es eine AWS Identity and Access Management (IAM) -Rolle mit EKS Pod Identity annimmt. Alle Pods, die für die Verwendung des Dienstkontos konfiguriert sind, können dann auf jeden AWS Dienst zugreifen, für den die Rolle über Zugriffsberechtigungen verfügt.
Um eine EKS Pod Identity-Zuordnung zu erstellen, gibt es nur einen einzigen Schritt: Sie erstellen die Zuordnung in EKS über die AWS CLI AWS-Managementkonsole AWS SDKs, AWS CloudFormation und andere Tools. Es gibt keine Daten oder Metadaten zu den Zuordnungen innerhalb des Clusters in Kubernetes-Objekten, und Sie fügen den Servicekonten keine Annotationen hinzu
**Voraussetzungen**
+ Einen vorhandenen -Cluster. Falls Sie noch kein Service-Konto haben, können Sie eines erstellen, indem Sie einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) folgen.
+ Der IAM-Prinzipal, der die Zuordnung erstellt, muss `iam:PassRole` haben.
+ Die neueste Version der AWS CLI, die auf Ihrem Gerät installiert und konfiguriert ist, oder AWS CloudShell. Sie können Ihre aktuelle Version mit `aws --version | cut -d / -f2 | cut -d ' ' -f1` überprüfen. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle. Die in der installierte AWS CLI-Version AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im AWS CloudShell Benutzerhandbuch unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
## Erstellen Sie eine Pod Identity-Zuordnung (AWS Konsole)
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-on „EKS Pod Identity Agent“ konfigurieren möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie in den **Pod-Identity-Zuordnungen** die Option **Erstellen** aus.
1. Wählen Sie als **IAM-Rolle** die IAM-Rolle mit den Berechtigungen aus, die die Workload haben soll.
**Anmerkung**
Die Liste enthält nur Rollen mit der folgenden Vertrauensrichtlinie, die EKS Pod Identity ermöglicht, diese Rollen zu verwenden.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole` – EKS Pod Identity nutzt `AssumeRole`, um die IAM-Rolle anzunehmen, bevor es die temporären Anmeldeinformationen an Ihre Pods übergibt.
`sts:TagSession`— EKS Pod Identity verwendet`TagSession`, um *Sitzungs-Tags* in die Anfragen an AWS STS aufzunehmen.
Sie können diese Tags in den *Bedingungsschlüsseln* der Vertrauensrichtlinie verwenden, um einzuschränken, welche Servicekonten, Namespaces und Cluster diese Rolle verwenden dürfen.
Eine Liste der Amazon EKS-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in der *Service-Autorisierungsreferenz*. Um zu erfahren, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
1. Wählen Sie als **Kubernetes-Namespace** den Kubernetes-Namespace aus, der das Servicekonto und die Workload enthält. Optional können Sie den Namen eines Namespace angeben, der nicht im Cluster vorhanden ist.
1. Wählen Sie für das **Kubernetes-Servicekonto** das zu verwendende Kubernetes-Servicekonto aus. Das Manifest für Ihre Kubernetes-Workload muss dieses Servicekonto angeben. Optional können Sie den Namen eines Servicekontos angeben, das nicht im Cluster vorhanden ist.
1. (Optional) Wählen Sie **Sitzungs-Tags deaktivieren** aus, um die Standard-Sitzungs-Tags zu deaktivieren, die Pod Identity automatisch hinzufügt, wenn es die Rolle übernimmt.
1. (Optional) Schalten **Sie „Sitzungsrichtlinie konfigurieren**“ um, um eine IAM-Richtlinie so zu konfigurieren, dass zusätzliche Einschränkungen auf diese Pod-Identity-Zuordnung angewendet werden, die über die in der IAM-Rolle verknüpften IAM-Richtlinie definierten Berechtigungen hinausgehen.
**Anmerkung**
Eine Sitzungsrichtlinie kann nur angewendet werden, wenn die Einstellung **Sitzungs-Tags deaktivieren aktiviert** ist.
1. (Optional) Wählen Sie für die **Tags** die Option **Tag hinzufügen** aus, um Metadaten in einem Schlüssel-Wert-Paar hinzuzufügen. Diese Tags werden auf die Zuordnung angewendet und können in IAM-Richtlinien verwendet werden.
Sie können diesen Schritt wiederholen, um mehrere Regionen hinzuzufügen.
1. Wählen Sie **Erstellen** aus.
## Erstellen Sie eine Pod Identity-Zuordnung (AWS CLI)
1. Wenn Sie Ihrer IAM-Rolle eine vorhandene IAM-Richtlinie zuordnen möchten, fahren Sie mit dem nächsten Schritt fort.
Erstellen Sie eine IAM-Richtlinie. Sie können Ihre eigene Richtlinie erstellen oder eine AWS verwaltete Richtlinie kopieren, die bereits einige der benötigten Berechtigungen gewährt, und sie an Ihre spezifischen Anforderungen anpassen. Weitere Informationen finden Sie unter [Erstellen von IAM-Richtlinien](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) im *IAM-Benutzerhandbuch*.
1. Erstellen Sie eine Datei, die die Berechtigungen für die AWS Dienste enthält, auf die Ihre Pods zugreifen sollen. Eine Liste aller Aktionen für alle AWS Dienste finden Sie in der [Referenz zur Dienstautorisierung](https://docs.aws.amazon.com/service-authorization/latest/reference/).
Sie können den folgenden Befehl ausführen, um eine Beispiel-Richtliniendatei zu erstellen, die schreibgeschützten Zugriff auf einen Amazon-S3-Bucket gewährt. Sie können optional Konfigurationsinformationen oder ein Bootstrap-Skript in diesem Bucket speichern und die Container in Ihrem Pod können die Datei aus dem Bucket lesen und in Ihre Anwendung laden. Wenn Sie diese Beispielrichtlinie erstellen möchten, kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-pod-secrets-bucket*Ersetzen Sie es durch Ihren Bucket-Namen und führen Sie den Befehl aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Erstellen Sie die IAM-Richtlinie.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
1. Erstellen Sie eine IAM-Rolle und ordnen Sie diese einem Kubernetes- Servicekonto zu.
1. Wenn Sie ein vorhandenes Kubernetes-Servicekonto haben, das eine IAM-Rolle annehmen soll, können Sie diesen Schritt überspringen.
Erstellen Sie ein Kubernetes-Servicekonto. Kopieren Sie den folgenden Inhalt auf Ihr Gerät. *my-service-account*Ersetzen Sie ihn durch Ihren gewünschten Namen und gegebenenfalls *default* durch einen anderen Namespace. Wenn Sie eine Änderung vornehmen*default*, muss der Namespace bereits existieren.
```
cat >my-service-account.yaml <
1. Stellen Sie sicher, dass die Vertrauensrichtlinie der IAM-Rolle korrekt konfiguriert ist.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Stellen Sie sicher, dass die Richtlinie, die Sie in einem vorherigen Schritt an Ihre Rolle angehängt haben, an die Rolle angehängt ist.
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
Eine Beispielausgabe sieht wie folgt aus.
```
arn:aws: iam::111122223333:policy/my-policy
```
1. Legen Sie eine Variable fest, um den Amazon-Ressourcennamen (ARN) der Richtlinie zu speichern, die Sie verwenden möchten. *my-policy*Ersetzen Sie es durch den Namen der Richtlinie, für die Sie die Berechtigungen bestätigen möchten.
```
export policy_arn=arn:aws: iam::111122223333:policy/my-policy
```
1. Zeigen Sie die Standardversion der Richtlinie an.
```
aws iam get-policy --policy-arn $policy_arn
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws: iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Überprüfen Sie den Inhalt der Richtlinie, um sicherzustellen, dass sie alle Berechtigungen enthält, die Ihr Pod benötigt. Falls erforderlich, ersetzen Sie *1* den folgenden Befehl durch die Version, die in der vorherigen Ausgabe zurückgegeben wurde.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Eine Beispielausgabe sieht wie folgt aus.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Wenn Sie die Beispielrichtlinie in einem vorherigen Schritt erstellt haben, ist Ihre Ausgabe dieselbe. Wenn Sie eine andere Richtlinie erstellt haben, ist der *example* Inhalt anders.
## Nächste Schritte
[Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren](pod-id-configure-pods.md)
# Zugreifen auf AWS Ressourcen mithilfe von EKS Pod Identity Target IAM-Rollen
Wenn Sie Anwendungen auf Amazon Elastic Kubernetes Service (Amazon EKS) ausführen, müssen Sie möglicherweise auf AWS Ressourcen zugreifen, die in verschiedenen AWS Konten vorhanden sind. In dieser Anleitung erfahren Sie, wie Sie den kontoübergreifenden Zugriff mithilfe von EKS Pod Identity einrichten, sodass Ihre Kubernetes-Pods mithilfe von Zielrollen auf andere AWS Ressourcen zugreifen können.
## Voraussetzungen
Stellen Sie vor dem Beginn sicher, dass Sie die folgenden Schritte abgeschlossen haben:
+ [Einrichtung des Amazon-EKS-Pod-Identity-Agenten](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [Erstellung der EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## So funktioniert’s
Mit Pod Identity können Anwendungen in Ihrem EKS-Cluster über einen Prozess, der als Rollenverkettung bezeichnet wird, kontenübergreifend auf AWS Ressourcen zugreifen.
Wenn Sie eine Pod Identity-Zuordnung erstellen, können Sie zwei IAM-Rollen angeben: eine [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in demselben Konto wie Ihr EKS-Cluster und eine Ziel-IAM-Rolle aus dem Konto, das Ihre AWS Ressourcen enthält, auf die Sie zugreifen möchten (wie S3-Buckets oder RDS-Datenbanken). Die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) muss sich aufgrund der [ PassRoleIAM-Anforderungen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html) im Konto Ihres EKS-Clusters befinden, während sich die Target-IAM-Rolle in jedem Konto befinden kann. AWS PassRole ermöglicht es einer AWS Entität, die Rollenübernahme an einen anderen Dienst zu delegieren. EKS Pod Identity verwendet PassRole , um eine Rolle mit einem Kubernetes-Dienstkonto zu verbinden. Dabei müssen sich sowohl die Rolle als auch die Identität, die sie übergibt, in demselben AWS Konto wie der EKS-Cluster befinden. Wenn Ihr Anwendungs-Pod auf AWS Ressourcen zugreifen muss, fordert er Anmeldeinformationen von Pod Identity an. Pod Identity führt dann automatisch zwei Rollenübernahmen nacheinander durch: Zunächst übernimmt es die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) und verwendet dann diese Anmeldeinformationen, um die Ziel-IAM-Rolle zu übernehmen. Durch diesen Vorgang erhält Ihr Pod temporäre Anmeldeinformationen, für die die in der Zielrolle definierten Berechtigungen gelten, sodass Sie sicher auf Ressourcen in anderen AWS Konten zugreifen können.
## Überlegungen zum Caching
Aufgrund von Caching-Mechanismen werden Aktualisierungen einer IAM-Rolle in einer vorhandenen Pod-Identity-Zuordnung möglicherweise nicht sofort in den Pods wirksam, die auf Ihrem EKS-Cluster ausgeführt werden. Der Pod-Identity-Agent speichert IAM-Anmeldedaten basierend auf der Konfiguration der Zuordnung zum Zeitpunkt des Abrufs der Anmeldedaten zwischen. Wenn die Zuordnung nur eine [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) und keine Ziel-IAM-Rolle enthält, bleiben die im Cache gespeicherten Anmeldedaten 6 Stunden lang gültig. Wenn die Zuordnung sowohl die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ARN als auch eine Ziel-IAM-Rolle enthält, bleiben die im Cache gespeicherten Anmeldeinformationen 59 Minuten lang gültig. Durch das Ändern einer vorhandenen Zuordnung, z. B. durch Aktualisieren der ARN der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) oder Hinzufügen einer Ziel-IAM-Rolle, wird der vorhandene Cache nicht zurückgesetzt. Daher erkennt der Agent Aktualisierungen erst, wenn die zwischengespeicherten Anmeldedaten aktualisiert werden. Um Änderungen schneller anzuwenden, können Sie die vorhandenen Pods neu erstellen. Andernfalls müssen Sie warten, bis der Cache abgelaufen ist.
## Schritt 1: Erstellen und Zuordnen einer Ziel-IAM-Rolle
In diesem Schritt erstellen Sie eine sichere Vertrauenskette, indem Sie eine Ziel-IAM-Rolle erstellen und konfigurieren. Zur Veranschaulichung erstellen wir eine neue Target-IAM-Rolle, um eine Vertrauenskette zwischen zwei AWS Konten einzurichten: Die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (z. B.`eks-pod-identity-primary-role`) im AWS Konto des EKS-Clusters erhält die Erlaubnis, die Target-IAM-Rolle (z. B.`eks-pod-identity-aws-resources`) in Ihrem Zielkonto zu übernehmen, wodurch der Zugriff auf AWS Ressourcen wie Amazon S3 S3-Buckets ermöglicht wird.
### Ziel-IAM-Rolle erstellen
1. Öffnen Sie die [Amazon IAM-Konsole](https://console.aws.amazon.com/iam/home).
1. Vergewissern Sie sich in der oberen Navigationsleiste, dass Sie bei dem Konto angemeldet sind, das die AWS Ressourcen (wie S3-Buckets oder DynamoDB-Tabellen) für Ihre Target IAM-Rolle enthält.
1. Wählen Sie im linken Navigationsbereich **Roles** aus.
1. Wählen Sie die Schaltfläche „**Rolle erstellen**“ und anschließend „** AWS Konto**“ unter „Vertrauenswürdiger Entitätstyp“.
1. Wählen Sie **Anderes AWS Konto**, geben Sie Ihre AWS Kontonummer ein (das Konto, für das Ihre [EKS Pod Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) existiert) und wählen Sie dann **Weiter**.
1. **Fügen Sie die Berechtigungsrichtlinien hinzu, die Sie der Rolle zuordnen möchten (z. B. AmazonS3FullAccess), und wählen Sie dann Weiter.**
1. Geben Sie einen Rollennamen ein, z. B. `MyCustomIAMTargetRole`, und wählen Sie dann **Rolle erstellen** aus.
### Aktualisierung der Vertrauensrichtlinie für die Ziel-IAM-Rolle
1. Nach der Erstellung der Rolle werden Sie zur Liste **Rollen** zurückgeleitet. Suchen und wählen Sie die neue Rolle aus, die Sie im vorherigen Schritt erstellt haben (z. B. `MyCustomIAMTargetRole`).
1. Wählen Sie den Tab **Vertraunsbeziehungen**.
1. Klicken Sie auf der rechten Seite auf **Vertrauensrichtlinie bearbeiten**.
1. Ersetzen Sie im Richtlinien-Editor die Standard-JSON-Datei durch Ihre Vertrauensrichtlinie. Ersetzen Sie die Platzhalterwerte für den Rollennamen und `111122223333` im ARN der IAM-Rolle durch die AWS Konto-ID, die Ihren EKS-Cluster hostet. Sie können PrincipalTags in der Rollenvertrauensrichtlinie optional auch festlegen, dass nur bestimmte Dienstkonten aus einem bestimmten Cluster und Namespace Ihre Zielrolle übernehmen. Beispiel:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
Mit der obigen Richtlinienrichtlinie kann die Rolle `eks-pod-identeity-primary-role` aus dem AWS Konto 111122223333 mit den entsprechenden [EKS Pod Identity-Sitzungstags](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) diese Rolle übernehmen.
Wenn Sie [Sitzungs-Tags in Ihrer EKS-Pod-Identität deaktiviert](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) haben, legt die EKS Pod Identity beim Übernehmen einer Ziel-Rolle auch die `sts:ExternalId` mit Informationen zum Cluster, Namespace und Servicekonto eines Pods fest.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
Die oben genannte Richtlinie trägt dazu bei, dass nur der erwartete Cluster, Namespace und das Servicekonto die Zielrolle übernehmen können.
### Aktualisierung der Berechtigungsrichtlinie für die EKS-Pod-Identity-Rolle
In diesem Schritt aktualisieren Sie die Berechtigungsrichtlinie der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html), die Ihrem Amazon-EKS-Cluster zugeordnet ist, indem Sie die Ziel-IAM-Rolle ARN als Ressource hinzufügen.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** und anschließend den Namen des EKS-Clusters, den Sie ändern möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie unter **Pod Identity-Zuordnungen** Ihre [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) aus.
1. Wählen Sie **Berechtigungen**, **Berechtigungen hinzufügen** und anschließend **Inline-Richtlinie erstellen** aus.
1. Wählen Sie auf der rechten Seite **JSON** aus.
1. Ersetzen Sie im Richtlinien-Editor die Standard-JSON-Datei durch Ihre Berechtigungsrichtlinie. Ersetzen Sie den Platzhalterwert für den Rollennamen und `222233334444` in der IAM-Rolle ARN durch Ihre Ziel-IAM-Rolle. Beispiel:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## Schritt 2: Zuordnung der Ziel-IAM-Rolle zu einem Kubernetes-Servicekonto
In diesem Schritt erstellen Sie eine Zuordnung zwischen der Ziel-IAM-Rolle und dem Kubernetes-Servicekonto in Ihrem EKS-Cluster.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Cluster** und anschließend den Namen des Clusters aus, zu dem Sie die Zuordnung hinzufügen möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie in den **Pod-Identity-Zuordnungen** die Option **Erstellen** aus.
1. Wählen Sie die [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) in der **IAM-Rolle** für Ihre Workloads aus.
1. Wählen Sie die Ziel-IAM-Rolle in der **Ziel-IAM-Rolle** aus, die von der [EKS-Pod-Identity-Rolle](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) übernommen werden soll.
1. Geben Sie im Feld **Kubernetes-Namespace** den Namen des Namespace ein, in dem Sie die Zuordnung erstellen möchten (z. B. `my-app-namespace`). Dies definiert, wo sich das Servicekonto befindet.
1. Geben Sie im Feld **Kubernetes-Servicekonto** den Namen des Servicekontos ein (z. B. `my-service-account`), das die IAM-Anmeldeinformationen verwenden soll. Dadurch wird die IAM-Rolle dem Servicekonto zugeordnet.
1. (Optional) Wählen Sie **Sitzungs-Tags deaktivieren** aus, um die Standardsitzungs-Tags zu deaktivieren, die Pod Identity automatisch hinzufügt, wenn es die Rolle übernimmt.
1. (Optional) Schalten **Sie „Sitzungsrichtlinie konfigurieren**“ um, um eine IAM-Richtlinie so zu konfigurieren, dass zusätzliche Einschränkungen auf diese Pod-Identity-Zuordnung angewendet werden, die über die Berechtigungen hinausgehen, die in der IAM-Richtlinie für die **Ziel-IAM-Rolle** definiert sind.
**Anmerkung**
1. Eine Sitzungsrichtlinie kann nur angewendet werden, wenn die Einstellung **Sitzungs-Tags deaktivieren aktiviert** ist. 2. Wenn Sie eine Sitzungsrichtlinie angeben, gelten die Richtlinieneinschränkungen für die Berechtigungen der **Target-IAM-Rolle** und nicht für die **IAM-Rolle**, die dieser Pod-Identity-Zuordnung zugeordnet ist.
1. Wählen Sie **Erstellen** aus, um die Zuordnung zu erstellen.
# Pods für den Zugriff auf AWS Dienste mit Dienstkonten konfigurieren
Wenn ein Pod auf AWS Dienste zugreifen muss, müssen Sie ihn für die Verwendung eines Kubernetes-Dienstkontos konfigurieren. Das Dienstkonto muss einer AWS Identity and Access Management (IAM) -Rolle zugeordnet sein, die über Berechtigungen für den Zugriff auf die AWS Dienste verfügt.
+ Einen vorhandenen -Cluster. Wenn Sie keine Rolle haben, können Sie sie mithilfe einer der Anleitungen in [Erste Schritte mit Amazon EKS](getting-started.md) erstellen.
+ Ein vorhandenes Kubernetes-Servicekonto und eine EKS-Pod-Identity-Zuordnung, die das Servicekonto einer IAM-Rolle zuordnet. Der Rolle muss eine IAM-Richtlinie zugeordnet sein, die die Berechtigungen enthält, die Ihre Pods für die Nutzung AWS von Diensten haben sollen. Weitere Informationen zu Rollen, ihren Vorteilen sowie zu ihrer Erstellung und Konfiguration finden Sie unter [Zuordnung einer IAM-Rolle einem Kubernetes-Servicekonto](pod-id-association.md).
+ Die neueste Version der AWS CLI, die auf Ihrem Gerät installiert und konfiguriert ist, oder AWS CloudShell. Sie können Ihre aktuelle Version mit `aws --version | cut -d / -f2 | cut -d ' ' -f1` überprüfen. Paketmanager wie `yum``apt-get`, oder Homebrew für macOS liegen oft mehrere Versionen hinter der neuesten Version der AWS CLI. Informationen zur Installation der neuesten Version finden Sie unter [Installation](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) und [Schnellkonfiguration mit aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) im Benutzerhandbuch für die AWS Befehlszeilenschnittstelle. Die in der installierte AWS CLI-Version AWS CloudShell kann auch mehrere Versionen hinter der neuesten Version liegen. Informationen zur Aktualisierung finden Sie im AWS CloudShell Benutzerhandbuch unter [AWS CLI in Ihrem Home-Verzeichnis installieren](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software).
+ Das `kubectl`-Befehlszeilen-Tool ist auf Ihrem Gerät oder in der AWS CloudShell installiert. Die Version kann mit der Kubernetes-Version Ihres Clusters identisch sein oder bis zu einer Nebenversion älter oder neuer sein. Wenn Ihre Clusterversion beispielsweise `1.29` ist, können Sie `kubectl`-Version `1.28`, `1.29`, oder `1.30` damit verwenden. Informationen zum Installieren oder Aktualisieren von `kubectl` finden Sie unter [`kubectl` und `eksctl` einrichten](install-kubectl.md).
+ Eine vorhandene `kubectl` `config`-Datei, die Ihre Clusterkonfiguration enthält. Informationen zum Erstellen einer `kubectl` `config`-Datei finden Sie unter [kubectl mit einem EKS-Cluster durch Erstellen einer kubeconfig-Datei verbinden](create-kubeconfig.md).
1. Verwenden Sie den folgenden Befehl, um ein Bereitstellungs-Manifest zu erstellen, mit dem Sie einen Pod bereitstellen können, um die Konfiguration zu bestätigen. Ersetzen Sie die Beispielwerte durch eigene Werte.
```
cat >my-deployment.yaml <
Die attributbasierte Zugriffskontrolle (ABAC) gewährt Benutzern Rechte anhand von Richtlinien, die Attribute miteinander kombinieren. EKS Pod Identity fügt den temporären Anmeldeinformationen für jeden Pod Tags mit Attributen wie Cluster-Name, Namespace und Servicekonto-Name hinzu. Diese Rollensitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die für alle Dienstkonten verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht. Durch den zusätzlichen Support für Rollensitzungs-Tags können Kunden engere Sicherheitsgrenzen zwischen Clustern und Workloads innerhalb von Clustern durchsetzen und gleichzeitig dieselben IAM-Rollen und IAM-Richtlinien wiederverwenden.
## Beispiel-Richtlinie mit Tags
Nachfolgend finden Sie ein Beispiel für eine IAM-Richtlinie, die `s3:GetObject`-Berechtigungen gewährt, wenn das entsprechende Objekt mit dem EKS-Clusternamen gekennzeichnet ist.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## Aktivieren oder Deaktivieren von Sitzungs-Tags
EKS Pod Identity fügt einen vordefinierten Satz von Sitzungs-Tags hinzu, wenn es die Rolle übernimmt. Diese Sitzungs-Tags ermöglichen es Administratoren, eine einzelne Rolle zu erstellen, die ressourcenübergreifend verwendet werden kann, indem sie den Zugriff auf AWS Ressourcen auf der Grundlage übereinstimmender Tags ermöglicht.
### Aktivieren von Sitzungs-Tags
Sitzungstags werden automatisch mit EKS Pod Identity aktiviert – Ihrerseits sind keine Maßnahmen erforderlich. Standardmäßig fügt EKS Pod Identity Ihrer Sitzung eine Reihe vordefinierter Tags hinzu. Um in Richtlinien auf diese Tags zu verweisen, verwenden Sie die Syntax `${aws:PrincipalTag/` gefolgt vom Tag-Schlüssel. Beispiel, `${aws:PrincipalTag/kubernetes-namespace}`.
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### Deaktivieren von Sitzungs-Tags
AWS komprimiert Inline-Sitzungsrichtlinien, verwaltete Richtlinien ARNs und Sitzungs-Tags in ein gepacktes Binärformat mit separatem Limit. Wenn Sie einen `PackedPolicyTooLarge`-Fehler erhalten, die darauf hinweist, dass das gepackte Binärformat die Größenbeschränkung überschritten hat, können Sie diese Größe reduzieren, indem Sie die von EKS Pod Identity hinzugefügten Sitzungs-Tags deaktivieren. Um diese Sitzungs-Tags zu deaktivieren, führen Sie die folgenden Schritte aus:
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Clusters** und anschließend den Namen des Clusters, den Sie ändern möchten.
1. Wählen Sie die Registerkarte **Zugriff** aus.
1. Wählen Sie unter **Pod-Identity-Zuordnungen** die **Zuordnungs-ID**, die Sie ändern möchten, und klicken Sie dann auf **Bearbeiten**.
1. Wählen Sie unter **Sitzungs-Tags** die Option **Sitzungs-Tags deaktivieren**.
1. Wählen Sie **Änderungen speichern ** aus.
## Kontoübergreifende Tags
Alle Sitzungs-Tags, die von EKS Pod Identity hinzugefügt werden, sind *transitiv*. Die Tag-Schlüssel und -Werte werden an alle `AssumeRole`-Aktionen weitergegeben, die Ihre Workloads verwenden, um Rollen auf ein anderes Konto zu wechseln. Sie können diese Tags in Richtlinien in anderen Konten verwenden, um den Zugriff in kontoübergreifenden Szenarien einzuschränken. Weitere Informationen finden Sie im *IAM-Benutzerhandbuch* unter [Verketten von Rollen mit Sitzungs-Tags](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining).
## Benutzerdefinierte Tags
EKS Pod Identity kann der `AssumeRole`-Aktion, die es ausführt, keine zusätzlichen benutzerdefinierten Tags hinzufügen. Tags, die Sie auf die IAM-Rolle anwenden, sind jedoch immer im gleichen Format verfügbar: `${aws:PrincipalTag/` gefolgt vom Schlüssel, zum Beispiel `${aws:PrincipalTag/MyCustomTag}`.
**Anmerkung**
Tags, die der Sitzung über die `sts:AssumeRole`-Anfrage hinzugefügt wurden, haben im Konfliktfall Vorrang. Nehmen wir zum Beispiel an:
Amazon EKS fügt der Sitzung einen Schlüssel `eks-cluster-name` und einen Wert `my-cluster` hinzu, wenn EKS die Kundenrolle übernimmt und
Sie fügen der IAM-Rolle ein `eks-cluster-name`-Tag mit dem Wert `my-own-cluster` hinzu.
In diesem Fall hat Ersteres Vorrang und der Wert für das `eks-cluster-name`-Tag ist `my-cluster`.
# Verwendung der Pod Identity mit dem AWS-SDK
## Verwenden von EKS-Pod-Identity-Anmeldeinformationen
Um die Anmeldeinformationen von einer EKS-Pod-Identity-Zuordnung zu nutzen, kann Ihr Code ein beliebiges AWS-SDK verwenden, um einen Client für einen AWS-Service mit einem SDK zu erstellen. Standardmäßig sucht das SDK in einer Kette von Speicherorten nach zu verwendenden Anmeldeinformationen für die AWS-Identitäts- und Zugriffsverwaltung. Die Anmeldeinformationen für EKS Pod Identity werden verwendet, wenn Sie bei der Erstellung des Clients keinen Anmeldeinformationsanbieter angeben oder Sie das SDK anderweitig initialisiert haben.
Das funktioniert, weil EKS-Pod-Identitäten dem *Anbieter für Container-Anmeldeinformationen* hinzugefügt wurden, der in einem Schritt in der standardmäßigen Anmeldeinformationskette durchsucht wird. Wenn Ihre Workloads derzeit Anmeldeinformationen verwenden, die in der Kette der Anmeldeinformationen weiter vorn stehen, werden diese Anmeldeinformationen auch dann weiter verwendet, wenn Sie eine EKS-Pod-Identity-Zuordnung für dieselbe Workload konfigurieren.
Weitere Informationen zur Funktionsweise von EKS-Pod-Identitäten finden Sie unter [Funktionsweise von EKS Pod Identity verstehen](pod-id-how-it-works.md).
Bei der Verwendung von [Erfahren Sie, wie EKS Pod Identity Pods Zugriff auf AWS-Services gewährt](pod-identities.md) müssen die Container in Ihren Pods eine AWS-SDK-Version verwenden, welche die Übernahme einer IAM-Rolle vom EKS-Pod-Identity-Agent unterstützt. Stellen Sie sicher, dass Sie die folgenden Versionen oder höher für Ihr AWS-SDK verwenden:
+ Java (Version 2) – [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java – [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ Go v1 – [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2 – [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python (Boto3) – [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore) – [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS-CLI – [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS-CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2 – [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3 – [v3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ Kotlin – [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby – [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Rust – [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1 – [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET – [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell – [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP – [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
Um sicherzustellen, dass Sie ein unterstütztes SDK verwenden, befolgen Sie die Installationsanweisungen für Ihr bevorzugtes SDK unter [Tools für die Entwickelung in AWS](https://aws.amazon.com/tools/), wenn Sie Ihre Container entwickeln.
Eine Liste der Add-Ons, die EKS Pod Identity unterstützen, finden Sie unter [Unterstützungsreferenz für Pod Identity](retreive-iam-info.md#pod-id-add-on-versions).
# Deaktivierung von `IPv6` im EKS-Pod-Identity-Agent
## AWS-Managementkonsole
1. Um `IPv6` im EKS-Pod-Identity-Agent zu deaktivieren, fügen Sie die folgende Konfiguration zu den **Optionalen Konfigurationseinstellungen** des EKS- Add-Ons hinzu.
1. Öffnen Sie die [Amazon-EKS-Konsole](https://console.aws.amazon.com/eks/home#/clusters).
1. Wählen Sie im linken Navigationsbereich **Clusters** (Cluster) aus. Wählen Sie anschließend den Namen des Clusters aus, für den Sie das Add-On konfigurieren möchten.
1. Wählen Sie die Registerkarte **Add-ons**.
1. Aktivieren Sie das Kontrollkästchen oben rechts im Feld „EKS-Pod-Identity-Agent-Add-on“ und wählen Sie anschließend **Bearbeiten**.
1. Auf der Seite **EKS-Pod-Identity-Agent konfigurieren**:
1. Wählen Sie die **Version** aus, die Sie verwenden möchten. Wir empfehlen Ihnen, die gleiche Version wie im vorherigen Schritt beizubehalten und die Version und Konfiguration in separaten Schritten zu aktualisieren.
1. Erweitern Sie **Optionale Konfigurationseinstellungen**.
1. Geben Sie den JSON-Schlüssel `"agent":` und den Wert eines verschachtelten JSON-Objekts mit einem Schlüssel `"additionalArgs":` in den **Konfigurationswerten** ein. Der resultierende Text muss ein gültiges JSON-Objekt sein. Wenn dieser Schlüssel und dieser Wert die einzigen Daten im Textfeld sind, setzen Sie den Schlüssel und den Wert in geschweifte Klammern `{ }`. Das folgende Beispiel veranschaulicht, dass die Netzwerkrichtlinie aktiviert ist:
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
Diese Konfiguration legt die `IPv4`-Adresse als einzige Adresse fest, die vom Agenten verwendet wird.
1. Um die neue Konfiguration durch Ersetzen des Agent-Pods von EKS Pod Identity anzuwenden, wählen Sie **Änderungen speichern**.
Amazon EKS wendet Änderungen an den EKS-Add-Ons an, indem es einen *Einführung* von Kubernetes `DaemonSet` für EKS Pod Identity Agent durchführt. Sie können den Status der Einführung im **Aktualisierungsverlauf** des Add-Ons in AWS-Managementkonsole und mit `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` verfolgen.
`kubectl rollout` verfügt über die folgenden Befehle:
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Wenn die Einführung zu lange dauert, macht Amazon EKS die Einführung rückgängig und eine Nachricht mit dem Typ der **Add-On-Aktualisierung** und dem Status **Fehlgeschlagen** dem **Aktualisierungsverlauf** des Add-Ons hinzugefügt. Um etwaige Probleme zu untersuchen, beginnen Sie mit dem Verlauf der Einführung und führen Sie `kubectl logs` auf einem Agent-Pod von EKS Pod Identity aus, um die Protokolle des EKS-Pod-Identity-Agent anzuzeigen.
1. Wenn der neue Eintrag im **Aktualisierungsverlauf** den Status **Erfolgreich** aufweist, ist die Einführung abgeschlossen und das Add-On verwendet die neue Konfiguration in allen Pods von EKS Pod Identity Agent.
## AWS-CLI
1. Um `IPv6` im EKS-Pod-Identity-Agent zu deaktivieren, fügen Sie die folgende Konfiguration zu den **Konfigurationswerten** des EKS-Add-Ons hinzu.
Führen Sie den folgenden AWS-CLI-Befehl aus. Ersetzen Sie `my-cluster` durch den Namen Ihres Clusters und den IAM-Rollen-ARN durch die Rolle, die Sie verwenden.
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
Diese Konfiguration legt die `IPv4`-Adresse als einzige Adresse fest, die vom Agenten verwendet wird.
Amazon EKS wendet Änderungen an den EKS-Add-Ons an, indem es eine *Einführung* von Kubernetes DaemonSet für EKS-Pod-Identity-Agent durchführt. Sie können den Status der Einführung im **Aktualisierungsverlauf** des Add-Ons in AWS-Managementkonsole und mit `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system` verfolgen.
`kubectl rollout` verfügt über die folgenden Befehle:
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Wenn die Einführung zu lange dauert, macht Amazon EKS die Einführung rückgängig und eine Nachricht mit dem Typ der **Add-On-Aktualisierung** und dem Status **Fehlgeschlagen** dem **Aktualisierungsverlauf** des Add-Ons hinzugefügt. Um etwaige Probleme zu untersuchen, beginnen Sie mit dem Verlauf der Einführung und führen Sie `kubectl logs` auf einem Agent-Pod von EKS Pod Identity aus, um die Protokolle des EKS-Pod-Identity-Agent anzuzeigen.
# Erstellen einer IAM-Rolle mit der von EKS Pod Identity geforderten Vertrauensrichtlinie
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
EKS Pod Identity nutzt `AssumeRole`, um die IAM-Rolle anzunehmen, bevor es die temporären Anmeldeinformationen an Ihre Pods übergibt.
** `sts:TagSession` **
EKS Pod Identity verwendet`TagSession`, um *Sitzungs-Tags* in die Anfragen an STS aufzunehmen. AWS
**Einstellungsbedingungen**
Sie können diese Tags in den *Bedingungsschlüsseln* der Vertrauensrichtlinie verwenden, um einzuschränken, welche Servicekonten, Namespaces und Cluster diese Rolle verwenden dürfen. Die Liste der von Pod Identity hinzugefügten Anforderungs-Tags finden Sie unter [Aktivieren oder Deaktivieren von Sitzungs-Tags](pod-id-abac.md#pod-id-abac-tags).
Sie können beispielsweise mit der folgenden Vertrauensrichtlinie mit dem hinzugefügten `Condition` einschränken, welche Pods die Rolle einer Pod-Identity-IAM-Rolle auf ein bestimmtes `ServiceAccount` und `Namespace` übernehmen können:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
Eine Liste der Amazon EKS-Bedingungsschlüssel finden Sie unter [Bedingungsschlüssel für Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) in der *Service-Autorisierungsreferenz*. Um zu erfahren, mit welchen Aktionen und Ressourcen Sie einen Bedingungsschlüssel verwenden können, lesen Sie von [Amazon Elastic Kubernetes Service definierte Aktionen](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).