Asociaciones de identidad de EKS Pod

AWS EKS ha introducido un nuevo mecanismo mejorado denominado Pod Identity Association para que los administradores de clústeres puedan configurar las aplicaciones de Kubernetes para recibir los permisos de IAM necesarios para conectarse con los servicios de AWS fuera del clúster. Pod Identity Association aprovecha el IRSA, pero lo hace configurable directamente a través de la API de EKS, lo que elimina por completo la necesidad de utilizar la API de IAM.

Como resultado, las funciones de IAM ya no necesitan hacer referencia a un proveedor de OIDC y, por lo tanto, ya no estarán vinculadas a un solo clúster. Esto significa que las funciones de IAM ahora se pueden utilizar en varios clústeres de EKS sin necesidad de actualizar la política de confianza de los roles cada vez que se crea un clúster nuevo. Esto, a su vez, elimina la necesidad de duplicar las funciones y simplifica por completo el proceso de automatización del IRSA.

Requisitos previos

Entre bastidores, la implementación de las asociaciones de identidad de los módulos consiste en ejecutar un agente como un demonio en los nodos de trabajo. Para ejecutar el agente necesario en el clúster, EKS proporciona un nuevo complemento llamado EKS Pod Identity Agent. Por lo tanto, la creación de asociaciones de identidad de pods (en general y coneksctl) requiere que el eks-pod-identity-agent complemento esté preinstalado en el clúster. Este complemento se puede crear de la misma manera que cualquier otro complemento compatible. eksctl

nota

Si está utilizando el clúster EKS Auto Mode, eks-pod-identity-agent viene preinstalado y puede omitir la creación del complemento.

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

Además, si utiliza un rol de IAM preexistente al crear una asociación de identidad de pod, debe configurar el rol para que confíe en el nuevo director de servicio de EKS (). pods.eks.amazonaws.com A continuación se muestra un ejemplo de política de confianza de IAM:

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

Si, por el contrario, no proporciona el ARN de un rol existente al comando create, eksctl creará uno entre bastidores y configurará la política de confianza anterior.

Creación de asociaciones de identidad de pods

Para manipular las asociaciones de identidad de los pods, eksctl ha añadido un nuevo campo eniam.podIdentityAssociations, p. ej.

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

Para ver un ejemplo completo, consulta pod-identity-associations.yaml.

nota

Además de permissionPolicy que se utiliza como documento de política en línea, todos los demás campos tienen una contraparte de marca CLI.

La creación de asociaciones de identidad de pods se puede lograr de las siguientes maneras. Durante la creación del clúster, especificando las asociaciones de identidad de los pods deseadas como parte del archivo de configuración y ejecutándolas:

eksctl create cluster -f config.yaml

Tras la creación del clúster, mediante un archivo de configuración, p. ej.

eksctl create podidentityassociation -f config.yaml

O utilizando indicadores CLI, p. ej.

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

Solo se puede asociar un único rol de IAM a una cuenta de servicio a la vez. Por lo tanto, si se intenta crear una segunda asociación de identidad de pod para la misma cuenta de servicio, se producirá un error.

Buscando asociaciones de identidad de pods

Para recuperar todas las asociaciones de identidad de los pods de un clúster determinado, ejecuta uno de los siguientes comandos:

eksctl get podidentityassociation -f config.yaml

OR

eksctl get podidentityassociation --cluster my-cluster

Además, para recuperar solo las asociaciones de identidad de los pods dentro de un espacio de nombres determinado, usa la --namespace marca, p. ej.

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

Por último, para recuperar una sola asociación, correspondiente a una determinada cuenta de servicio de K8s, incluye también el comando anterior--service-account-name, es decir

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

Actualización de las asociaciones de identidad de los pods

Para actualizar la función de IAM de una o más asociaciones de identidad de pods, pasa la nueva roleARN(s) al archivo de configuración, por ejemplo

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

y ejecuta:

eksctl update podidentityassociation -f config.yaml

O (para actualizar una sola asociación) pase la nueva --role-arn mediante indicadores CLI:

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

Eliminar las asociaciones de identidad de los pods

Para eliminar una o más asociaciones de identidad de un pod, pasa la namespace(s) dirección serviceAccountName(s) al archivo de configuración, p. ej.

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

y ejecuta:

eksctl delete podidentityassociation -f config.yaml

O (para eliminar una sola asociación) pase los indicadores --namespace y --service-account-name mediante CLI:

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

Los complementos de EKS son compatibles con las asociaciones de identidad de los pods

Los complementos de EKS también permiten recibir permisos de IAM a través de las asociaciones de identidad de los pods de EKS. El archivo de configuración muestra tres campos que permiten configurarlos:addon.podIdentityAssociations, yaddonsConfig.autoApplyPodIdentityAssociations. addon.useDefaultPodIdentityAssociations Puede configurar de forma explícita las asociaciones de identidad del pod que deseeaddon.podIdentityAssociations, o bien hacer que eksctl se resuelva (y aplique) automáticamente la configuración de identidad del pod recomendada, utilizando una de las dos addonsConfig.autoApplyPodIdentityAssociations opciones. addon.useDefaultPodIdentityAssociations

