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 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 coneksctl) richiede l'eks-pod-identity-agentaddon preinstallato nel cluster. Questo componente aggiuntivo può essere creato utilizzando nello stesso modo eksctl in cui viene utilizzato qualsiasi altro componente aggiuntivo supportato.

Nota

Se utilizzi il cluster EKS Auto Mode, eks-pod-identity-agent viene preinstallato e puoi saltare la creazione dell'addon.

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 sottoiam.podIdentityAssociations, ad es.

iam:
  podIdentityAssociations:
  - namespace: <string> #required
    serviceAccountName: <string> #required
    createServiceAccount: true #optional, default is false
    roleARN: <string> #required if none of permissionPolicyARNs, permissionPolicy and wellKnownPolicies is specified. Also, cannot be used together with any of the three other referenced fields.
    roleName: <string> #optional, generated automatically if not provided, ignored if roleARN is provided
    permissionPolicy: {} #optional
    permissionPolicyARNs: [] #optional
    wellKnownPolicies: {} #optional
    permissionsBoundaryARN: <string> #optional
    tags: {} #optional

Per un esempio completo, fai riferimento a pod-identity-associations .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 ottenuta 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.

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 podeksctl, 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-agentaddon 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

Ulteriori riferimenti

Supporto ufficiale dei componenti aggiuntivi AWS Userdocs for EKS per le identità dei pod

Post ufficiale del blog AWS sulle associazioni di identità dei Pod

Userdocs ufficiali AWS per Pod Identity Associations