Associações de identidade do EKS Pod

O AWS EKS introduziu um novo mecanismo aprimorado chamado Pod Identity Association para administradores de cluster configurarem aplicativos Kubernetes para receber as permissões do IAM necessárias para se conectar aos serviços da AWS fora do cluster. A Pod Identity Association aproveita o IRSA, mas o torna configurável diretamente por meio da API EKS, eliminando totalmente a necessidade de usar a API IAM.

Como resultado, as funções do IAM não precisam mais fazer referência a um provedor OIDC e, portanto, não estarão mais vinculadas a um único cluster. Isso significa que as funções do IAM agora podem ser usadas em vários clusters do EKS sem a necessidade de atualizar a política de confiança da função toda vez que um novo cluster é criado. Isso, por sua vez, elimina a necessidade de duplicação de funções e simplifica completamente o processo de automatização do IRSA.

Pré-requisitos

Nos bastidores, a implementação de associações de identidade de pod está executando um agente como daemonset nos nós de trabalho. Para executar o agente pré-requisito no cluster, o EKS fornece um novo complemento chamado EKS Pod Identity Agent. Portanto, criar associações de identidade de pod (em geral e comeksctl) requer o eks-pod-identity-agent complemento pré-instalado no cluster. Esse complemento pode ser criado usando eksctl da mesma forma que qualquer outro complemento compatível.

nota

Se você estiver usando o cluster EKS Auto Mode, eks-pod-identity-agent ele vem pré-instalado e você pode pular a criação do complemento.

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

Além disso, se estiver usando uma função preexistente do IAM ao criar uma associação de identidade de pod, você deve configurar a função para confiar no recém-introduzido EKS service principal (pods.eks.amazonaws.com). Um exemplo de política de confiança do IAM pode ser encontrado abaixo:

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

Se, em vez disso, você não fornecer o ARN de uma função existente ao comando create, eksctl criará uma nos bastidores e configurará a política de confiança acima.

Criação de associações de identidade de pod

Para manipular associações de identidade de pod, eksctl adicionou um novo campo abaixoiam.podIdentityAssociations, por exemplo

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 um exemplo completo, consulte pod-identity-associations.yaml.

nota

Além de ser permissionPolicy usado como um documento de política embutido, todos os outros campos têm uma contrapartida de bandeira CLI.

A criação de associações de identidade de pod pode ser feita das seguintes maneiras. Durante a criação do cluster, especificando as associações de identidade do pod desejadas como parte do arquivo de configuração e executando:

eksctl create cluster -f config.yaml

Pós-criação do cluster, usando um arquivo de configuração, por exemplo

eksctl create podidentityassociation -f config.yaml

OU usando sinalizadores CLI, por exemplo

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

Somente uma única função do IAM pode ser associada a uma conta de serviço por vez. Portanto, tentar criar uma segunda associação de identidade de pod para a mesma conta de serviço resultará em um erro.

Buscando associações de identidade do Pod

Para recuperar todas as associações de identidade de pod para um determinado cluster, execute um dos seguintes comandos:

eksctl get podidentityassociation -f config.yaml

OU

eksctl get podidentityassociation --cluster my-cluster

Além disso, para recuperar somente as associações de identidade do pod em um determinado namespace, use o --namespace sinalizador, por exemplo

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

Por fim, para recuperar uma única associação, correspondente a uma determinada conta de serviço K8s, inclua também o comando --service-account-name para o comando acima, ou seja,

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

Atualizando associações de identidade do pod

Para atualizar a função do IAM de uma ou mais associações de identidade de pod, passe a nova roleARN(s) para o arquivo de configuração, por exemplo

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

e execute:

eksctl update podidentityassociation -f config.yaml

OU (para atualizar uma única associação) passe a nova --role-arn por meio de sinalizadores CLI:

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

Excluindo associações de identidade do pod

Para excluir uma ou mais associações de identidade de pod, passe namespace(s) e serviceAccountName(s) para o arquivo de configuração, por exemplo

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

e execute:

eksctl delete podidentityassociation -f config.yaml

OU (para excluir uma única associação) passe os sinalizadores --namespace e --service-account-name por meio da CLI:

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

Suporte de complementos do EKS para associações de identidade de pods

Os complementos do EKS também oferecem suporte ao recebimento de permissões do IAM por meio do EKS Pod Identity Associations. O arquivo de configuração expõe três campos que permitem configurá-los: e. addon.podIdentityAssociations addonsConfig.autoApplyPodIdentityAssociations addon.useDefaultPodIdentityAssociations Você pode configurar explicitamente as associações de identidade de pod desejadasaddon.podIdentityAssociations, usando ou fazer com que resolva (e aplique) eksctl automaticamente a configuração de identidade de pod recomendada, usando addonsConfig.autoApplyPodIdentityAssociations ouaddon.useDefaultPodIdentityAssociations.

