Associations d'identité EKS Pod

AWS EKS a introduit un nouveau mécanisme amélioré appelé Pod Identity Association permettant aux administrateurs de clusters de configurer les applications Kubernetes afin de recevoir les autorisations IAM requises pour se connecter aux services AWS en dehors du cluster. Pod Identity Association tire parti de l'IRSA, mais le rend configurable directement via l'API EKS, éliminant ainsi le besoin d'utiliser l'API IAM.

Par conséquent, les rôles IAM n'ont plus besoin de faire référence à un fournisseur OIDC et ne seront donc plus liés à un seul cluster. Cela signifie que les rôles IAM peuvent désormais être utilisés sur plusieurs clusters EKS sans qu'il soit nécessaire de mettre à jour la politique de confiance des rôles à chaque fois qu'un nouveau cluster est créé. Cela élimine à son tour le besoin de duplication des rôles et simplifie complètement le processus d'automatisation de l'IRSA.

Prérequis

Dans les coulisses, la mise en œuvre des associations d'identité des pods consiste à exécuter un agent en tant que daemonset sur les nœuds de travail. Pour exécuter l'agent prérequis sur le cluster, EKS fournit un nouveau module complémentaire appelé EKS Pod Identity Agent. Par conséquent, la création d'associations d'identité de pod (en général et aveceksctl) nécessite que l'eks-pod-identity-agentaddon soit préinstallé sur le cluster. Cet addon peut être créé de la même manière que n'importe quel autre addon compatible. eksctl

Note

Si vous utilisez le cluster EKS Auto Mode, celui-ci eks-pod-identity-agent est préinstallé et vous pouvez ignorer la création de l'addon.

eksctl create addon --cluster my-cluster --name eks-pod-identity-agent

En outre, si vous utilisez un rôle IAM préexistant lors de la création d'une association d'identité de pod, vous devez configurer le rôle pour qu'il fasse confiance au nouveau principal de service EKS ()pods.eks.amazonaws.com. Vous trouverez ci-dessous un exemple de politique de confiance IAM :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "pods.eks.amazonaws.com"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:TagSession"
            ]
        }
    ]
}

Si, au contraire, vous ne fournissez pas l'ARN d'un rôle existant à la commande create, eksctl vous en créerez un en arrière-plan et configurerez la politique de confiance ci-dessus.

Création d'associations d'identité de pods

Pour manipuler les associations d'identité des pods, eksctl a ajouté un nouveau champ sousiam.podIdentityAssociations, par ex.

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

Pour un exemple complet, reportez-vous au pod-identity-associationsfichier .yaml.

Note

Hormis celui permissionPolicy qui est utilisé comme document de politique intégré, tous les autres champs ont un équivalent d'indicateur CLI.

La création d'associations d'identité de pods peut être réalisée de la manière suivante. Lors de la création du cluster, en spécifiant les associations d'identité de pod souhaitées dans le fichier de configuration et en exécutant :

eksctl create cluster -f config.yaml

Après la création du cluster, en utilisant soit un fichier de configuration, par exemple

eksctl create podidentityassociation -f config.yaml

OU en utilisant des drapeaux CLI, par exemple

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

Note

Un seul rôle IAM peut être associé à un compte de service à la fois. Par conséquent, toute tentative de création d'une deuxième association d'identité de pod pour le même compte de service entraînera une erreur.

Récupération des associations d'identité des pods

Pour récupérer toutes les associations d'identité des pods pour un cluster donné, exécutez l'une des commandes suivantes :

eksctl get podidentityassociation -f config.yaml

OU

eksctl get podidentityassociation --cluster my-cluster

De plus, pour récupérer uniquement les associations d'identité des pods dans un espace de noms donné, utilisez le --namespace drapeau, par exemple

eksctl get podidentityassociation --cluster my-cluster --namespace default

Enfin, pour récupérer une seule association, correspondant à un certain compte de service K8s, incluez également la --service-account-name commande ci-dessus, c'est-à-dire

