Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà. # Associazioni EKS Pod Identity AWS EKS ha introdotto un nuovo meccanismo avanzato chiamato Pod Identity Association per consentire agli amministratori di cluster di configurare le applicazioni Kubernetes per ricevere le autorizzazioni IAM necessarie per connettersi ai servizi AWS esterni al cluster. Pod Identity Association sfrutta IRSA, tuttavia la rende configurabile direttamente tramite l'API EKS, eliminando del tutto la necessità di utilizzare l'API IAM. Di conseguenza, i ruoli IAM non devono più fare riferimento a un [provider OIDC](iamserviceaccounts.md#iam-how-works) e quindi non saranno più legati a un singolo cluster. Ciò significa che i ruoli IAM possono ora essere utilizzati su più cluster EKS senza la necessità di aggiornare la policy di fiducia dei ruoli ogni volta che viene creato un nuovo cluster. Questo, a sua volta, elimina la necessità di duplicare i ruoli e semplifica del tutto il processo di automazione dell'IRSA. ## Prerequisiti Dietro le quinte, l'implementazione delle associazioni di identità dei pod consiste nell'eseguire un agente come demone sui nodi di lavoro. Per eseguire l'agente prerequisito sul cluster, EKS fornisce un nuovo componente aggiuntivo chiamato EKS Pod Identity Agent. Pertanto, la creazione di associazioni di identità dei pod (in generale e con`eksctl`) richiede l'`eks-pod-identity-agent`addon preinstallato nel cluster. Questo componente aggiuntivo può essere creato utilizzando nello stesso modo `eksctl` in cui viene utilizzato qualsiasi altro componente aggiuntivo supportato. ``` eksctl create addon --cluster my-cluster --name eks-pod-identity-agent ``` Inoltre, se si utilizza un ruolo IAM preesistente durante la creazione di un'associazione di identità del pod, è necessario configurare il ruolo in modo che consideri attendibile il service principal EKS appena introdotto (). `pods.eks.amazonaws.com` Di seguito è riportato un esempio di politica di fiducia IAM: ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "pods.eks.amazonaws.com" }, "Action": [ "sts:AssumeRole", "sts:TagSession" ] } ] } ``` Se invece non fornisci l'ARN di un ruolo esistente al comando create, ne creerà uno dietro le quinte e `eksctl` configurerà la politica di fiducia di cui sopra. ## Creazione di associazioni di identità Pod Per manipolare le associazioni di identità dei pod, `eksctl` ha aggiunto un nuovo campo sotto`iam.podIdentityAssociations`, ad es. ``` 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 ``` [Per un esempio completo, fai riferimento a pod-identity-associations .yaml.](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.yaml) **Nota** Oltre `permissionPolicy` a essere utilizzato come documento di policy in linea, tutti gli altri campi hanno una controparte con flag CLI. La creazione di associazioni di identità pod può essere eseguita nei seguenti modi. Durante la creazione del cluster, specificando le associazioni di identità dei pod desiderate come parte del file di configurazione ed eseguendo: ``` eksctl create cluster -f config.yaml ``` Dopo la creazione del cluster, utilizzando un file di configurazione, ad es. ``` eksctl create podidentityassociation -f config.yaml ``` O utilizzando i flag CLI, ad es. ``` 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 ``` **Nota** A un account di servizio può essere associato un solo ruolo IAM alla volta. Pertanto, il tentativo di creare una seconda associazione di identità del pod per lo stesso account di servizio genererà un errore. ## Recupero delle associazioni di identità dei pod Per recuperare tutte le associazioni di identità dei pod per un determinato cluster, esegui uno dei seguenti comandi: ``` eksctl get podidentityassociation -f config.yaml ``` O ``` eksctl get podidentityassociation --cluster my-cluster ``` Inoltre, per recuperare solo le associazioni di identità dei pod all'interno di un determinato namespace, usa il flag, ad es. `--namespace` ``` eksctl get podidentityassociation --cluster my-cluster --namespace default ``` Infine, per recuperare una singola associazione, corrispondente a un determinato account di servizio K8s, includi anche il `--service-account-name` comando precedente, ad es. ``` eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Aggiornamento delle associazioni di identità Pod Per aggiornare il ruolo IAM di una o più associazioni di identità dei pod, passa il nuovo `roleARN(s)` al file di configurazione, ad es. ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader roleARN: new-role-arn-1 - namespace: dev serviceAccountName: app-cache-access roleARN: new-role-arn-2 ``` ed esegui: ``` eksctl update podidentityassociation -f config.yaml ``` OPPURE (per aggiornare una singola associazione) passa la nuova `--role-arn` tramite i flag CLI: ``` eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn ``` ## Eliminazione delle associazioni di identità Pod Per eliminare una o più associazioni di identità dei pod, passale `namespace(s)` e `serviceAccountName(s)` al file di configurazione, ad es. ``` iam: podIdentityAssociations: - namespace: default serviceAccountName: s3-reader - namespace: dev serviceAccountName: app-cache-access ``` ed esegui: ``` eksctl delete podidentityassociation -f config.yaml ``` OPPURE (per eliminare una singola associazione) passa i flag `--namespace` e `--service-account-name` tramite CLI: ``` eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader ``` ## Supporto dei componenti aggiuntivi EKS per le associazioni di identità dei pod I componenti aggiuntivi EKS supportano anche la ricezione di autorizzazioni IAM tramite EKS Pod Identity Associations. Il file di configurazione espone tre campi che consentono di configurarli:, e. `addon.podIdentityAssociations` `addonsConfig.autoApplyPodIdentityAssociations` `addon.useDefaultPodIdentityAssociations` È possibile configurare in modo esplicito le associazioni di identità del pod desiderate utilizzando `addon.podIdentityAssociations` o far risolvere (e applicare) `eksctl` automaticamente la configurazione di identità del pod consigliata, utilizzando o. `addonsConfig.autoApplyPodIdentityAssociations` `addon.useDefaultPodIdentityAssociations` **Nota** Non tutti i componenti aggiuntivi EKS supporteranno le associazioni di identità dei pod al momento del lancio. In questo caso, le autorizzazioni IAM richieste continueranno a essere fornite utilizzando le impostazioni [IRSA](addons.md#addons-create). ### Creazione di componenti aggiuntivi con autorizzazioni IAM Quando crei un addon che richiede le autorizzazioni IAM, `eksctl` verificherà innanzitutto se le associazioni di identità dei pod o le impostazioni IRSA vengono configurate in modo esplicito come parte del file di configurazione e, in tal caso, utilizzerà una di queste per configurare le autorizzazioni per l'addon, ad es. ``` addons: - name: vpc-cni podIdentityAssociations: - serviceAccountName: aws-node permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"] ``` ed esegui ``` 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 ``` **Nota** L'impostazione contemporanea delle identità dei pod e dell'IRSA non è consentita e genererà un errore di convalida. Per i componenti aggiuntivi EKS che supportano le identità dei pod, `eksctl` offre la possibilità di configurare automaticamente tutte le autorizzazioni IAM consigliate, al momento della creazione dell'addon. Ciò può essere ottenuto semplicemente impostando il file di `addonsConfig.autoApplyPodIdentityAssociations: true` configurazione. ad es. ``` 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 ``` ed esegui ``` 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 ``` Equivalentemente, lo stesso può essere fatto tramite i flag CLI, ad es. ``` eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations ``` Per migrare un addon esistente per utilizzare l'identità del pod con le politiche IAM consigliate, usa ``` addons: - name: vpc-cni useDefaultPodIdentityAssociations: true ``` ``` eksctl update addon -f config.yaml ``` ### Aggiornamento dei componenti aggiuntivi con autorizzazioni IAM Quando si aggiorna un componente aggiuntivo, la specificazione `addon.PodIdentityAssociations` rappresenterà l'unica fonte di verità sullo stato che dovrà avere l'addon, una volta completata l'operazione di aggiornamento. Dietro le quinte, vengono eseguiti diversi tipi di operazioni per raggiungere lo stato desiderato, ad es. + crea identità di pod presenti nel file di configurazione, ma mancanti nel cluster + elimina gli identità dei pod esistenti che sono stati rimossi dal file di configurazione, insieme a tutte le risorse IAM associate + aggiorna le identità dei pod esistenti che sono presenti anche nel file di configurazione e per le quali è stato modificato il set di autorizzazioni IAM **Nota** Il ciclo di vita delle associazioni di identità dei pod di proprietà di EKS Add-ons viene gestito direttamente dall'API EKS Addons. Non puoi utilizzare `eksctl update podidentityassociation` (per aggiornare le autorizzazioni IAM) o `eksctl delete podidentityassociations` (per rimuovere l'associazione) per le associazioni utilizzate con un componente aggiuntivo Amazon EKS. Invece, `eksctl update addon` o `eksctl delete addon` deve essere usato. Vediamo un esempio di quanto sopra, iniziando con l'analisi della configurazione iniziale dell'identità del pod per l'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" } ] ``` Ora usa la configurazione seguente: ``` 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 ``` ed esegui ``` 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 ``` ora controlla che la configurazione dell'identità del pod sia stata aggiornata correttamente ``` 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" } ] ``` Per rimuovere tutte le associazioni di identità dei pod da un addon, `addon.PodIdentityAssociations` devono essere impostate esplicitamente su, ad es. `[]` ``` 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: [] ``` ed esegui ``` eksctl update addon -f config.yaml ``` ### Eliminazione di componenti aggiuntivi con autorizzazioni IAM L'eliminazione di un componente aggiuntivo rimuoverà anche tutte le identità del pod associate all'addon. L'eliminazione del cluster otterrà lo stesso effetto, per tutti i componenti aggiuntivi. Verranno eliminati anche tutti i ruoli IAM per le identità dei pod`eksctl`, creati da. ## Migrazione degli account e dei componenti aggiuntivi iamservice esistenti alle associazioni di identità dei pod Esiste un comando `eksctl` utils per la migrazione dei ruoli IAM esistenti per gli account di servizio alle associazioni di identità dei pod, ad es. ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve ``` Dietro le quinte, il comando applicherà i seguenti passaggi: + installa l'`eks-pod-identity-agent`addon se non è già attivo nel cluster + identifica tutti i ruoli IAM associati a iamserviceaccounts + identifica tutti i ruoli IAM associati ai componenti aggiuntivi EKS che supportano le associazioni di identità dei pod + aggiorna la policy di fiducia IAM di tutti i ruoli identificati, con un'ulteriore entità attendibile, che indichi il nuovo responsabile del servizio EKS (e, facoltativamente, rimuovi la relazione fiduciaria esistente con il provider OIDC) + crea associazioni di identità pod per i ruoli filtrati associati a iamserviceaccounts + aggiorna i componenti aggiuntivi EKS con le identità dei pod (l'API EKS creerà le identità dei pod dietro le quinte) L'esecuzione del comando senza il `--approve` flag produrrà solo un piano costituito da una serie di attività che riflettono i passaggi precedenti, ad es. ``` [ℹ] (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 ``` La relazione di fiducia esistente con il provider OIDC viene sempre rimossa dai ruoli IAM associati ai componenti aggiuntivi EKS. Inoltre, per rimuovere la relazione di fiducia esistente con il provider OIDC dai ruoli IAM associati a iamserviceaccounts, esegui il comando con flag, ad es. `--remove-oidc-provider-trust-relationship` ``` eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship ``` ## Supporto per Pod Identity su più account eksctl supporta l'accesso a più account [EKS Pod Identity.](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) Questa funzionalità consente ai pod in esecuzione nel cluster EKS di accedere alle risorse AWS in un altro account AWS. ### Utilizzo Per creare un'associazione di identità pod con accesso su più account, configura innanzitutto IAM Roles and Policies che consentano l'accesso da un account AWS di origine (con il cluster) a un account AWS di destinazione (con le risorse a cui il cluster può accedere). Per un esempio, consulta [«Amazon EKS Pod Identity semplifica l'accesso tra account».](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/) Una volta configurato un ruolo IAM in ogni account, usa eksctl per creare le associazioni di identità dei pod: ``` 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 ``` ## Ulteriori riferimenti [Supporto ufficiale dei componenti aggiuntivi AWS Userdocs for EKS per le identità dei pod](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html) [Post ufficiale del blog AWS sulle associazioni di identità dei pod](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/) [Userdocs ufficiali AWS per Pod Identity Associations](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)