**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.
# Zugangseinträ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 im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer für den Zugriff AWS mithilfe temporärer Anmeldeinformationen einen Verbund mit einem Identitätsanbieter](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) verwenden müssen.
+ 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 etwas anderes ist als `STANDARD` (siehe nächste Überlegung zu Typen), muss sich der ARN in demselben AWS Konto befinden, in dem sich Ihr Cluster befindet. Wenn der Typ ist`STANDARD`, kann sich der ARN in demselben oder einem anderen Konto befinden als das AWS Konto, in dem sich Ihr Cluster befindet.
+ 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 der ARN für den neu erstellten IAM-Prinzipal derselbe ist, der `roleID` oder `userID` (Sie können dies mit dem `aws sts get-caller-identity` AWS CLI-Befehl 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 IAM-Rolle, die mit AWS Fargate (Fargate) verwendet wird
+ `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 eines `{{SessionName}}` oder `{{SessionNameRaw}}` hinzufügen, muss der Benutzername einen Doppelpunkt *vor* {{SessionName}} 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 erscheint in den CloudTrail Protokollen. 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 [Verwendung der RBAC-Autorisierung](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 existiert, akzeptiert Amazon EKS die Konfiguration, ohne einen Fehler zurückzugeben, aber der IAM-Prinzipal hat keine Berechtigungen, bis die entsprechenden Kubernetes-RBAC-Ressourcen erstellt wurden.
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 im [IAM-Benutzerhandbuch unter Erteilen von Benutzerberechtigungen zur Übergabe einer Rolle an einen AWS Dienst](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html).*
+ Ä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 mit der AWS-Managementkonsole oder 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 im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um AWS mithilfe temporärer Anmeldeinformationen darauf zuzugreifen](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp).
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 in der Kubernetes-Dokumentation unter [User-facing Rollen](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles).
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 für die 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. {{my-cluster}}Ersetzen Sie es durch den Namen Ihres Clusters, {{111122223333}} durch Ihre AWS Konto-ID und {{EKS-my-cluster-self-managed-ng-1}} durch den Namen Ihrer [Node-IAM-Rolle](create-node-role.md). Wenn es sich bei Ihrer Knotengruppe um eine Windows-Knotengruppe handelt, {{EC2\_LINUX}} ersetzen `EC2_Windows` Sie sie durch.
```
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. {{my-cluster}}Ersetzen Sie durch den Namen Ihres Clusters, {{111122223333}} durch Ihre AWS Konto-ID und {{my-role}} durch den Namen Ihrer IAM-Rolle. {{Viewers}}Ersetzen Sie es durch den Namen einer Gruppe, die Sie in einem Kubernetes `RoleBinding` oder `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 --username 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 im *IAM-Benutzerhandbuch* unter [Erfordern, dass menschliche Benutzer den Verbund mit einem Identitätsanbieter verwenden müssen, um AWS mithilfe temporärer Anmeldeinformationen darauf zugreifen zu](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) können.
```
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.