eksctl get podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader

Mettre à jour les associations d'identité des pods

Pour mettre à jour le rôle IAM d'une ou de plusieurs associations d'identité de pod, transmettez la nouvelle roleARN(s) au fichier de configuration, par exemple

iam:
  podIdentityAssociations:
    - namespace: default
      serviceAccountName: s3-reader
      roleARN: new-role-arn-1
    - namespace: dev
      serviceAccountName: app-cache-access
      roleARN: new-role-arn-2

et lancez :

eksctl update podidentityassociation -f config.yaml

OU (pour mettre à jour une seule association) transmettez les nouveaux indicateurs --role-arn via la CLI :

eksctl update podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader --role-arn new-role-arn

Supprimer les associations d'identité des pods

Pour supprimer une ou plusieurs associations d'identité de pod, transmettez-les namespace(s) serviceAccountName(s) au fichier de configuration, par exemple

iam:
  podIdentityAssociations:
    - namespace: default
      serviceAccountName: s3-reader
    - namespace: dev
      serviceAccountName: app-cache-access

et lancez :

eksctl delete podidentityassociation -f config.yaml

OU (pour supprimer une seule association) transmettez les indicateurs --namespace et --service-account-name via la CLI :

eksctl delete podidentityassociation --cluster my-cluster --namespace default --service-account-name s3-reader

Support des modules complémentaires EKS pour les associations d'identité des pods

Les modules complémentaires EKS permettent également de recevoir des autorisations IAM via EKS Pod Identity Associations. Le fichier de configuration expose trois champs qui permettent de les configurer :addon.podIdentityAssociations, addonsConfig.autoApplyPodIdentityAssociations etaddon.useDefaultPodIdentityAssociations. Vous pouvez soit configurer explicitement les associations d'identité d'espace souhaitées, en utilisantaddon.podIdentityAssociations, soit résoudre (et appliquer) eksctl automatiquement la configuration d'identité d'espace recommandée, en utilisant l'un addonsConfig.autoApplyPodIdentityAssociations ou l'autre des deuxaddon.useDefaultPodIdentityAssociations.

Note

Les modules complémentaires EKS ne prendront pas tous en charge les associations d'identité des pods au lancement. Dans ce cas, les autorisations IAM requises doivent continuer à être fournies à l'aide des paramètres IRSA.

Création d'addons avec des autorisations IAM

Lorsque vous créez un addon nécessitant des autorisations IAM, eksctl vous devez d'abord vérifier si les associations d'identité du pod ou les paramètres IRSA sont explicitement configurés dans le fichier de configuration, et si c'est le cas, utiliser l'un d'entre eux pour configurer les autorisations pour l'addon. Par exemple

addons:
- name: vpc-cni
  podIdentityAssociations:
  - serviceAccountName: aws-node
    permissionPolicyARNs: ["arn:aws:iam::aws:policy/AmazonEKS_CNI_Policy"]

et courez

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

Note

La définition simultanée de l'identité du pod et de l'IRSA n'est pas autorisée et entraînera une erreur de validation.

Pour les modules complémentaires EKS qui prennent en charge les identités eksctl des pods, offre la possibilité de configurer automatiquement les autorisations IAM recommandées, lors de la création de l'addon. Cela peut être réalisé addonsConfig.autoApplyPodIdentityAssociations: true en configurant simplement le fichier de configuration. par exemple

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

et courez

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

De manière équivalente, la même chose peut être faite via les drapeaux de la CLI, par exemple

eksctl create addon --cluster my-cluster --name vpc-cni --auto-apply-pod-identity-associations

Pour migrer un addon existant afin d'utiliser l'identité du pod avec les politiques IAM recommandées, utilisez

addons:
- name: vpc-cni
  useDefaultPodIdentityAssociations: true

eksctl update addon -f config.yaml

Mise à jour des addons avec des autorisations IAM