nota

No todos los complementos de EKS admitirán las asociaciones de identidad de los pods en el momento del lanzamiento. En este caso, los permisos de IAM necesarios se seguirán proporcionando mediante la configuración de IRSA.

Crear complementos con permisos de IAM

Al crear un complemento que requiera permisos de IAM, eksctl comprobará primero si las asociaciones de identidad de los pods o los ajustes de IRSA se han configurado de forma explícita como parte del archivo de configuración y, de ser así, utilizará uno de ellos para configurar los permisos del complemento, p. ej.

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

y ejecuta

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

No se permite configurar las identidades de los módulos y el IRSA al mismo tiempo y se producirá un error de validación.

En el caso de los complementos de EKS que admiten identidades de pods, eksctl ofrece la opción de configurar automáticamente los permisos de IAM recomendados al crear el complemento. Esto se puede lograr simplemente configurándolo addonsConfig.autoApplyPodIdentityAssociations: true en el archivo de configuración, p. ej.

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

y ejecuta

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 manera equivalente, lo mismo se puede hacer mediante indicadores CLI, p. ej.

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

Para migrar un complemento existente y utilizar la identidad del pod con las políticas de IAM recomendadas, utilice

addons:
- name: vpc-cni
  useDefaultPodIdentityAssociations: true

eksctl update addon -f config.yaml

Actualización de complementos con permisos de IAM

Al actualizar un complemento, especificarlo addon.PodIdentityAssociations representará la única fuente de información sobre el estado que tendrá el complemento una vez finalizada la operación de actualización. Entre bastidores, se realizan diferentes tipos de operaciones para alcanzar el estado deseado, es decir,

• cree las identidades de los pods que estén presentes en el archivo de configuración, pero que no estén en el clúster

• elimine las identidades de pod existentes que se eliminaron del archivo de configuración, junto con cualquier recurso de IAM asociado

• actualice las identidades de los pods existentes que también están presentes en el archivo de configuración y para las que se ha modificado el conjunto de permisos de IAM

nota

La API de complementos de EKS gestiona directamente el ciclo de vida de las asociaciones de identidad de los pods propiedad de EKS Add-ons.

No puede usar eksctl update podidentityassociation (para actualizar los permisos de IAM) ni eksctl delete podidentityassociations (para eliminar la asociación) para las asociaciones utilizadas con un complemento de Amazon EKS. En su lugar, eksctl update addon o se eksctl delete addon utilizará.

Veamos un ejemplo de lo anterior, empezando por analizar la configuración inicial de identidad del pod para el complemento:

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

Ahora usa la siguiente configuración:

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

y ejecuta

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

ahora compruebe que la configuración de identidad del pod se actualizó correctamente

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

Para eliminar todas las asociaciones de identidad de un pod de un complemento, addon.PodIdentityAssociations debe configurarse explícitamente en[], p. ej.

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

y ejecuta

eksctl update addon -f config.yaml

Eliminar complementos con permisos de IAM

Al eliminar un complemento, también se eliminarán todas las identidades de los pods asociadas al complemento. Al eliminar el clúster, se obtendrá el mismo efecto para todos los complementos. También se eliminarán todas las funciones de IAM creadas por eksctl las identidades de los pods.

Migración de las cuentas y complementos de iamservice existentes a las asociaciones de identidad de los pods

Hay un comando eksctl utils para migrar las funciones de IAM existentes para las cuentas de servicio a las asociaciones de identidad de los pods, es decir

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

Entre bastidores, el comando aplicará los siguientes pasos:

• instale el eks-pod-identity-agent complemento si aún no está activo en el clúster

• identifique todas las funciones de IAM asociadas a iamserviceaccounts

• identifique todas las funciones de IAM asociadas a los complementos de EKS que admiten asociaciones de identidad de pods

• actualice la política de confianza de IAM de todas las funciones identificadas y añada una entidad de confianza adicional que dirija al nuevo director del servicio de EKS (y, si lo desea, elimine la relación de confianza existente entre los proveedores de OIDC)

• cree asociaciones de identidad de pod para las funciones filtradas asociadas a iamserviceaccounts

• actualice los complementos de EKS con las identidades de los pods (la API de EKS creará las identidades de los pods entre bastidores)

Al ejecutar el comando sin la --approve marca, solo se generará un plan compuesto por un conjunto de tareas que reflejen los pasos anteriores, p. ej.

[ℹ]  (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 relación de confianza existente entre los proveedores de OIDC siempre se elimina de las funciones de IAM asociadas a los complementos de EKS. Además, para eliminar la relación de confianza existente entre los proveedores de OIDC de las funciones de IAM asociadas a iamserviceaccounts, ejecute el comando con un indicador, p. ej. --remove-oidc-provider-trust-relationship

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

Más referencias

Compatibilidad con los complementos oficiales de AWS Userdocs for EKS para las identidades de los pods

Entrada oficial del blog de AWS sobre las asociaciones de identidad de los pods

Documentos de usuario oficiales de AWS para asociaciones de identidad de Pod