nota

Nem todos os complementos do EKS suportarão associações de identidade de pod no lançamento. Nesse caso, as permissões necessárias do IAM continuarão sendo fornecidas usando as configurações do IRSA.

Criação de complementos com permissões do IAM

Ao criar um complemento que exija permissões do IAM, primeiro eksctl verificará se as associações de identidade do pod ou as configurações do IRSA estão sendo configuradas explicitamente como parte do arquivo de configuração e, em caso afirmativo, use uma delas para configurar as permissões do complemento. por exemplo

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

e corra

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

Não é permitido definir as identidades do pod e do IRSA ao mesmo tempo e resultará em um erro de validação.

Para complementos do EKS que oferecem suporte a identidades de pods, eksctl oferece a opção de configurar automaticamente todas as permissões recomendadas do IAM, na criação do complemento. Isso pode ser feito simplesmente configurando o arquivo addonsConfig.autoApplyPodIdentityAssociations: true de configuração. por exemplo

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

e corra

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

Da mesma forma, o mesmo pode ser feito por meio de sinalizadores CLI, por exemplo

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

Para migrar um complemento existente para usar a identidade do pod com as políticas recomendadas do IAM, use

addons:
- name: vpc-cni
  useDefaultPodIdentityAssociations: true

eksctl update addon -f config.yaml

Atualização de complementos com permissões do IAM

Ao atualizar um complemento, a especificação addon.PodIdentityAssociations representará a única fonte confiável para o estado que o complemento deverá ter, após a conclusão da operação de atualização. Nos bastidores, diferentes tipos de operações são realizados para atingir o estado desejado, ou seja,

• criar identidades de pod que estão presentes no arquivo de configuração, mas ausentes no cluster

• exclua as identidades de pod existentes que foram removidas do arquivo de configuração, junto com quaisquer recursos do IAM associados

• atualize as identidades de pod existentes que também estão presentes no arquivo de configuração e para as quais o conjunto de permissões do IAM foi alterado

nota

O ciclo de vida das associações de identidade de pods pertencentes ao EKS Add-ons é gerenciado diretamente pela API EKS Addons.

Você não pode usar eksctl update podidentityassociation (para atualizar as permissões do IAM) ou eksctl delete podidentityassociations (para remover a associação) para associações usadas com um complemento do Amazon EKS. Em vez disso, eksctl update addon ou eksctl delete addon deve ser usado.

Vamos ver um exemplo acima, começando analisando a configuração inicial da identidade do pod para o 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"
    }
]

Agora use a configuração abaixo:

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

e corra

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

agora verifique se a configuração de identidade do pod foi atualizada corretamente

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 remover todas as associações de identidade de pod de um complemento, ele addon.PodIdentityAssociations deve ser definido explicitamente como, por exemplo []

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

e corra

eksctl update addon -f config.yaml

Excluindo complementos com permissões do IAM

A exclusão de um complemento também removerá todas as identidades do pod associadas ao complemento. A exclusão do cluster terá o mesmo efeito para todos os complementos. Todas as funções do IAM para identidades de pods, criadas poreksctl, também serão excluídas.

Migração de contas e complementos iamserviceaccounts existentes para associações de identidade de pod

Há um comando eksctl utils para migrar funções do IAM existentes para contas de serviço para associações de identidade de pod, ou seja,

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

Nos bastidores, o comando aplicará as seguintes etapas:

• instale o eks-pod-identity-agent complemento se ainda não estiver ativo no cluster

• identificar todas as funções do IAM associadas a iamserviceaccounts

• identifique todas as funções do IAM associadas aos complementos do EKS que oferecem suporte a associações de identidade de pod

• atualize a política de confiança do IAM de todas as funções identificadas, com uma entidade confiável adicional, apontando para o novo diretor do EKS Service (e, opcionalmente, remova a relação de confiança existente com o provedor do OIDC)

• criar associações de identidade de pod para funções filtradas associadas a iamserviceaccounts

• atualize os complementos do EKS com identidades do pod (a API do EKS criará as identidades do pod nos bastidores)

Executar o comando sem o --approve sinalizador produzirá apenas um plano que consiste em um conjunto de tarefas que refletem as etapas acima, por exemplo

[ℹ]  (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

A relação de confiança existente com o provedor do OIDC está sempre sendo removida das funções do IAM associadas aos complementos do EKS. Além disso, para remover a relação de confiança existente do provedor OIDC das funções do IAM associadas a iamserviceaccounts, execute o comando com flag, por exemplo --remove-oidc-provider-trust-relationship

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

Referências adicionais

Suporte oficial de complementos do AWS Userdocs for EKS para identidades de pods

Publicação oficial do blog da AWS sobre associações de identidade de pods

Documentos de usuário oficiais da AWS para associações de identidade de pods