Lors de la mise à jour d'un addon, la spécification addon.PodIdentityAssociations représentera la source unique de vérité pour l'état que l'addon devra avoir, une fois l'opération de mise à jour terminée. Dans les coulisses, différents types d'opérations sont effectués afin d'atteindre l'état souhaité, c'est-à-dire

• créer des identifiants de pod présents dans le fichier de configuration, mais absents du cluster

• supprimer les identifiants de pod existants qui ont été supprimés du fichier de configuration, ainsi que toutes les ressources IAM associées

• mettre à jour les identités de pod existantes qui sont également présentes dans le fichier de configuration et pour lesquelles l'ensemble des autorisations IAM a changé

Note

Le cycle de vie des associations d'identité des pods détenues par EKS Add-ons est directement géré par l'API EKS Addons.

Vous ne pouvez pas utiliser eksctl update podidentityassociation (pour mettre à jour les autorisations IAM) ou eksctl delete podidentityassociations (pour supprimer l'association) pour les associations utilisées avec un module complémentaire Amazon EKS. Au lieu de cela, eksctl update addon ou eksctl delete addon doit être utilisé.

Voyons un exemple pour ce qui précède, en commençant par analyser la configuration initiale de l'identité du pod pour 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"
    }
]

Utilisez maintenant la configuration ci-dessous :

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

et courez

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

vérifiez maintenant que la configuration de l'identité du pod a été correctement mise à jour

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"
    }
]

Pour supprimer toutes les associations d'identité de pod d'un addon, celui-ci addon.PodIdentityAssociations doit être explicitement défini sur[], par exemple

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: []

et courez

eksctl update addon -f config.yaml

Supprimer des addons avec des autorisations IAM

La suppression d'un addon supprimera également toutes les identités de pod associées à l'addon. La suppression du cluster produira le même effet, pour tous les addons. Tous les rôles IAM pour les identités des pods, créés pareksctl, seront également supprimés.

Migration de comptes iamservice et d'extensions existants vers des associations d'identité de pod

Il existe une commande eksctl utils pour migrer les rôles IAM existants pour les comptes de service vers des associations d'identité de pod, c'est-à-dire

eksctl utils migrate-to-pod-identity --cluster my-cluster --approve

Dans les coulisses, la commande appliquera les étapes suivantes :

• installer l'eks-pod-identity-agentaddon s'il n'est pas déjà actif sur le cluster

• identifier tous les rôles IAM associés à iamserviceaccounts

• identifier tous les rôles IAM associés aux modules complémentaires EKS qui prennent en charge les associations d'identité des pods

• mettre à jour la politique de confiance IAM de tous les rôles identifiés, avec une entité de confiance supplémentaire, pointant vers le nouveau principal du service EKS (et, éventuellement, supprimer la relation de confiance existante avec le fournisseur OIDC)

• créer des associations d'identité de pod pour les rôles filtrés associés à iamserviceaccounts

• mettre à jour les extensions EKS avec les identités des pods (l'API EKS créera les identités des pods en arrière-plan)

L'exécution de la commande sans l'--approveindicateur produira uniquement un plan composé d'un ensemble de tâches reflétant les étapes ci-dessus, par ex.

[ℹ]  (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 relation de confiance existante avec le fournisseur OIDC est toujours supprimée des rôles IAM associés aux modules complémentaires EKS. En outre, pour supprimer la relation de confiance existante du fournisseur OIDC dans les rôles IAM associés à iamserviceaccounts, exécutez la commande avec un indicateur, par exemple --remove-oidc-provider-trust-relationship

eksctl utils migrate-to-pod-identity --cluster my-cluster --approve --remove-oidc-provider-trust-relationship

Autres références

Support officiel d'AWS Userdocs pour les modules complémentaires EKS pour les identités des pods

Article de blog officiel d'AWS sur les associations d'identité des pods

Documents utilisateur AWS officiels pour Pod Identity Associations