Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # IAM-Rollen für Dienstkonten **Tipp** `eksctl`[unterstützt die Konfiguration detaillierter Berechtigungen für EKS-Anwendungen, die über EKS Pod Identity Associations ausgeführt werden](pod-identity-associations.md) Amazon EKS unterstützt [hier](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) Rollen für Service Accounts (IRSA)], wodurch Cluster-Betreiber AWS IAM-Rollen Kubernetes-Servicekonten zuordnen können. Dies bietet ein detailliertes Berechtigungsmanagement für Apps, die auf EKS ausgeführt werden und andere AWS-Services verwenden. Dies können Apps sein, die S3, andere Datendienste (RDS, MQ, STS, DynamoDB) oder Kubernetes-Komponenten wie den AWS Load Balancer-Controller oder ExternalDNS verwenden. Sie können ganz einfach IAM-Rollen- und Dienstkontopaare mit erstellen. `eksctl` **Anmerkung** Wenn Sie [Instanzrollen](iam-policies.md) verwendet haben und erwägen, stattdessen IRSA zu verwenden, sollten Sie die beiden Rollen nicht mischen. ## Funktionsweise Es funktioniert über den IAM OpenID Connect Provider (OIDC), den EKS verfügbar macht, und IAM-Rollen müssen mit Bezug auf den IAM OIDC-Anbieter (spezifisch für einen bestimmten EKS-Cluster) und einem Verweis auf das Kubernetes-Dienstkonto, an das sie gebunden werden, erstellt werden. Sobald eine IAM-Rolle erstellt wurde, sollte ein Dienstkonto den ARN dieser Rolle als Anmerkung (`eks.amazonaws.com/role-arn`) enthalten. Standardmäßig wird das Dienstkonto so erstellt oder aktualisiert, dass es die Rollenanmerkung enthält. Diese kann mithilfe des Flags `--role-only` deaktiviert werden. In EKS gibt es einen [Zugangscontroller](https://github.com/aws/amazon-eks-pod-identity-webhook/), der AWS-Sitzungsanmeldedaten in Pods bzw. Rollen einfügt, basierend auf der Anmerkung zu dem vom Pod verwendeten Dienstkonto. Die Anmeldeinformationen werden durch `AWS_ROLE_ARN` `AWS_WEB_IDENTITY_TOKEN_FILE` &-Umgebungsvariablen verfügbar gemacht. Wenn eine aktuelle Version des AWS-SDK verwendet wird (Einzelheiten zur genauen Version finden Sie [hier](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions)), verwendet die Anwendung diese Anmeldeinformationen. Im Namen `eksctl` der Ressource steht *iamserviceaccount*, was ein Paar aus IAM-Rolle und Dienstkonto darstellt. ## Verwendung über CLI **Anmerkung** IAM-Rollen für Dienstkonten erfordern Kubernetes Version 1.13 oder höher. Der IAM OIDC Provider ist standardmäßig nicht aktiviert. Sie können ihn mit dem folgenden Befehl aktivieren oder die Konfigurationsdatei verwenden (siehe unten): ``` eksctl utils associate-iam-oidc-provider --cluster= ``` Sobald Sie den IAM-OIDC-Anbieter mit dem Cluster verknüpft haben, führen Sie folgenden Befehl aus, um eine an ein Dienstkonto gebundene IAM-Rolle zu erstellen: ``` eksctl create iamserviceaccount --cluster= --name= --namespace= --attach-policy-arn= ``` **Anmerkung** Sie können `--attach-policy-arn` mehrfach angeben, dass mehr als eine Richtlinie verwendet werden soll. Insbesondere können Sie ein Dienstkonto mit schreibgeschütztem Zugriff auf S3 erstellen, indem Sie Folgendes ausführen: ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` Standardmäßig wird es im `default` Namespace erstellt, aber Sie können jeden anderen Namespace angeben, z. B.: ``` eksctl create iamserviceaccount --cluster= --name=s3-read-only --namespace=s3-app --attach-policy-arn=arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess ``` **Anmerkung** Wenn der Namespace noch nicht existiert, wird er erstellt. Wenn Sie bereits ein Dienstkonto im Cluster erstellt haben (ohne IAM-Rolle), müssen Sie Flag verwenden`--override-existing-serviceaccounts`. Benutzerdefiniertes Tagging kann auch auf die IAM-Rolle angewendet werden, indem Folgendes angegeben wird: `--tags` ``` eksctl create iamserviceaccount --cluster= --name= --tags "Owner=John Doe,Team=Some Team" ``` CloudFormation generiert einen Rollennamen, der eine zufällige Zeichenfolge enthält. Wenn Sie einen vordefinierten Rollennamen bevorzugen, können Sie Folgendes angeben`--role-name`: ``` eksctl create iamserviceaccount --cluster= --name= --role-name "custom-role-name" ``` Wenn das Dienstkonto mit einem anderen Tool wie Helm erstellt und verwaltet wird, verwenden Sie es, `--role-only` um Konflikte zu vermeiden. Das andere Tool ist dann für die Pflege der ARN-Anmerkung der Rolle verantwortlich. Beachten Sie, dass dies keine Auswirkungen auf die `roleOnly` `--role-only` /-Dienstkonten `--override-existing-serviceaccounts` hat. Die Rolle wird immer erstellt. ``` eksctl create iamserviceaccount --cluster= --name= --role-only --role-name= ``` Wenn Sie über eine bestehende Rolle verfügen, die Sie mit einem Dienstkonto verwenden möchten, können Sie anstelle der Richtlinien das `--attach-role-arn` Kennzeichen angeben. Um sicherzustellen, dass die Rolle nur von dem angegebenen Dienstkonto übernommen werden kann, sollten Sie [hier](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) ein Dokument zur Beziehungsrichtlinie einrichten]. ``` eksctl create iamserviceaccount --cluster= --name= --attach-role-arn= ``` Um die Rollen und Berechtigungen eines Dienstkontos zu aktualisieren, können Sie ausführen`eksctl update iamserviceaccount`. **Anmerkung** `eksctl delete iamserviceaccount`löscht Kubernetes, `ServiceAccounts` auch wenn sie nicht von erstellt wurden. `eksctl` ## Verwendung mit Konfigurationsdateien Um die Verwaltung `iamserviceaccounts` mithilfe der Konfigurationsdatei durchzuführen, müssen Sie das gewünschte Konto einrichten `iam.withOIDC: true` und auflisten`iam.serviceAccount`. *Alle Befehle werden unterstützt`--config-file`. Sie können *iamserviceaccounts* genauso verwalten wie Nodegroups.* Der `eksctl create iamserviceaccount` Befehl unterstützt `--include` und `--exclude` markiert (weitere Informationen darüber, wie [diese funktionieren, finden Sie in diesem Abschnitt](general-nodegroups.md#node-include)). Und der `eksctl delete iamserviceaccount` Befehl unterstützt `--only-missing` auch, sodass Sie Löschungen genauso durchführen können wie Nodegroups. **Anmerkung** IAM-Dienstkonten befinden sich innerhalb eines Namespaces, d. h. zwei Dienstkonten mit demselben Namen können in unterschiedlichen Namespaces existieren. Um also ein Dienstkonto als Teil von `--exclude` Flags eindeutig zu definieren`--include`, müssen Sie die Namenszeichenfolge im folgenden Format übergeben. `namespace/name` z. B. ``` eksctl create iamserviceaccount --config-file= --include backend-apps/s3-reader ``` Die Option zum Aktivieren `wellKnownPolicies` ist für die Verwendung von IRSA in bekannten Anwendungsfällen wie `cluster-autoscaler` und `cert-manager` als Abkürzung für Richtlinienlisten enthalten. [Unterstützte bekannte Richtlinien und andere Eigenschaften von `serviceAccounts` sind im Konfigurationsschema dokumentiert.](https://geoffcline.github.io/eksctl-schema-demo/#iam-serviceAccounts) Sie verwenden das folgende Konfigurationsbeispiel mit`eksctl create cluster`: ``` # An example of ClusterConfig with IAMServiceAccounts: --- apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: name: cluster-13 region: us-west-2 iam: withOIDC: true serviceAccounts: - metadata: name: s3-reader # if no namespace is set, "default" will be used; # the namespace will be created if it doesn't exist already namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess" tags: Owner: "John Doe" Team: "Some Team" - metadata: name: cache-access namespace: backend-apps labels: {aws-usage: "application"} attachPolicyARNs: - "arn:aws:iam::aws:policy/AmazonDynamoDBReadOnlyAccess" - "arn:aws:iam::aws:policy/AmazonElastiCacheFullAccess" - metadata: name: cluster-autoscaler namespace: kube-system labels: {aws-usage: "cluster-ops"} wellKnownPolicies: autoScaler: true roleName: eksctl-cluster-autoscaler-role roleOnly: true - metadata: name: some-app namespace: default attachRoleARN: arn:aws:iam::123:role/already-created-role-for-app nodeGroups: - name: "ng-1" tags: # EC2 tags required for cluster-autoscaler auto-discovery k8s.io/cluster-autoscaler/enabled: "true" k8s.io/cluster-autoscaler/cluster-13: "owned" desiredCapacity: 1 ``` Wenn Sie einen Cluster erstellen, ohne dass diese Felder gesetzt sind, können Sie die folgenden Befehle verwenden, um alles zu aktivieren, was Sie benötigen: ``` eksctl utils associate-iam-oidc-provider --config-file= eksctl create iamserviceaccount --config-file= ``` ## Weitere Informationen + [Einführung detaillierter IAM-Rollen für Dienstkonten](https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/) + [EKS-Benutzerhandbuch — IAM-Rollen für Dienstkonten](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html#access-policy-permissions) + [Zuordnung von IAM-Benutzern und Rollen zu Kubernetes-RBAC-Rollen](iam-identity-mappings.md)