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. # EKS Pod Identity-Assoziationen AWS EKS hat einen neuen erweiterten Mechanismus namens Pod Identity Association eingeführt, mit dem Clusteradministratoren Kubernetes-Anwendungen so konfigurieren können, dass sie IAM-Berechtigungen erhalten, die für die Verbindung mit AWS-Services außerhalb des Clusters erforderlich sind. Pod Identity Association nutzt IRSA, macht es jedoch direkt über die EKS-API konfigurierbar, sodass die Verwendung der IAM-API vollständig entfällt. Infolgedessen müssen IAM-Rollen nicht mehr auf einen [OIDC-Anbieter](iamserviceaccounts.md#iam-how-works) verweisen und sind daher nicht mehr an einen einzelnen Cluster gebunden. Das bedeutet, dass IAM-Rollen jetzt in mehreren EKS-Clustern verwendet werden können, ohne dass die Rollenvertrauensrichtlinie jedes Mal aktualisiert werden muss, wenn ein neuer Cluster erstellt wird. Dies wiederum macht die Duplizierung von Rollen überflüssig und vereinfacht den Prozess der IRSA-Automatisierung insgesamt. ## Voraussetzungen Hinter den Kulissen wird bei der Implementierung von Pod-Identitätszuordnungen ein Agent als Daemonset auf den Worker-Knoten ausgeführt. Um den erforderlichen Agenten auf dem Cluster auszuführen, bietet EKS ein neues Add-on namens EKS Pod Identity Agent. Daher muss für die Erstellung von Pod-Identitätszuordnungen (im Allgemeinen und mit`eksctl`) das `eks-pod-identity-agent` Addon auf dem Cluster vorinstalliert sein. Dieses Addon kann auf die gleiche Weise wie jedes andere unterstützte Addon erstellt `eksctl` werden. ``` eksctl create addon --cluster my-cluster --name eks-pod-identity-agent ``` Wenn Sie beim Erstellen einer Pod-Identitätszuordnung eine bereits vorhandene IAM-Rolle verwenden, müssen Sie die Rolle außerdem so konfigurieren, dass sie dem neu eingeführten EKS-Dienstprinzipal () vertraut. `pods.eks.amazonaws.com` Ein Beispiel für eine IAM-Vertrauensrichtlinie finden Sie unten: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` Wenn Sie stattdessen nicht den ARN einer vorhandenen Rolle für den Befehl create angeben, `eksctl` wird hinter den Kulissen eine erstellt und die obige Vertrauensrichtlinie konfiguriert. ## Pod-Identitätszuordnungen erstellen Für die Manipulation von Pod-Identitätszuordnungen `eksctl` wurde ein neues Feld hinzugefügt`iam.podIdentityAssociations`, z. B. ``` iam: podIdentityAssociations: - namespace: #required serviceAccountName: #required createServiceAccount: true #optional, default is false roleARN: #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields. roleName: #optional, generated automatically if not provided, ignored if roleARN is provided permissionPolicy: {} #optional permissionPolicyARNs: [] #optional wellKnownPolicies: {} #optional permissionsBoundaryARN: #optional tags: {} #optional ``` Ein vollständiges Beispiel finden Sie unter [pod-identity-associations.yaml.](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.yaml) **Anmerkung** Abgesehen `permissionPolicy` davon, dass es als Inline-Richtliniendokument verwendet wird, haben alle anderen Felder ein CLI-Flag-Gegenstück. Das Erstellen von Pod-Identitätszuordnungen kann auf folgende Weise erreicht werden. Während der Clustererstellung, indem Sie die gewünschten Pod-Identitätszuordnungen als Teil der Konfigurationsdatei angeben und Folgendes ausführen: ``` eksctl create cluster -f config.yaml ``` Nach der Clustererstellung entweder mit einer Konfigurationsdatei, z. B. ``` eksctl create podidentityassociation -f config.yaml ``` ODER mit CLI-Flags, z. B. ``` eksctl create podidentityassociation \ --cluster my-cluster \ --namespace default \ --service-account-name s3-reader \ --permission-policy-arns="arn:aws:iam::111122223333:policy/permission-policy-1, arn:aws:iam::111122223333:policy/permission-policy-2" \ --well-known-policies="autoScaler,externalDNS" \ --permissions-boundary-arn arn:aws:iam::111122223333:policy/permissions-boundary ``` **Anmerkung** Einem Dienstkonto kann jeweils nur eine IAM-Rolle zugeordnet werden. Daher führt der Versuch, eine zweite Pod-Identitätszuordnung für dasselbe Dienstkonto zu erstellen, zu einem Fehler. ## Pod-Identitätszuordnungen werden abgerufen Führen Sie einen der folgenden Befehle aus, um alle Pod-Identitätszuordnungen für einen bestimmten Cluster abzurufen: ``` eksctl get podidentityassociation -f config.yaml ``` ODER ``` eksctl get podidentityassociation --cluster my-cluster ``` Um zusätzlich nur die Pod-Identitätszuordnungen innerhalb eines bestimmten Namespace abzurufen, verwenden Sie das `--namespace` Flag, z. B. ``` eksctl get podidentityassociation --cluster my-cluster --namespace default ``` Um schließlich eine einzelne Assoziation abzurufen, die einem bestimmten K8s-Dienstkonto entspricht, fügen Sie auch den obigen Befehl `--service-account-name` hinzu, d. h. ``` eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Aktualisierung der Pod-Identitätszuordnungen Um die IAM-Rolle einer oder mehrerer Pod-Identitätszuordnungen zu aktualisieren, übergeben Sie entweder die neuen Daten `roleARN(s)` an die Konfigurationsdatei, z. B. ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader roleARN: new-role-arn-1 - namespace: dev serviceAccountName: app-cache-access roleARN: new-role-arn-2 ``` und führe Folgendes aus: ``` eksctl update podidentityassociation -f config.yaml ``` ODER (um eine einzelne Assoziation zu aktualisieren) übergeben Sie die neuen `--role-arn` über CLI-Flags: ``` eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn ``` ## Pod-Identitätszuordnungen löschen Um eine oder mehrere Pod-Identitätszuordnungen zu löschen, übergeben Sie entweder `namespace(s)` und `serviceAccountName(s)` an die Konfigurationsdatei, z. B. ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader - namespace: dev serviceAccountName: app-cache-access ``` und führe Folgendes aus: ``` eksctl delete podidentityassociation -f config.yaml ``` ODER (um eine einzelne Assoziation zu löschen) übergeben Sie die `--namespace` und `--service-account-name` über die CLI-Flags: ``` eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Unterstützung von EKS-Add-Ons für Pod-Identitätszuordnungen EKS-Add-Ons unterstützen auch den Empfang von IAM-Berechtigungen über EKS Pod Identity Associations. Die Konfigurationsdatei enthält drei Felder, mit denen diese konfiguriert werden können:`addon.podIdentityAssociations`, und`addonsConfig.autoApplyPodIdentityAssociations`. `addon.useDefaultPodIdentityAssociations` Sie können entweder die gewünschten Pod-Identitätszuordnungen explizit konfigurieren`addon.podIdentityAssociations`, indem Sie entweder `addonsConfig.autoApplyPodIdentityAssociations` oder verwenden, oder die empfohlene Konfiguration der Pod-Identität `eksctl` automatisch auflösen (und anwenden) lassen. `addon.useDefaultPodIdentityAssociations` **Anmerkung** Nicht alle EKS-Add-Ons unterstützen Pod-Identitätszuordnungen beim Start. In diesem Fall müssen die erforderlichen IAM-Berechtigungen weiterhin mithilfe der [IRSA-Einstellungen](addons.md#addons-create) bereitgestellt werden. ### Addons mit IAM-Berechtigungen erstellen Wenn Sie ein Addon erstellen, für das IAM-Berechtigungen erforderlich sind, `eksctl` wird zunächst geprüft, ob entweder Pod-Identitätszuordnungen oder IRSA-Einstellungen explizit als Teil der Konfigurationsdatei konfiguriert wurden, und falls ja, verwenden Sie eine davon, um die Berechtigungen für das Addon zu konfigurieren. z. B. ``` addons: - name: vpc-cni podIdentityAssociations: - serviceAccountName: aws-node permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] ``` und starte ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] pod identity associations are set for "vpc-cni" addon; will use these to configure required IAM permissions ``` **Anmerkung** Das gleichzeitige Einstellen von Pod-Identitäten und IRSA ist nicht zulässig und führt zu einem Validierungsfehler. `eksctl`Bietet für EKS-Add-Ons, die Pod-Identitäten unterstützen, die Option, alle empfohlenen IAM-Berechtigungen bei der Addon-Erstellung automatisch zu konfigurieren. Dies kann durch einfaches Einstellen `addonsConfig.autoApplyPodIdentityAssociations: true` in der Konfigurationsdatei erreicht werden. z.B. ``` addonsConfig: autoApplyPodIdentityAssociations: true # bear in mind that if either pod identity or IRSA configuration is explicitly set in the config file, # or if the addon does not support pod identities, # addonsConfig.autoApplyPodIdentityAssociations won't have any effect. addons: - name: vpc-cni ``` und laufe ``` eksctl create addon -f config.yaml 2024-05-13 15:38:58 [ℹ] "addonsConfig.autoApplyPodIdentityAssociations" is set to true; will lookup recommended pod identity configuration for "vpc-cni" addon ``` Entsprechendes kann dasselbe über CLI-Flags erfolgen, z. ``` eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations ``` Um ein vorhandenes Addon zur Verwendung der Pod-Identität mit den empfohlenen IAM-Richtlinien zu migrieren, verwenden Sie ``` addons: - name: vpc-cni useDefaultPodIdentityAssociations: true ``` ``` eksctl update addon -f config.yaml ``` ### Aktualisierung von Addons mit IAM-Berechtigungen Bei der Aktualisierung eines Addons `addon.PodIdentityAssociations` stellt die Angabe die einzige Informationsquelle für den Status dar, den das Addon nach Abschluss des Aktualisierungsvorgangs haben soll. Hinter den Kulissen werden verschiedene Arten von Operationen ausgeführt, um den gewünschten Status zu erreichen, d. h. + Pod-Identitäten erstellen, die in der Konfigurationsdatei vorhanden sind, aber im Cluster fehlen + löschen Sie vorhandene Pod-Identitäten, die aus der Konfigurationsdatei entfernt wurden, zusammen mit allen zugehörigen IAM-Ressourcen + aktualisieren Sie bestehende Pod-Identitäten, die auch in der Konfigurationsdatei vorhanden sind und für die sich die IAM-Berechtigungen geändert haben **Anmerkung** Der Lebenszyklus von Pod-Identitätszuordnungen, die EKS Add-ons gehören, wird direkt von der EKS Addons API verwaltet. Sie können `eksctl update podidentityassociation` (um IAM-Berechtigungen zu aktualisieren) oder `eksctl delete podidentityassociations` (um die Zuordnung zu entfernen) nicht für Verknüpfungen verwenden, die mit einem Amazon EKS-Add-on verwendet werden. Stattdessen `eksctl delete addon` soll `eksctl update addon` oder verwendet werden. Sehen wir uns ein Beispiel für das Obige an, beginnend mit der Analyse der anfänglichen Pod-Identitätskonfiguration für das Addon: ``` eksctl get podidentityassociation --cluster my-cluster --namespace opentelemetry-operator-system --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-JwrGA4mn1Ny8", # OwnerARN is populated when the pod identity lifecycle is handled by the EKS Addons API "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-Xc7qVg5fgCqr", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/b2c7bb45-4090-bf34-ec78-a2298b8643f6" } ] ``` Verwenden Sie nun die folgende Konfiguration: ``` addons: - name: adot podIdentityAssociations: # For the first association, the permissions policy of the role will be updated - serviceAccountName: adot-col-prom-metrics permissionPolicyARNs: #- arn:aws:iam::aws:policy/AmazonPrometheusRemoteWriteAccess - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy # The second association will be deleted, as it's been removed from the config file #- serviceAccountName: adot-col-otlp-ingest # permissionPolicyARNs: # - arn:aws:iam::aws:policy/AWSXrayWriteOnlyAccess # The third association will be created, as it's been added to the config file - serviceAccountName: adot-col-container-logs permissionPolicyARNs: - arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy ``` und renne ``` eksctl update addon -f config.yaml ... # updating the permission policy for the first association 2024-05-14 13:27:43 [ℹ] updating IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for pod identity association "a-reaxk2uz1iknwazwj" 2024-05-14 13:27:44 [ℹ] waiting for CloudFormation changeset "eksctl-opentelemetry-operator-system-adot-col-prom-metrics-update-1715682463" for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" 2024-05-14 13:28:47 [ℹ] updated IAM resources stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-prom-metrics" for "a-reaxk2uz1iknwazwj" # creating the IAM role for the second association 2024-05-14 13:28:48 [ℹ] deploying stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:28:48 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" 2024-05-14 13:29:19 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-container-logs" # updating the addon, which handles the pod identity config changes behind the scenes 2024-05-14 13:29:19 [ℹ] updating addon # deleting the IAM role for the third association 2024-05-14 13:29:19 [ℹ] deleting IAM resources for pod identity service account adot-col-otlp-ingest 2024-05-14 13:29:20 [ℹ] will delete stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:20 [ℹ] waiting for stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" to get deleted 2024-05-14 13:29:51 [ℹ] waiting for CloudFormation stack "eksctl-my-cluster-addon-adot-podidentityrole-adot-col-otlp-ingest" 2024-05-14 13:29:51 [ℹ] deleted IAM resources for addon adot ``` Überprüfen Sie nun, ob die Pod-Identitätskonfiguration korrekt aktualisiert wurde ``` eksctl get podidentityassociation --cluster my-cluster --output json [ { ... "ServiceAccountName": "adot-col-prom-metrics", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-nQAlp0KktS2A", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" }, { ... "ServiceAccountName": "adot-col-otlp-ingest", "RoleARN": "arn:aws:iam::111122223333:role/eksctl-my-cluster-addon-adot-podident-Role1-1k1XhAdziGzX", "OwnerARN": "arn:aws:eks:us-west-2:111122223333:addon/my-cluster/adot/1ec7bb63-8c4e-ca0a-f947-310c4b55052e" } ] ``` Um alle Pod-Identitätszuordnungen aus einem Addon zu entfernen, `addon.PodIdentityAssociations` muss es explizit auf gesetzt werden`[]`, z. ``` addons: - name: vpc-cni # omitting the `podIdentityAssociations` field from the config file, # instead of explicitly setting it to [], will result in a validation error podIdentityAssociations: [] ``` und laufe ``` eksctl update addon -f config.yaml ``` ### Löschen von Addons mit IAM-Berechtigungen Durch das Löschen eines Addons werden auch alle mit dem Addon verknüpften Pod-Identitäten entfernt. Durch das Löschen des Clusters wird derselbe Effekt für alle Addons erzielt. Alle IAM-Rollen für Pod-Identitäten, die von erstellt wurden`eksctl`, werden ebenfalls gelöscht. ## Migrieren vorhandener IAM-Servicekonten und Addons zu Pod-Identitätszuordnungen Es gibt einen Befehl `eksctl` utils für die Migration vorhandener IAM-Rollen für Dienstkonten zu Pod-Identitätszuordnungen, d. h. ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve ``` Hinter den Kulissen führt der Befehl die folgenden Schritte aus: + installieren Sie das `eks-pod-identity-agent` Addon, falls es nicht bereits auf dem Cluster aktiv ist + Identifizieren Sie alle IAM-Rollen, die iamserviceaccounts zugeordnet sind + Identifizieren Sie alle IAM-Rollen, die mit EKS-Addons verknüpft sind, die Pod-Identitätszuordnungen unterstützen + aktualisieren Sie die IAM-Vertrauensrichtlinie aller identifizierten Rollen mit einer zusätzlichen vertrauenswürdigen Entität, die auf den neuen EKS-Dienstprinzipal verweist (und entfernen Sie optional die bestehende OIDC-Anbieter-Vertrauensbeziehung) + Pod-Identitätszuordnungen für gefilterte Rollen erstellen, die iamserviceaccounts zugeordnet sind + Aktualisieren Sie EKS-Addons mit Pod-Identitäten (die EKS-API erstellt die Pod-Identitäten hinter den Kulissen) Wenn Sie den Befehl ohne die `--approve` Markierung ausführen, wird nur ein Plan ausgegeben, der aus einer Reihe von Aufgaben besteht, die die oben genannten Schritte widerspiegeln, z. ``` [ℹ] (plan) would migrate 2 iamserviceaccount(s) and 2 addon(s) to pod identity association(s) by executing the following tasks [ℹ] (plan) 3 sequential tasks: { install eks-pod-identity-agent addon, ## tasks for migrating the addons 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-DDuMLoeZ8weD", migrate addon aws-ebs-csi-driver to pod identity, }, 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-xYiPFOVp1aeI", migrate addon vpc-cni to pod identity, }, }, ## tasks for migrating the iamserviceaccounts 2 parallel sub-tasks: { 2 sequential sub-tasks: { update trust policy for owned role "eksctl-my-cluster--Role1-QLXqHcq9O1AR", create pod identity association for service account "default/sa1", }, 2 sequential sub-tasks: { update trust policy for unowned role "Unowned-Role1", create pod identity association for service account "default/sa2", }, } } [ℹ] all tasks were skipped [!] no changes were applied, run again with '--approve' to apply the changes ``` Die bestehende Vertrauensstellung zwischen OIDC-Anbietern wird immer aus den IAM-Rollen entfernt, die mit EKS-Add-Ons verknüpft sind. Um außerdem die bestehende Vertrauensstellung eines OIDC-Anbieters aus den IAM-Rollen zu entfernen, die iamserviceaccounts zugeordnet sind, führen Sie den Befehl mit Flag aus, z. B. `--remove-oidc-provider-trust-relationship` ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship ``` ## Support für kontoübergreifende Pod-Identitäten eksctl unterstützt den [kontoübergreifenden Zugriff auf EKS Pod Identity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html). Mit dieser Funktion können Pods, die in Ihrem EKS-Cluster ausgeführt werden, auf AWS-Ressourcen in einem anderen AWS-Konto zugreifen. ### Usage Um eine Pod-Identitätszuordnung mit kontoübergreifendem Zugriff zu erstellen, richten Sie zunächst IAM-Rollen und -Richtlinien ein, die den Zugriff von einem AWS-Quellkonto (mit dem Cluster) auf ein AWS-Zielkonto (mit den Ressourcen, auf die der Cluster zugreifen kann) ermöglichen. Ein Beispiel hierfür finden Sie unter [„Amazon EKS Pod Identity optimiert den kontoübergreifenden Zugriff“.](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/) Sobald in jedem Konto eine IAM-Rolle konfiguriert ist, verwenden Sie eksctl, um die Pod-Identitätszuordnungen zu erstellen: ``` apiVersion: eksctl.io/v1alpha5 kind: ClusterConfig metadata: # The cluster name and service account name should match the target # account policy's trust relationship. name: my-cluster region: us-west-2 version: "1.32" addons: - name: vpc-cni - name: coredns - name: kube-proxy - name: eks-pod-identity-agent iam: podIdentityAssociations: - namespace: default serviceAccountName: demo-app-sa createServiceAccount: true # The source role in the same account as the cluster roleARN: arn:aws:iam::1111111111:role/account-a-role # The target role in a different account targetRoleARN: arn:aws:iam::2222222222:role/account-b-role # Optional: Disable session tags disableSessionTags: false managedNodeGroups: - name: my-cluster instanceType: m6a.large privateNetworking: true minSize: 2 desiredCapacity: 2 maxSize: 3 ``` ## Weitere Verweise [Offizielle Unterstützung von AWS-Benutzerdokumenten für EKS Add-Ons für Pod-Identitäten](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html) [Offizieller AWS-Blogbeitrag zu Pod Identity Associations](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/) [Offizielle AWS-Benutzerdokumente für Pod Identity Associations](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)