As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# 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](iamserviceaccounts.md#iam-how-works) 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 sempre 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 com`eksctl`) 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.
```
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 abaixo`iam.podIdentityAssociations`, por exemplo
```
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
```
Para ver um exemplo completo, consulte [pod-identity-associations.yaml.](https://github.com/eksctl-io/eksctl/blob/main/examples/39-pod-identity-association.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 desejadas`addon.podIdentityAssociations`, usando ou fazer com que resolva (e aplique) `eksctl` automaticamente a configuração de identidade de pod recomendada, usando `addonsConfig.autoApplyPodIdentityAssociations` ou`addon.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](addons.md#addons-create).
### 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 suportam identidades de pod, `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 de pods 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 por`eksctl`, 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
```
## Cross Account Pod Identity Support
O eksctl suporta o acesso [entre contas do EKS Pod Identity](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html). Esse recurso permite que pods executados em seu cluster EKS acessem recursos da AWS em uma conta diferente da AWS.
### Usage
Para criar uma associação de identidade de pod com acesso entre contas, primeiro configure as funções e políticas do IAM que permitam o acesso de uma conta de origem da AWS (com o cluster) a uma conta da AWS de destino (com os recursos que o cluster pode acessar). Para ver um exemplo disso, consulte [“O Amazon EKS Pod Identity simplifica o acesso entre contas”.](https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-streamlines-cross-account-access/)
Depois que uma função do IAM estiver configurada em cada conta, use eksctl para criar as associações de identidade do 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
```
## Referências adicionais
[Suporte oficial de complementos do AWS Userdocs for EKS para identidades de pods](https://docs.aws.amazon.com/eks/latest/userguide/add-ons-iam.html)
[Publicação oficial do blog da AWS sobre associações de identidade de pods](https://aws.amazon.com/blogs/aws/amazon-eks-pod-identity-simplifies-iam-permissions-for-applications-on-amazon-eks-clusters/)
[Documentos de usuário oficiais da AWS para associações de identidade de pods](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html)