**Ajudar a melhorar esta página**
Para contribuir com este guia de usuário, escolha o link **Editar esta página no GitHub**, disponível no painel direito de cada página.
# Saiba como o controle de acesso funciona no Amazon EKS
Saiba como gerenciar o acesso ao seu cluster do Amazon EKS. O uso do Amazon EKS exige o conhecimento de como o Kubernetes e o AWS Identity and Access Management (AWS IAM) lidam com o controle de acesso.
**Esta seção inclui:**
** [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md) **: saiba como permitir que aplicações ou usuários se autentiquem na API do Kubernetes. É possível usar entradas de acesso, o aws-auth ConfigMap ou um provedor de OIDC externo.
** [Visualize os recursos do Kubernetes na seção Console de gerenciamento da AWS](view-kubernetes-resources.md) **: saiba como configurar o Console de gerenciamento da AWS para se comunicar com o cluster do Amazon EKS. Use o console para visualizar os recursos do Kubernetes no cluster, como namespaces, nós e pods.
** [Concessão de acesso de gravação às APIs do Kubernetes pra serviços da AWS](mutate-kubernetes-resources.md) **: saiba mais sobre as permissões obrigatórias para modificar os recursos do Kubernetes.
** [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md) ** — saiba como configurar o kubectl para se comunicar com o cluster do Amazon EKS. Use a AWS CLI para criar um arquivo kubeconfig.
** [Conceder às workloads do Kubernetes acesso a AWS usando contas de serviço do Kubernetes](service-accounts.md) **: saiba como associar uma conta de serviço do Kubernetes a perfis do AWS IAM. É possível usar a Identidade de Pods ou perfis do IAM para contas de serviço (IRSA).
## Tarefas comuns
+ Conceda aos desenvolvedores acesso à API do Kubernetes. Visualize os recursos do Kubernetes no Console de gerenciamento da AWS.
+ Solução: [use entradas de acesso](access-entries.md) para associar permissões RBAC do Kubernetes a usuários ou perfis do AWS IAM.
+ Configure o kubectl para se comunicar com um cluster do Amazon EKS usando credenciais da AWS.
+ Solução: usar a AWS CLI para [criar um arquivo kubeconfig](create-kubeconfig.md).
+ Use um provedor de identidade externo, como o Ping Identity, para autenticar usuários na API do Kubernetes.
+ Solução: [vincule um provedor de OIDC externo](authenticate-oidc-identity-provider.md).
+ Conceda às workloads no cluster do Kubernetes a capacidade de chamar APIs da AWS.
+ Solução: [use a Identidade de Pods](pod-identities.md) para associar um perfil do AWS IAM a uma conta de serviço do Kubernetes.
## Contexto
+ [Saiba como as contas de serviço do Kubernetes funcionam.](https://kubernetes.io/docs/concepts/security/service-accounts/)
+ [Analise o modelo de controle de acesso baseado em perfil (RBAC) do Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
+ Para obter mais informações sobre como gerenciar o acesso a recursos da AWS, consulte o [Guia do usuário do AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/intro-structure.html). Como alternativa, faça um [treinamento introdutório gratuito sobre o uso do AWS IAM](https://explore.skillbuilder.aws/learn/course/external/view/elearning/120/introduction-to-aws-identity-and-access-management-iam).
## Considerações para o Modo Automático do EKS
O Modo Automático do EKS se integra à Identidade de Pods do EKS e às entradas de acesso ao EKS.
+ O Modo Automático do EKS usa entradas de acesso para conceder permissões ao Kubernetes ao ambiente de gerenciamento do EKS. Por exemplo, as políticas de acesso permitem que o Modo Automático do EKS leia informações sobre endpoints e serviços de rede.
+ Você não pode desabilitar as entradas de acesso em um cluster do Modo Automático do EKS.
+ Opcionalmente, você pode habilitar o `ConfigMap` `aws-auth`.
+ As entradas de acesso para o Modo Automático do EKS são configuradas automaticamente. É possível visualizar essas entradas de acesso, mas não pode modificá-las.
+ Caso use um NodeClass para criar um perfil do IAM de nós personalizado, você precisará criar uma entrada de acesso para o perfil usando a política de acesso AmazonEKSAutoNodePolicy.
+ Caso queira conceder permissões de workloads para os serviços da AWS, use a Identidade de Pods do EKS.
+ Não é necessário instalar o agente da Identidade de Pods nos clusters do Modo Automático do EKS.
# Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes
O cluster tem um endpoint de API do Kubernetes. O Kubectl usa essa API. Você pode se autenticar nessa API usando dois tipos de identidades:
+ **Uma *entidade principal* (perfil ou usuário) do AWS Identity and Access Management (IAM)**: esse tipo requer autenticação no IAM. Os usuários podem fazer login na AWS como um usuário do [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) ou com uma [identidade](https://aws.amazon.com/identity/federation/) federada ao usar credenciais fornecidas por meio de uma fonte de identidades. Os usuários só poderão fazer login com uma identidade federada se o administrador tiver configurado a federação de identidades anteriormente usando perfis do IAM. Quando os usuários acessam a AWS usando a federação, estão indiretamente [assumindo um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/when-to-use-iam.html#security-iam-authentication-iamrole). Quando os usuários usam esse tipo de identidade, você:
+ Pode atribuir permissões do Kubernetes a eles para que possam trabalhar com objetos do Kubernetes no cluster. Para obter mais informações sobre como atribuir permissões às entidades principais do IAM para que elas possam acessar objetos do Kubernetes no seu cluster, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
+ Pode atribuir a eles permissões de IAM para que possam trabalhar com seu cluster do Amazon EKS e seus recursos usando a API do Amazon EKS, AWS CLI, AWS CloudFormation, Console de gerenciamento da AWS ou `eksctl`. Para obter mais informações, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) na Referência de autorização do serviço.
+ Os nós se juntam ao seu cluster assumindo um perfil do IAM. A capacidade de acessar seu cluster usando princípios de IAM é fornecida pelo [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), que é executado no ambiente de gerenciamento do Amazon EKS.
+ **Um usuário em seu próprio provedor OpenID Connect (OIDC)**: este tipo requer autenticação em seu provedor [OIDC](https://openid.net/connect/). Para obter mais informações sobre como configurar o seu próprio provedor OIDC com o cluster do Amazon EKS, consulte [Conceder aos usuários acesso ao Kubernetes com um provedor OIDC externo](authenticate-oidc-identity-provider.md). Quando os usuários usam esse tipo de identidade, você:
+ Pode atribuir permissões do Kubernetes a eles para que possam trabalhar com objetos do Kubernetes no cluster.
+ Não é possível atribuir a eles permissões de IAM para que possam trabalhar com seu cluster do Amazon EKS e seus recursos usando a API do Amazon EKS, AWS CLI, AWS CloudFormation, Console de gerenciamento da AWS ou `eksctl`.
Você pode usar os dois tipos de identidades com seu cluster. Não é possível desabilitar o método de autenticação do IAM. O método de autenticação OIDC é opcional.
## Associe identidades do IAM a permissões do Kubernetes
O [Autenticador AWS IAM para Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) está instalado no ambiente de gerenciamento do seu cluster. Ele habilita as entidades principais (perfis e usuários) do [AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) (IAM) que você permite acessar os recursos do Kubernetes no seu cluster. É possível permitir que entidades principais do IAM acessem objetos do Kubernetes no seu cluster usando um dos seguintes métodos:
+ **Criação de entradas de acesso**: se o cluster for igual ou posterior à versão da plataforma listada na seção [Pré-requisitos](access-entries.md) da versão do Kubernetes do cluster, recomendamos que você use essa opção.
Use *entradas de acesso* para gerenciar as permissões do Kubernetes das entidades principais do IAM de fora do cluster. Você pode adicionar e gerenciar o acesso ao cluster usando a API do EKS, a interface de linha de comando AWS, os SDKs AWS, o AWS CloudFormation e o Console de gerenciamento da AWS. Isso significa que você pode gerenciar usuários com as mesmas ferramentas com as quais criou o cluster.
Para começar, siga as instruções em [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md) e, em seguida, [Migrar entradas existentes do ConfigMap aws-auth para entradas de acesso](migrating-access-entries.md).
+ **Adicionar entradas ao `ConfigMap` `aws-auth`**: se a versão da plataforma do cluster for anterior à versão listada na seção [Pré-requisitos](access-entries.md), você deverá usar esta opção. Se a versão da plataforma do cluster for igual ou posterior à versão da plataforma listada na seção [Pré-requisitos](access-entries.md) da versão do Kubernetes do cluster e você tiver adicionado entradas ao `ConfigMap`, recomendamos que migre essas entradas para entradas de acesso. No entanto, você não pode migrar entradas que o Amazon EKS adicionou ao `ConfigMap`, como entradas para perfis do IAM usadas com grupos de nós gerenciados ou perfis do Fargate. Para obter mais informações, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](#grant-k8s-access).
+ Caso precise usar a opção do `aws-auth` `ConfigMap`, você poderá adicionar entradas ao `ConfigMap` usando o comando `eksctl create iamidentitymapping`. Para obter mais informações, consulte [Gerenciar usuários e perfis do IAM](https://eksctl.io/usage/iam-identity-mappings/) na documentação do `eksctl`.
## Definir modo de autenticação do cluster
Cada cluster tem um *modo de autenticação*. O modo de autenticação determina quais métodos você pode usar para permitir que as entidades principais do IAM acessem os objetos do Kubernetes no seu cluster. Existem três modos de autenticação.
**Importante**
Depois que o método de entrada de acesso estiver habilitado, ele não poderá ser desabilitado.
Se o método `ConfigMap` não for habilitado durante a criação do cluster, ele não poderá ser habilitado posteriormente. Todos os clusters criados antes da introdução das entradas de acesso têm o método `ConfigMap` habilitado.
Caso esteja usando nós híbridos com o cluster, você deverá usar os modos de autenticação de `API` ou `API_AND_CONFIG_MAP` do cluster.
**O`aws-auth` `ConfigMap` dentro do cluster**
Este é o modo de autenticação original para clusters do Amazon EKS. A entidade principal do IAM que criou o cluster é o usuário inicial que pode acessar o cluster usando `kubectl`. O usuário inicial deve adicionar outros usuários à lista no `aws-auth` `ConfigMap` e atribuir permissões que afetem os outros usuários dentro do cluster. Os outros usuários não podem gerenciar nem remover o usuário inicial, pois não há uma entrada no `ConfigMap` para gerenciar.
**Tanto as entradas do `ConfigMap` quanto as de acesso**
Com este modo de autenticação, é possível usar os dois métodos para adicionar entidades principais do IAM ao cluster. Observe que cada método armazena entradas separadas; por exemplo, se você adicionar uma entrada de acesso pela AWS CLI, o `aws-auth` `ConfigMap` não será atualizado.
**Somente entradas de acesso**
Com esse modo de autenticação, você pode usar a API do EKS, a AWS Command Line Interface, SDKs AWS, o AWS CloudFormation e o Console de gerenciamento da AWS para gerenciar o acesso ao cluster para as entidades principais do IAM.
Cada entrada de acesso tem um *tipo* e você pode usar a combinação de um *escopo de acesso* para limitar a entidade principal a um namespace específico e uma *política de acesso* para definir políticas de permissões reutilizáveis pré-configuradas. Como alternativa, você pode usar o tipo STANDARD e grupos de RBAC do Kubernetes para atribuir permissões personalizadas.
| Modos de autenticação | Métodos |
| --- | --- |
| Somente `ConfigMap` (`CONFIG_MAP`) | `aws-auth` `ConfigMap` |
| API do EKS e `ConfigMap` (`API_AND_CONFIG_MAP`) | entradas de acesso na API do EKS, na interface de linha de comando AWS, nos SDKs da AWS, no AWS CloudFormation e no Console de gerenciamento da AWS e `aws-auth` `ConfigMap` |
| Somente API do EKS (`API`) | entradas de acesso na API do EKS, na interface de linha de comando AWS, nos SDKs da AWS, no AWS CloudFormation e no Console de gerenciamento da AWS |
**nota**
O Modo Automático do Amazon EKS requer entradas de acesso.
# Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS
Esta seção foi criada para mostrar como gerenciar o acesso de entidades principais do IAM aos clusters do Kubernetes no Amazon Elastic Kubernetes Service (EKS) usando entradas e políticas de acesso. Você encontrará detalhes sobre como alterar os modos de autenticação, migrar a partir de entradas legadas ConfigMap do `aws-auth`, criar, atualizar e excluir entradas de acesso, associar políticas a entradas, revisar permissões de políticas predefinidas e os principais pré-requisitos e considerações para o gerenciamento seguro de acesso.
## Visão geral
As entradas de acesso do EKS são a maneira mais eficiente de conceder aos usuários o acesso à API do Kubernetes. Por exemplo, você pode usar as entradas de acesso para conceder aos desenvolvedores acesso para usar o kubectl. De maneira geral, uma entrada de acesso do EKS associa um conjunto de permissões do Kubernetes com uma identidade do IAM, como um perfil do IAM. Por exemplo, um desenvolvedor pode assumir um perfil do IAM e usá-lo para se autenticar em um cluster do EKS.
## Atributos
+ **Autenticação e autorização centralizadas**: controla o acesso aos clusters do Kubernetes diretamente por meio das APIs do Amazon EKS, eliminando a necessidade de alternar entre as APIs da AWS e as do Kubernetes para obter permissões de usuário.
+ **Gerencimento granular de permissões**: usa entradas e políticas de acesso para definir permissões granulares para as entidades principais do AWS IAM, incluindo a capacidade de modificar ou de revogar o acesso de administrador de cluster do criador.
+ **Ferramenta de integração de IaC**: oferece suporte a ferramentas de infraestrutura como código como o AWS CloudFormation, o Terraform e o AWS CDK para definir configurações de acesso durante a criação do cluster.
+ **Recuperação de erros de configuração**: permite restaurar o acesso ao cluster por meio da API do Amazon EKS, sem acesso direto à API do Kubernetes.
+ **Sobrecarga reduzida e segurança aprimorada**: centraliza as operações para reduzir a sobrecarga ao aproveitar as funcionalidades do AWS IAM, como o registro em log da auditoria do CloudTrail e a autenticação multifator.
## Como anexar permissões
Você pode conceder permissões do Kubernetes às entradas de acesso de duas maneiras:
+ Use uma política de acesso. As políticas de acesso são modelos de permissões do Kubernetes definidos previamente e mantidos pela AWS. Para obter mais informações, consulte [Analisar permissões da política de acesso](access-policy-permissions.md).
+ Referencie um grupo do Kubernetes. Se você associar uma identidade do IAM a um grupo do Kubernetes, será possível criar recursos do Kubernetes que concedem permissões ao grupo. Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
## Considerações
Ao habilitar entradas de acesso ao EKS em clusters existentes, lembre-se do seguinte:
+ **Comportamento de cluster legado**: para clusters criados antes da introdução de entradas de acesso (aqueles com versões iniciais da plataforma anteriores às especificadas nos [Requisitos de versão da plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html)), o EKS cria automaticamente uma entrada de acesso refletindo permissões preexistentes. Essa entrada inclui a identidade do IAM que criou originalmente o cluster e as permissões administrativas concedidas a essa identidade durante a criação do cluster.
+ **Manipulação do ConfigMap do `aws-auth` legado**: se seu cluster dopende do ConfigMap do `aws-auth` legado para gerenciamento de acesso, somente a entrada de acesso do criador original do cluster é criada automaticamente ao habilitar as entradas de acesso. Perfis ou permissões adicionais adicionadas ao ConfigMap (por exemplo, perfis do IAM personalizados para desenvolvedores ou serviços) não são migradas automaticamente. Para resolver isso, crie manualmente as entradas de acesso correspondentes.
## Conceitos básicos
1. Determine a identidade do IAM e a política de acesso que você deseja usar.
+ [Analisar permissões da política de acesso](access-policy-permissions.md)
1. Habilite as entradas de acesso do EKS no seu cluster. Confirme se você tem uma versão da plataforma compatível.
+ [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md)
1. Crie uma entrada de acesso que associe uma identidade do IAM com permissões do Kubernetes.
+ [Criar entradas de acesso](creating-access-entries.md)
1. Faça a autenticação do cluster com a identidade do IAM.
+ [Configurar a AWS CLI](install-awscli.md)
+ [Configurar o `kubectl` e o `eksctl`](install-kubectl.md)
# Associar políticas de acesso a entradas de acesso
Você pode atribuir uma ou mais políticas de acesso para *acessar entradas* do *tipo* `STANDARD`. O Amazon EKS concede automaticamente aos outros tipos de entradas de acesso as permissões necessárias para funcionar adequadamente em seu cluster. As políticas de acesso do Amazon EKS incluem permissões do Kubernetes, não permissões do IAM. Antes de associar uma política de acesso a uma entrada de acesso, familiarize-se com as permissões do Kubernetes incluídas em cada política de acesso. Para ter mais informações, consulte [Analisar permissões da política de acesso](access-policy-permissions.md). Se nenhuma das políticas de acesso atender aos seus requisitos, não associe uma política de acesso a uma entrada de acesso. Em vez disso, especifique um ou mais *nomes de grupos* para a entrada de acesso e crie e gerencie objetos de controle de acesso baseado em perfil do Kubernetes. Para ter mais informações, consulte [Criar entradas de acesso](creating-access-entries.md).
+ Uma entrada de acesso existente. Para criar uma, consulte [Criar entradas de acesso](creating-access-entries.md).
+ Um perfil ou usuário do AWS Identity and Access Management com as seguintes permissões: `ListAccessEntries`, `DescribeAccessEntry`, `UpdateAccessEntry`, `ListAccessPolicies`, `AssociateAccessPolicy`, e `DisassociateAccessPolicy`. Para obter mais informações, consulte [Actions defined by Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) na *Referência de autorização do serviço*.
Antes de associar políticas de acesso às entradas de acesso, considere os seguintes requisitos:
+ Você pode associar várias políticas de acesso a cada entrada de acesso, mas só pode associar cada política a uma entrada de acesso uma vez. Se você associar várias políticas de acesso, a entidade principal do IAM da entrada de acesso tem todas as permissões incluídas em todas as políticas de acesso associadas.
+ Você pode definir o escopo de uma política de acesso para todos os recursos em um cluster ou especificando o nome de um ou mais namespaces do Kubernetes. Você pode usar caracteres curinga para o nome de um namespace. Por exemplo, se você quiser definir o escopo de uma política de acesso para todos os namespaces que começam com `dev-`, você pode especificar `dev-*` como um nome de namespace. Verifique se os namespaces existem no cluster e se a ortografia corresponde ao nome real do namespace no cluster. O Amazon EKS não confirma a ortografia nem a existência dos namespaces no seu cluster.
+ Você pode alterar o *escopo de acesso* de uma política de acesso depois de associá-la a uma entrada de acesso. Caso tenha definido o escopo da política de acesso para namespaces do Kubernetes, você pode adicionar e remover namespaces da associação, conforme necessário.
+ Se você associar uma política de acesso a uma entrada de acesso que também tenha *nomes de grupos* especificados, a entidade principal do IAM terá todas as permissões em todas as políticas de acesso associadas. Ela também tem todas as permissões em qualquer objeto `Role` ou `ClusterRole` do Kubernetes especificado em qualquer objeto `Role` ou `RoleBinding` do Kubernetes que especifica os nomes dos grupos.
+ Caso execute o comando `kubectl auth can-i --list`, você não verá nenhuma permissão do Kubernetes atribuída pelas políticas de acesso associadas a uma entrada de acesso para a entidade principal do IAM que você está usando ao executar o comando. O comando só mostrará as permissões do Kubernetes se você as tiver concedido em objetos `Role` ou `ClusterRole` do Kubernetes vinculados aos nomes de grupo ou ao nome de usuário que você especificou para uma entrada de acesso.
+ Se você representar um usuário ou grupo do Kubernetes ao interagir com objetos do Kubernetes no cluster, como usar o comando `kubectl` com `--as username ` ou `--as-group group-name `, você estará forçando o uso da autorização RBAC do Kubernetes. Como resultado, a entidade principal do IAM não tem permissões atribuídas por nenhuma política de acesso associada à entrada de acesso. As únicas permissões do Kubernetes que o usuário ou grupo que a entidade principal do IAM está representando tem são as permissões do Kubernetes que você concedeu a eles em objetos `Role` ou `ClusterRole` do Kubernetes que você vinculou aos nomes do grupo ou do usuário. Para que a entidade principal do IAM tenha as permissões nas políticas de acesso associadas, não represente um usuário ou grupo do Kubernetes. A entidade principal do IAM ainda terá todas as permissões que você concedeu a ela nos objetos `Role` ou `ClusterRole` do Kubernetes que você vinculou aos nomes dos grupos ou do usuário que você especificou para a entrada de acesso. Para obter mais informações, consulte [Personificação de usuário](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation) na documentação do Kubernetes.
Você pode associar uma política de acesso a uma entrada de acesso usando o Console de gerenciamento da AWS ou a AWS CLI.
## Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster que tem uma entrada de acesso à qual você deseja associar uma política de acesso.
1. Escolha a guia **Acesso**.
1. Se o tipo da entrada de acesso for **Padrão**, você poderá associar ou desassociar as **políticas de acesso** do Amazon EKS. Se o tipo da sua entrada de acesso for diferente de **Padrão**, essa opção não estará disponível.
1. Escolha **Associar política de acesso**.
1. Em **Nome da política**, selecione a política com as permissões que você deseja que a entidade principal do IAM tenha.. Para visualizar as permissões incluídas em cada política, consulte [Analisar permissões da política de acesso](access-policy-permissions.md).
1. Em **Escopo de acesso**, escolha um escopo de acesso. Se você escolher **Cluster**, as permissões na política de acesso serão concedidas à entidade principal do IAM para recursos em todos os namespaces do Kubernetes. Se você escolher **Namespace do Kubernetes**, poderá então escolher **Adicionar novo namespace**. No campo **Namespace** exibido, você pode inserir o nome de um namespace do Kubernetes no cluster. Se quiser que a entidade principal do IAM tenha as permissões em vários namespaces, você pode inserir vários namespaces.
1. Escolha **Adicionar política de acesso**.
## AWS CLI
1. Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
1. Visualize as políticas de acesso disponíveis.
```
aws eks list-access-policies --output table
```
Veja um exemplo de saída abaixo.
```
---------------------------------------------------------------------------------------------------------
| ListAccessPolicies |
+-------------------------------------------------------------------------------------------------------+
|| accessPolicies ||
|+---------------------------------------------------------------------+-------------------------------+|
|| arn | name ||
|+---------------------------------------------------------------------+-------------------------------+|
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSAdminPolicy | AmazonEKSAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy | AmazonEKSClusterAdminPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSEditPolicy | AmazonEKSEditPolicy ||
|| {arn-aws}eks::aws:cluster-access-policy/AmazonEKSViewPolicy | AmazonEKSViewPolicy ||
|+---------------------------------------------------------------------+-------------------------------+|
```
Para visualizar as permissões incluídas em cada política, consulte [Analisar permissões da política de acesso](access-policy-permissions.md).
1. Visualize suas entradas de acesso existentes. Substitua *my-cluster* pelo nome do cluster.
```
aws eks list-access-entries --cluster-name my-cluster
```
Veja um exemplo de saída abaixo.
```
{
"accessEntries": [
"arn:aws:iam::111122223333:role/my-role",
"arn:aws:iam::111122223333:user/my-user"
]
}
```
1. Associe uma política de acesso a uma entrada de acesso. O exemplo a seguir associa a política de acesso do `AmazonEKSViewPolicy` a uma entrada de acesso. Sempre que o perfil do IAM *my-role* tentar acessar objetos do Kubernetes no cluster, o Amazon EKS autorizará o perfil a usar as permissões na política para acessar os objetos do Kubernetes somente nos namespaces *my-namespace1* e *my-namespace2* do Kubernetes. Substitua *my-cluster* pelo nome do cluster, *111122223333* pelo ID da conta AWS e *my-role* pelo nome do perfil do IAM para o qual você deseja que o Amazon EKS autorize o acesso aos objetos do cluster do Kubernetes.
```
aws eks associate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy
```
Se você quiser que a entidade principal do IAM tenha as permissões em todo o cluster, substitua `type=namespace,namespaces=my-namespace1,my-namespace2 ` por `type=cluster`. Se você quiser associar várias políticas de acesso à entrada de acesso, execute o comando várias vezes, cada uma com uma política de acesso exclusiva. Cada política de acesso associada tem seu próprio escopo.
**nota**
Se você quiser alterar posteriormente o escopo de uma política de acesso associada, execute o comando anterior novamente com o novo escopo. Por exemplo, se você quisesse remover *my-namespace2*, executaria o comando novamente usando somente `type=namespace,namespaces=my-namespace1 `. Se você quisesse alterar o escopo de `namespace` para `cluster`, executaria o comando novamente usando `type=cluster`, removendo `type=namespace,namespaces=my-namespace1,my-namespace2 `.
1. Determine quais políticas de acesso estão associadas a uma entrada de acesso.
```
aws eks list-associated-access-policies --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
Veja um exemplo de saída abaixo.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333",
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2023-04-17T15:25:21.675000-04:00",
"modifiedAt": "2023-04-17T15:25:21.675000-04:00"
},
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy",
"accessScope": {
"type": "namespace",
"namespaces": [
"my-namespace1",
"my-namespace2"
]
},
"associatedAt": "2023-04-17T15:02:06.511000-04:00",
"modifiedAt": "2023-04-17T15:02:06.511000-04:00"
}
]
}
```
No exemplo anterior, a entidade principal do IAM para essa entrada de acesso tem permissões de visualização em todos os namespaces no cluster e permissões de administrador em dois namespaces do Kubernetes.
1. Desassocie uma política de acesso de uma entrada de acesso. Neste exemplo, a política `AmazonEKSAdminPolicy` é desassociada de uma entrada de acesso. No entanto, a entidade principal do IAM retém as permissões na política de acesso `AmazonEKSViewPolicy` para objetos nos namespaces *my-namespace1* e *my-namespace2* porque essa política de acesso não está dissociada da entrada de acesso.
```
aws eks disassociate-access-policy --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy
```
Para listar as políticas de acesso disponíveis, consulte [Analisar permissões da política de acesso](access-policy-permissions.md).
# Migrando entradas existentes `aws-auth ConfigMap` para entradas de acesso
Se você adicionou entradas ao `ConfigMap` `aws-auth` no seu cluster, recomendamos que você crie entradas de acesso para as entradas existentes no seu `ConfigMap` `aws-auth`. Depois de criar as entradas de acesso, você pode remover as entradas do seu `ConfigMap`. Você não pode associar [políticas de acesso](access-policies.md) às entradas no `ConfigMap` `aws-auth`. Se você quiser associar políticas de acesso às entidades principais do IAM, crie entradas de acesso.
**Importante**
Quando um cluster está no modo de autenticação `API_AND_CONFIGMAP` e há um mapeamento para o mesmo perfil do IAM tanto no `ConfigMap` `aws-auth` como nas entradas de acesso, o perfil usará o mapeamento da entrada de acesso para autenticação. As entradas de acesso têm precedência sobre as entradas do `ConfigMap` do mesmo principal do IAM.
Antes de remover as entradas do `ConfigMap` `aws-auth` existentes que foram criadas pelo Amazon EKS para um [grupo de nós gerenciados](managed-node-groups.md) ou um [perfil do Fargate](fargate-profile.md) no cluster, verifique se as entradas de acesso corretas para esses recursos específicos existem no cluster do Amazon EKS. Se você remover as entradas que o Amazon EKS criou no `ConfigMap` sem ter as entradas de acesso equivalentes, seu cluster não funcionará corretamente.
## Pré-requisitos
+ Familiaridade com entradas de acesso e políticas de acesso. Para obter mais informações, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md) e [Associar políticas de acesso a entradas de acesso](access-policies.md).
+ Um cluster existente com uma versão da plataforma igual ou posterior às versões listadas nos pré-requisitos do tópico [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
+ Versão `0.215.0` ou posterior da ferramenta de linha de comando da `eksctl` instalada no seu dispositivo ou AWS CloudShell. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
+ Permissões do Kubernetes para modificar o `ConfigMap` `aws-auth` no namespace do `kube-system`.
+ Um perfil ou usuário do AWS Identity and Access Management com as seguintes permissões: `CreateAccessEntry` e `ListAccessEntries`. Para obter mais informações, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) na Referência de autorização do serviço.
## `eksctl`
1. Veja as entradas existentes em seu `aws-auth ConfigMap`. Substitua *my-cluster* pelo nome do cluster.
```
eksctl get iamidentitymapping --cluster my-cluster
```
Veja abaixo um exemplo de saída.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/EKS-my-cluster-Admins Admins system:masters
arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers my-namespace-Viewers Viewers
arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:user/my-user my-user
arn:aws:iam::111122223333:role/EKS-my-cluster-fargateprofile1 system:node:{{SessionName}} system:bootstrappers,system:nodes,system:node-proxier
arn:aws:iam::111122223333:role/EKS-my-cluster-managed-ng system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. [Criar entradas de acesso](creating-access-entries.md) para qualquer uma das entradas do `ConfigMap` que você criou retornadas na saída anterior. Ao criar as entradas de acesso, verifique se você especificou os mesmos valores para`ARN`, `USERNAME`, `GROUPS` e `ACCOUNT` retornados em sua saída. No exemplo de saída, você criaria entradas de acesso para todas as entradas, exceto as duas últimas, já que essas entradas foram criadas pelo Amazon EKS para um perfil do Fargate e um grupo de nós gerenciados.
1. Exclua as entradas do `ConfigMap` para todas as entradas de acesso que você criou. Se você não excluir a entrada do `ConfigMap`, as configurações da entrada de acesso do ARN principal do IAM substituirão a entrada do `ConfigMap`. Substitua *111122223333* pelo seu ID de conta AWS e *EKS-my-cluster-my-namespace-Viewers* pelo nome do perfil na entrada em seu `ConfigMap`. Se a entrada que você está removendo for para um usuário do IAM, em vez de um perfil do IAM, substitua `role` por `user` e *EKS-my-cluster-my-namespace-Viewers* pelo nome do usuário.
```
eksctl delete iamidentitymapping --arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --cluster my-cluster
```
# Analisar permissões da política de acesso
As políticas de acesso incluem `rules` que contêm `verbs` (permissões) e `resources` do Kubernetes. As políticas de acesso não incluem permissões ou recursos do IAM. Semelhantes aos objetos `Role` e `ClusterRole` do Kubernetes, as políticas de acesso incluem apenas `rules` de `allow`. Não é possível modificar o conteúdo de uma política de acesso. Você não pode criar suas próprias políticas de acesso. Se as permissões nas políticas de acesso não atenderem às suas necessidades, crie objetos RBAC do Kubernetes e especifique *nomes de grupos* para as entradas de acesso. Para obter mais informações, consulte [Criar entradas de acesso](creating-access-entries.md). As permissões contidas nas políticas de acesso são semelhantes às permissões nos perfis de clusters do Kubernetes voltados para o usuário. Para obter mais informações, consulte [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) na documentação do Kubernetes.
## Listagem de todas as políticas
Use qualquer uma das políticas de acesso listadas nesta página ou recupere uma lista de todas as políticas de acesso disponíveis usando a AWS CLI:
```
aws eks list-access-policies
```
A saída esperada deve ser semelhante a esta (abreviada por brevidade):
```
{
"accessPolicies": [
{
"name": "AmazonAIOpsAssistantPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonAIOpsAssistantPolicy"
},
{
"name": "AmazonARCRegionSwitchScalingPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonARCRegionSwitchScalingPolicy"
},
{
"name": "AmazonEKSAdminPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
},
{
"name": "AmazonEKSAdminViewPolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy"
},
{
"name": "AmazonEKSAutoNodePolicy",
"arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy"
}
// Additional policies omitted
]
}
```
## AmazonEKSAdminPolicy
Essa política de acesso inclui permissões que concedem à entidade principal do IAM a maioria das permissões aos recursos. Quando associada a uma entrada de acesso, seu escopo de acesso geralmente é um ou mais namespaces do Kubernetes. Se você quiser que uma entidade principal do IAM tenha acesso de administrador a todos os recursos do seu cluster, associe a política de acesso [AmazonEKSClusterAdminPolicy](#access-policy-permissions-amazoneksclusteradminpolicy) à sua entrada de acesso.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy`
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `authorization.k8s.io` | `localsubjectaccessreviews` | `create` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| `rbac.authorization.k8s.io` | `rolebindings`, `roles` | `create`, `delete`, `deletecollection`, `get`, `list`, `patch`, `update`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`,`list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `serviceaccounts` | `impersonate` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`,`list`, `watch` |
## AmazonEKSClusterAdminPolicy
Essa política de acesso inclui permissões que concedem ao administrador principal do IAM acesso a um cluster. Quando associada a uma entrada de acesso, seu escopo de acesso geralmente é o cluster, em vez de um namespace do Kubernetes. Se você quiser que uma entidade principal do IAM tenha um escopo administrativo mais limitado, considere associar a política de acesso [AmazonEKSAdminPolicy](#access-policy-permissions-amazoneksadminpolicy) à sua entrada de acesso.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy`
| Grupos de APIs Kubernetes | Kubernetes nonResourceURLs | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- | --- |
| `*` | | `*` | `*` |
| | `*` | | `*` |
## AmazonEKSAdminViewPolicy
Essa política de acesso inclui permissões que concedem a uma entidade principal do IAM acesso de listagem/visualização a todos os recursos em um cluster. Observe que isso inclui [Segredos do Kubernetes.](https://kubernetes.io/docs/concepts/configuration/secret/)
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminViewPolicy`
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `get`, `list`, `watch` |
## AmazonEKSEditPolicy
Essa política de acesso inclui permissões para que uma entidade principal do IAM edite a maioria dos recursos do Kubernetes.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy`
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `apps` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `replicasets`, `replicasets/scale`, `statefulsets`, `statefulsets/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `jobs` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `deployments`, `deployments/rollback`, `deployments/scale`, `ingresses`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicationcontrollers/scale` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `networkpolicies` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
| | `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy`, `secrets`, `services/proxy` | `get`, `list`, `watch` |
| | `serviceaccounts` | `impersonate` |
| | `pods`, `pods/attach`, `pods/exec`, `pods/portforward`, `pods/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `events`, `persistentvolumeclaims`, `replicationcontrollers`, `replicationcontrollers/scale`, `secrets`, `serviceaccounts`, `services`, `services/proxy` | `create`, `delete`, `deletecollection`, `patch`, `update` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, `resourcequotas/status` | `get`, `list`, `watch` |
## AmazonEKSViewPolicy
Essa política de acesso inclui permissões para que uma entidade principal do IAM visualize a maioria dos recursos do Kubernetes.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy`
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `apps` | `controllerrevisions`, `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `replicasets`, `replicasets/scale`, `replicasets/status`, `statefulsets`, `statefulsets/scale`, `statefulsets/status` | `get`, `list`, `watch` |
| `autoscaling` | `horizontalpodautoscalers`, `horizontalpodautoscalers/status` | `get`, `list`, `watch` |
| `batch` | `cronjobs`, `cronjobs/status`, `jobs`, `jobs/status` | `get`, `list`, `watch` |
| `discovery.k8s.io` | `endpointslices` | `get`, `list`, `watch` |
| `extensions` | `daemonsets`, `daemonsets/status`, `deployments`, `deployments/scale`, `deployments/status`, `ingresses`, `ingresses/status`, `networkpolicies`, `replicasets`, `replicasets/scale`, `replicasets/status`, `replicationcontrollers/scale` | `get`, `list`, `watch` |
| `networking.k8s.io` | `ingresses`, `ingresses/status`, `networkpolicies` | `get`, `list`, `watch` |
| `policy` | `poddisruptionbudgets`, `poddisruptionbudgets/status` | `get`, `list`, `watch` |
| | `configmaps`, `endpoints`, `persistentvolumeclaims`, `persistentvolumeclaims/status`, `pods`, `replicationcontrollers`, `replicationcontrollers/scale`, `serviceaccounts`, `services`, `services/status` | `get`, `list`, `watch` |
| | `bindings`, `events`, `limitranges`, `namespaces/status`, `pods/log`, `pods/status`, `replicationcontrollers/status`, `resourcequotas`, r`esourcequotas/status` | `get`, `list`, `watch` |
| | `namespaces` | `get`, `list`, `watch` |
## AmazonEKSSecretReaderPolicy
Esta política de acesso contém permissões que autorizam uma entidade principal do IAM a realizar a leitura do [Kubernetes Secrets](https://kubernetes.io/docs/concepts/configuration/secret/).
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSSecretReaderPolicy`
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| | `secrets` | `get`, `list`, `watch` |
## AmazonEKSAutoNodePolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy`
Esta política inclui as permissões abaixo, que permitem aos componentes do Amazon EKS concluir as seguintes tarefas:
+ `kube-proxy`: monitore endpoints e serviços de rede e gerencie eventos relacionados. Isso habilita a funcionalidade de proxy de rede em todo o cluster.
+ `ipamd`: gerencie recursos de rede da AWS VPC e interfaces de rede de contêineres (CNI). Isso permite que o daemon de gerenciamento de endereços IP lide com a rede de pods.
+ `coredns`: acesse recursos de descoberta de serviços, como endpoints e serviços. Isso permite a resolução de DNS no cluster.
+ `ebs-csi-driver`: trabalhe com recursos relacionados ao armazenamento de volumes do Amazon EBS. Isso permite o provisionamento dinâmico e a anexação de volumes persistentes.
+ `neuron`: monitore nós e pods de dispositivos do AWS Neuron. Isso permite o gerenciamento dos aceleradores AWS Inferentia e Trainium.
+ `node-monitoring-agent`: acesse diagnósticos e eventos de nós. Isso permite o monitoramento da integridade do cluster e a coleta de diagnósticos.
Cada componente usa uma conta de serviço dedicada e está restrito somente às permissões necessárias para sua função específica.
Se você especificar manualmente um perfil do IAM de nó em uma NodeClass, é necessário criar uma entrada de acesso que associe o novo perfil do IAM de nó a esta política de acesso.
## AmazonEKSBlockStoragePolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStoragePolicy`
Esta política inclui permissões que permitem que o Amazon EKS gerencie recursos de eleição do líder e coordenação de operações de armazenamento:
+ `coordination.k8s.io`: crie e gerencie objetos de concessão para a eleição do líder. Isso permite que os componentes de armazenamento do EKS coordenem suas atividades em todo o cluster por meio de um mecanismo de eleição do líder.
A política tem como escopo os recursos de concessão específicos usados pelos componentes de armazenamento do EKS para evitar o acesso conflitante a outros recursos de coordenação no cluster.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso do perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de armazenamento em blocos funcione adequadamente.
## AmazonEKSLoadBalancingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingPolicy`
Esta política inclui permissões que possibilitam ao Amazon EKS gerenciar recursos de eleição do líder para balanceamento de carga:
+ `coordination.k8s.io`: crie e gerencie objetos de concessão para a eleição do líder. Isso permite que os componentes de balanceamento de carga do EKS coordenem atividades em várias réplicas ao eleger um líder.
A política tem como escopo específico os recursos de concessão de balanceamento de carga para garantir a coordenação adequada e, ao mesmo tempo, impedir o acesso a outros recursos de concessão no cluster.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso para o perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de rede funcione adequadamente.
## AmazonEKSNetworkingPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingPolicy`
Esta política inclui permissões que possibilitam ao Amazon EKS gerenciar recursos de eleição do líder para redes:
+ `coordination.k8s.io`: crie e gerencie objetos de concessão para a eleição do líder. Isso permite que os componentes de rede do EKS coordenem as atividades de alocação de endereços IP ao eleger um líder.
A política tem como escopo específico os recursos de concessão de rede para garantir a coordenação adequada e, ao mesmo tempo, impedir o acesso a outros recursos de concessão no cluster.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso para o perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de rede funcione adequadamente.
## AmazonEKSComputePolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputePolicy`
Esta política inclui permissões que possibilitam ao Amazon EKS gerenciar recursos de eleição do líder para operações de computação:
+ `coordination.k8s.io`: crie e gerencie objetos de concessão para a eleição do líder. Isso permite que os componentes de computação do EKS coordenem as atividades de escalabilidade de nós ao eleger um líder.
A política tem como escopo específico os recursos de concessão de gerenciamento de computação, permitindo ao mesmo tempo acesso básico de leitura (`get`, `watch`) a todos os recursos de concessão no cluster.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso para o perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de rede funcione adequadamente.
## AmazonEKSBlockStorageClusterPolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSBlockStorageClusterPolicy`
Esta política concede as permissões necessárias para a capacidade de armazenamento em blocos do Modo Automático do Amazon EKS. Ela permite o gerenciamento eficiente dos recursos de armazenamento em blocos nos clusters do Amazon EKS. A política inclui as seguintes permissões:
Gerenciamento do driver CSI:
+ Criar, ler, atualizar e excluir drivers CSI, especificamente para armazenamento em blocos.
Gerenciamento de volumes:
+ Listar, observar, criar, atualizar, aplicar patch e excluir volumes persistentes.
+ Listar, observar e atualizar reivindicações de volumes persistentes.
+ Aplicar patch aos status de reivindicação de volumes persistentes.
Interação entre nós e pods:
+ Ler as informações do nó e do pod.
+ Gerenciar eventos relacionados às operações de armazenamento.
Classes e atributos de armazenamento:
+ Leia classes de armazenamento e nós CSI.
+ Leia as classes de atributos de volume.
Anexos de volume:
+ Liste, observe e modifique anexos de volume e seus status.
Operações de snapshots:
+ Gerencie snapshots de volume, conteúdo de snapshots e classes de snapshots.
+ Lide com operações de snapshots de grupos de volumes e recursos relacionados.
Essa política foi projetada para ser compatível com o gerenciamento abrangente de armazenamento em blocos nos clusters do Amazon EKS em execução no Modo Automático. Ela combina permissões de várias operações, incluindo provisionamento, anexação, redimensionamento e criação de snapshots de volumes de armazenamento em blocos.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso do perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de armazenamento em blocos funcione adequadamente.
## AmazonEKSComputeClusterPolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSComputeClusterPolicy`
Esta política concede as permissões necessárias para a capacidade de gerenciamento computacional do Modo Automático do Amazon EKS. Ela permite orquestração e escalabilidade eficientes de recursos computacionais nos clusters do Amazon EKS. A política inclui as seguintes permissões:
Gerenciamento de nós:
+ Criar, ler, atualizar, excluir e gerenciar o status de NodePools e NodeClaims.
+ Gerenciar NodeClasses, incluindo criação, modificação e exclusão.
Gerenciamento de recursos e programação:
+ Acesso de leitura a pods, nós, volumes persistentes, reivindicações de volumes persistentes, controladores de replicação e namespaces.
+ Acesso de leitura a classes de armazenamento, nós CSI e anexos de volumes.
+ Listar e observar implantações, conjuntos daemon, conjuntos de réplicas e conjuntos com estado.
+ Ler orçamentos de interrupção de pods.
Manipulação de eventos:
+ Criar, ler e gerenciar eventos de clusters.
Desprovisionamento de nós e remoção de pods:
+ Atualizar, aplicar patch e excluir nós.
+ Criar remoções de pods e excluí-los quando necessário.
Gerenciamento de definição de recursos personalizados (CRD):
+ Criar novos CRDs.
+ Gerencie CRDs específicos relacionados ao gerenciamento de nós (NodeClasses, NodePools, NodeClaims e NodeDiagnostics).
Esta política foi projetada para ser compatível com o gerenciamento computacional abrangente nos clusters do Amazon EKS em execução no Modo Automático. Ela combina permissões para várias operações, incluindo provisionamento de nós, programação, escalabilidade e otimização de recursos.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso do perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que a capacidade de gerenciamento de computação funcione adequadamente.
## AmazonEKSLoadBalancingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSLoadBalancingClusterPolicy`
Esta política concede as permissões necessárias para a capacidade de balanceamento de carga do Modo Automático do Amazon EKS. Ele permite o gerenciamento e a configuração eficientes dos recursos de balanceamento de carga nos clusters do Amazon EKS. A política inclui as seguintes permissões:
Gerenciamento de eventos e recursos:
+ Criar e aplicar patch a eventos.
+ Acesso de leitura a pods, nós, endpoints e namespaces.
+ Atualizar os status dos pods.
Gerenciamento de serviços e entradas:
+ Gerenciamento completo dos serviços e seus status.
+ Controle abrangente das entradas e seus status.
+ Acesso de leitura às fatias de endpoint e às classes de entrada.
Vinculações de grupos de destino:
+ Criar e modificar vinculações de grupos de destino e seus status.
+ Acesso de leitura aos parâmetros da classe de entrada.
Gerenciamento de definição de recursos personalizados (CRD):
+ Criar e ler todos os CRDs.
+ Gerenciamento específico dos CRDs targetgroupbindings.eks.amazonaws.com e ingressclassparams.eks.amazonaws.com.
Configuração do webhook:
+ Criar e ler configurações de webhook de mutação e validação.
+ Gerenciar a configuração eks-load-balancing-webhook.
Esta política foi projetada para ser compatível com o gerenciamento abrangente do balanceamento de carga nos clusters do Amazon EKS em execução no Modo Automático. Ela combina permissões para várias operações, incluindo exposição de serviços, roteamento de entradas e integração com serviços de balanceamento de carga da AWS.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso do perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que a capacidade de balanceamento de carga funcione adequadamente.
## AmazonEKSNetworkingClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSNetworkingClusterPolicy`
AmazonEKSNetworkingClusterPolicy
Esta política concede as permissões necessárias para a capacidade de rede do Modo Automático do Amazon EKS. Ele permite o gerenciamento e a configuração eficientes dos recursos de rede nos clusters do Amazon EKS. A política inclui as seguintes permissões:
Gerenciamento de nós e pods:
+ Ler o acesso aos NodeClasses e seus status.
+ Ler o acesso aos NodeClaims e seus status.
+ Acesso de leitura aos pods.
Gerenciamento de nós CNI:
+ Permissões de CNINodes e seus status, incluindo criar, ler, atualizar, excluir e aplicar patch.
Gerenciamento de definição de recursos personalizados (CRD):
+ Criar e ler todos os CRDs.
+ Gerenciamento específico (atualização, aplicação de patch, exclusão) do CRD cninodes.eks.amazonaws.com.
Gerenciamento de eventos:
+ Criar e aplicar patch a eventos.
Esta política foi projetada para ser compatível com o gerenciamento abrangente de redes nos clusters do Amazon EKS em execução no Modo Automático. Ela combina permissões para várias operações, incluindo configuração de rede de nós, gerenciamento de CNI (interface de rede de contêineres) e manipulação de recursos personalizados relacionados.
A política permite que os componentes de rede interajam com recursos relacionados a nós, gerenciem configurações de nós específicas da CNI e manipulem recursos personalizados essenciais para operações de rede no cluster.
O Amazon EKS cria automaticamente uma entrada de acesso com essa política de acesso para o perfil do IAM do cluster quando o Modo Automático está habilitado, garantindo que as permissões necessárias estejam em vigor para que o recurso de rede funcione adequadamente.
## AmazonEKSHybridPolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
Esta política de acesso inclui permissões que concedem ao EKS acesso aos nós de um cluster. Quando associada a uma entrada de acesso, seu escopo de acesso geralmente é o cluster, em vez de um namespace do Kubernetes. Esta política é usada pelo Amazon EKS Hybrid Nodes.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSHybridPolicy`
| Grupos de APIs Kubernetes | Kubernetes nonResourceURLs | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- | --- |
| `*` | | `nodes` | `list` |
## AmazonEKSClusterInsightsPolicy
**nota**
Essa política é designada somente para perfis vinculados a serviços da AWS e não pode ser usado com perfis gerenciados pelo cliente.
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterInsightsPolicy`
Esta política concede permissões somente leitura para a funcionalidade Amazon EKS Cluster Insights. A política inclui as seguintes permissões:
Acesso ao nó: - Listar e visualizar os nós do cluster - Ler as informações de status do nó
Acesso ao DaemonSet: - Acesso de leitura à configuração do kube-proxy
Esta política é gerenciada automaticamente pelo serviço do EKS para o Cluster Insights. Para obter mais informações, consulte [Prepare-se para as atualizações da versão e a solução de problemas de configurações incorretas do Kubernetes com insights do cluster](cluster-insights.md).
## AWSBackupFullAccessPolicyForBackup
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForBackup`
AWSBackupFullAccessPolicyForBackup
Esta política concede as permissões necessárias para que o AWS Backup gerencie e crie backups do cluster do EKS. Esta política inclui as seguintes permissões:
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `list`, `get` |
## AWSBackupFullAccessPolicyForRestore
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AWSBackupFullAccessPolicyForRestore`
AWSBackupFullAccessPolicyForRestore
Esta política concede as permissões necessárias para que o AWS Backup gerencie e restaure backups do cluster do EKS. Esta política inclui as seguintes permissões:
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `*` | `*` | `list`, `get`, `create` |
## AmazonEKSACKPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSACKPolicy`
Esta política concede as permissões necessárias para que a funcionalidade AWS Controllers for Kubernetes (ACK) gerencie recursos da AWS usando o Kubernetes. A política inclui as seguintes permissões:
Gerenciamento de recursos personalizados do ACK:
+ Permite acesso completo a todos os recursos personalizados dos serviços do ACK em mais de 50 serviços da AWS, como S3, RDS, DynamoDB, Lambda, EC2, entre outros.
+ Possibilita a criação, a leitura, a atualização e a exclusão de definições de recursos personalizados do ACK.
Acesso a namespaces:
+ Permite acesso de leitura a namespaces para organização de recursos.
Eleição do líder:
+ Possibilita a criação e a leitura de concessões de coordenação para eleição de líder.
+ Realiza a atualização e a exclusão de concessões específicas do controlador de serviço do ACK.
Gerenciamento de eventos:
+ Possibilita a criação e a aplicação de patches em eventos relacionados às operações do ACK.
Esta política foi projetada para oferecer suporte ao gerenciamento abrangente de recursos da AWS por meio das APIs do Kubernetes. O Amazon EKS cria automaticamente uma entrada de acesso com a presente política de acesso para o perfil do IAM da funcionalidade que você fornece quando a funcionalidade do ACK é criada.
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| | `namespaces` | `get`, `watch`, `list` |
| `services.k8s.aws`, `acm.services.k8s.aws`, `acmpca.services.k8s.aws`, `apigateway.services.k8s.aws`, `apigatewayv2.services.k8s.aws`, `applicationautoscaling.services.k8s.aws`, `athena.services.k8s.aws`, `bedrock.services.k8s.aws`, `bedrockagent.services.k8s.aws`, `bedrockagentcorecontrol.services.k8s.aws`, `cloudfront.services.k8s.aws`, `cloudtrail.services.k8s.aws`, `cloudwatch.services.k8s.aws`, `cloudwatchlogs.services.k8s.aws`, `codeartifact.services.k8s.aws`, `cognitoidentityprovider.services.k8s.aws`, `documentdb.services.k8s.aws`, `dynamodb.services.k8s.aws`, `ec2.services.k8s.aws`, `ecr.services.k8s.aws`, `ecrpublic.services.k8s.aws`, `ecs.services.k8s.aws`, `efs.services.k8s.aws`, `eks.services.k8s.aws`, `elasticache.services.k8s.aws`, `elbv2.services.k8s.aws`, `emrcontainers.services.k8s.aws`, `eventbridge.services.k8s.aws`, `iam.services.k8s.aws`, `kafka.services.k8s.aws`, `keyspaces.services.k8s.aws`, `kinesis.services.k8s.aws`, `kms.services.k8s.aws`, `lambda.services.k8s.aws`, `memorydb.services.k8s.aws`, `mq.services.k8s.aws`, `networkfirewall.services.k8s.aws`, `opensearchservice.services.k8s.aws`, `organizations.services.k8s.aws`, `pipes.services.k8s.aws`, `prometheusservice.services.k8s.aws`, `ram.services.k8s.aws`, `rds.services.k8s.aws`, `recyclebin.services.k8s.aws`, `route53.services.k8s.aws`, `route53resolver.services.k8s.aws`, `s3.services.k8s.aws`, `s3control.services.k8s.aws`, `sagemaker.services.k8s.aws`, `secretsmanager.services.k8s.aws`, `ses.services.k8s.aws`, `sfn.services.k8s.aws`, `sns.services.k8s.aws`, `sqs.services.k8s.aws`, `ssm.services.k8s.aws`, `wafv2.services.k8s.aws` | `*` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (somente concessões específicas do controlador de serviços do ACK) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
## AmazonEKSArgoCDClusterPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDClusterPolicy`
Esta política concede permissões em nível de cluster necessárias para que a funcionalidade do Argo CD descubra recursos e gerencie objetos com escopo de cluster. A política inclui as seguintes permissões:
Gerenciamento de namespaces:
+ Permite a criação, a leitura, a atualização e a exclusão de namespaces para o gerenciamento de namespaces de aplicações.
Gerenciamento da definição de recursos personalizados:
+ Gerenciamento de CRDs específicas do Argo CD (Applications, AppProjects e ApplicationSets).
Descoberta de API:
+ Possibilita acesso de leitura aos endpoints da API do Kubernetes para a descoberta de recursos.
Esta política foi projetada para fornecer suporte às operações do Argo CD em nível de cluster, incluindo o gerenciamento de namespaces e a instalação de CRDs. O Amazon EKS cria automaticamente uma entrada de acesso com a presente política de acesso para o perfil do IAM da funcionalidade que você fornece quando a funcionalidade do Argo CD é criada.
| Grupos de APIs Kubernetes | Kubernetes nonResourceURLs | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- | --- |
| | | `namespaces` | `create`, `get`, `update`, `patch`, `delete` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` | `create` |
| `apiextensions.k8s.io` | | `customresourcedefinitions` (Somente CRDs do Argo CD) | `get`, `update`, `patch`, `delete` |
| | `/api`, `/api/*`, `/apis`, `/apis/*` | | `get` |
## AmazonEKSArgoCDPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSArgoCDPolicy`
Esta política concede permissões em nível de namespace necessárias para que a funcionalidade do Argo CD realize a implantação e o gerenciamento de aplicações. A política inclui as seguintes permissões:
Gerenciamento de segredos:
+ Permite acesso completo aos segredos usados para as credenciais do Git e aos segredos do cluster.
Acesso ao ConfigMap:
+ Possibilita acesso de leitura a ConfigMaps para o envio de alertas caso os clientes tentem usar ConfigMaps do Argo CD que não são compatíveis.
Gerenciamento de eventos:
+ Permite acesso de leitura e criação de eventos com o objetivo de monitorar o ciclo de vida das aplicações.
Gerenciamento de recursos do Argo CD:
+ Possibilita acesso completo a Applications, ApplicationSets e AppProjects.
+ Permite gerenciamento de finalizadores e do status dos recursos do Argo CD.
Esta política foi projetada para fornecer suporte às operações do Argo CD em nível de namespace, incluindo a implantação e o gerenciamento de aplicações. O Amazon EKS cria automaticamente uma entrada de acesso com a presente política de acesso para o perfil do IAM da funcionalidade que você fornece quando a funcionalidade do Argo CD é criada, com escopo no namespace do Argo CD.
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| | `secrets` | `*` |
| | `configmaps` | `get`, `list`, `watch` |
| | `events` | `get`, `list`, `watch`, `patch`, `create` |
| `argoproj.io` | `applications`, `applications/finalizers`, `applications/status`, `applicationsets`, `applicationsets/finalizers`, `applicationsets/status`, `appprojects`, `appprojects/finalizers`, `appprojects/status` | `*` |
## AmazonEKSKROPolicy
**ARN** – ` arn:aws:eks::aws:cluster-access-policy/AmazonEKSKROPolicy`
Esta política concede as permissões necessárias para que a funcionalidade do kro (Kube Resource Orchestrator) crie e gerencie APIs personalizadas do Kubernetes. A política inclui as seguintes permissões:
Gerenciamento de recursos do kro:
+ Permite acesso completo a todos os recursos do kro, abrangendo ResourceGraphDefinitions e instâncias de recursos personalizados.
Gerenciamento da definição de recursos personalizados:
+ Possibilita a criação, a leitura, a atualização e a exclusão de CRDs para APIs personalizadas e definidas por ResourceGraphDefinitions.
Eleição do líder:
+ Possibilita a criação e a leitura de concessões de coordenação para eleição de líder.
+ Permite a atualização e a exclusão da concessão do controlador do kro.
Gerenciamento de eventos:
+ Possibilita a criação e a aplicação de patches em eventos relacionados às operações do kro.
Esta política foi projetada para oferecer suporte à composição abrangente de recursos e ao gerenciamento de APIs personalizadas por meio do kro. O Amazon EKS cria automaticamente uma entrada de acesso com a presente política de acesso para o perfil do IAM da funcionalidade que você fornece quando a funcionalidade do kro é criada.
| Grupos de APIs Kubernetes | Recursos Kubernetes | Verbos (permissões) Kubernetes |
| --- | --- | --- |
| `kro.run` | `*` | `*` |
| `apiextensions.k8s.io` | `customresourcedefinitions` | `*` |
| `coordination.k8s.io` | `leases` | `create`, `get`, `list`, `watch` |
| `coordination.k8s.io` | `leases` (somente para concessão de controladores do kro) | `delete`, `update`, `patch` |
| | `events` | `create`, `patch` |
## Atualizações de política de acesso
Visualize detalhes sobre as atualizações das políticas de acesso, desde que elas foram introduzidas. Para receber alertas automáticos sobre alterações nesta página, assine o feed RSS em [Histórico do documento](doc-history.md).
| Alteração | Descrição | Data |
| --- | --- | --- |
| Adição de políticas para as funcionalidades do EKS | Publicação das políticas `AmazonEKSACKPolicy`, `AmazonEKSArgoCDClusterPolicy`, `AmazonEKSArgoCDPolicy` e `AmazonEKSKROPolicy` para o gerenciamento das funcionalidades do EKS | 22 de novembro de 2025 |
| Adicionar `AmazonEKSSecretReaderPolicy` | Adição de uma nova política para acesso somente leitura a segredos | 6 de novembro de 2025 |
| Adicionar política para o EKS Cluster Insights | Publicar `AmazonEKSClusterInsightsPolicy` | 2 de dezembro de 2024 |
| Adicionar políticas do Amazon EKS Hybrid | Publicar `AmazonEKSHybridPolicy` | 2 de dezembro de 2024 |
| Adicionar políticas do Modo Automático do Amazon EKS | Estas políticas de acesso dão ao perfil do IAM do cluster e ao perfil do IAM do nó permissão para chamar as APIs do Kubernetes. A AWS as usa para automatizar tarefas de rotina de recursos de armazenamento, computação e rede. | 2 de dezembro de 2024 |
| Adicionar `AmazonEKSAdminViewPolicy` | Adicione uma nova política para acesso de visualização expandido, incluindo recursos como Segredos. | 23 de abril de 2024 |
| Políticas de acesso introduzidas. | O Amazon EKS introduziu políticas de acesso. | 29 de maio de 2023 |
# Alterar o modo de autenticação para usar entradas de acesso
Para começar a usar entradas de acesso, você deve alterar o modo de autenticação do cluster para os modos `API_AND_CONFIG_MAP` ou `API`. Essa ação adiciona a API para entradas de acesso.
## Console do AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster em que você deseja criar uma entrada de acesso.
1. Escolha a guia **Acesso**.
1. O **Modo de autenticação** mostra o modo de autenticação atual do cluster. Se o modo indicar API do EKS, já será possível adicionar entradas de acesso e pular as etapas restantes.
1. Selecione **Gerenciar acesso**.
1. Em **Modo de autenticação de cluster**, selecione um modo com a API do EKS. Observe que você não pode alterar o modo de autenticação de volta para um modo que remova as entradas de acesso e a API do EKS.
1. Escolha **Salvar alterações**. O Amazon EKS começa a atualizar o cluster, o status do cluster muda para Updating e a alteração é registrada na guia **Histórico de atualizações**.
1. Aguarde até que o status do cluster retorne para Active. Quando o cluster estiver Active, será possível seguir as etapas em [Criar entradas de acesso](creating-access-entries.md) para adicionar acesso ao cluster das entidades principais do IAM.
## AWS CLI
1. Instale a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no *Guia do usuário da AWS Command Line Interface*.
1. Execute o comando a seguir. Substitua *my-cluster* pelo nome do cluster. Se você quiser deshabilitar o método `ConfigMap` permanentemente, substitua `API_AND_CONFIG_MAP` por `API`.
O Amazon EKS começa a atualizar o cluster, o status do cluster muda para UPDATING e a alteração é registrada em ** aws eks list-updates **.
```
aws eks update-cluster-config --name my-cluster --access-config authenticationMode=API_AND_CONFIG_MAP
```
1. Aguarde até que o status do cluster retorne para Active. Quando o cluster estiver Active, será possível seguir as etapas em [Criar entradas de acesso](creating-access-entries.md) para adicionar acesso ao cluster das entidades principais do IAM.
## Versão da plataforma necessária
Para usar as *entradas de acesso*, o cluster dove ter uma versão da plataforma igual ou posterior à versão listada na tabela apresentada a seguir ou uma versão do Kubernetes posterior às versões listadas na tabela. Caso sua versão do Kubernetes não esteja listada, todas as versões da plataforma serão compatíveis com as entradas de acesso.
| Versão do Kubernetes | Versão da plataforma |
| --- | --- |
| Não listado | Todos compatíveis |
| `1.30` | `eks.2` |
| `1.29` | `eks.1` |
| `1.28` | `eks.6` |
Para obter mais informações, consulte [Versões da plataforma](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html).
# Criar entradas de acesso
Antes de criar entradas de acesso, considere o seguinte:
+ Um modo de autenticação definido corretamente. Consulte [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md).
+ Uma *entrada de acesso* inclui o nome do recurso da Amazon (ARN) de uma, e somente uma, entidade principal do IAM existente. Uma entidade principal do IAM não pode ser incluída em mais de uma entrada de acesso. Considerações adicionais para o ARN especificado por você:
+ As práticas recomendadas do IAM sugerem que você acesse o cluster usando *perfis* do IAM que têm credenciais de curto prazo, em vez de *usuários* do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte [Exigir que os usuários humanos usem a federação com um provedor de identidade para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
+ Se o ARN for para um perfil do IAM, ele *pode* incluir um caminho. Os ARNs nas entradas `ConfigMap` `aws-auth` *não podem* incluir um caminho. Por exemplo, seu ARN pode ser ` arn:aws:iam::<111122223333>:role/` ou ` arn:aws:iam::<111122223333>:role/`.
+ Se o tipo da entrada de acesso for diferente de `STANDARD` (consulte a próxima consideração sobre tipos), o ARN deverá estar na mesma conta AWS em que seu cluster está. Se o tipo for `STANDARD`, o ARN poderá estar na mesma conta AWS ou em uma conta diferente da conta em que seu cluster está.
+ Não é possível alterar a entidade principal do IAM depois que a entrada de acesso é criada.
+ Se você alguma vez você excluir a entidade principal do IAM com esse ARN, a entrada de acesso não será excluída automaticamente. Recomendamos que você exclua a entrada de acesso com um ARN para uma entidade principal do IAM que você exclua. Se você não excluir a entrada de acesso e nunca recriar a entidade principal do IAM, mesmo que ela tenha o mesmo ARN, a entrada de acesso não funcionará. Isso ocorre porque, embora o ARN seja o mesmo para a entidade principal do IAM recriada, o endereço `roleID` ou `userID` (você pode ver isso com o comando `aws sts get-caller-identity` da AWS CLI) é diferente para a entidade principal do IAM recriada e para a entidade IAM original. Mesmo que você não veja o `roleID` ou `userID` da entidade principal do IAM para uma entrada de acesso, o Amazon EKS o armazena com a entrada de acesso.
+ Cada entrada de acesso tem um *tipo*. O tipo da entrada de acesso depende do tipo de recurso ao qual está associada, e não define as permissões. Se você não especificar um tipo, o Amazon EKS definirá automaticamente o tipo como `STANDARD`.
+ `EC2_LINUX`: para um perfil do IAM usado com nós autogerenciados do Linux ou Bottlerocket
+ `EC2_WINDOWS`: para um perfil do IAM usado com nós autogerenciados do Windows
+ `FARGATE_LINUX`: para um perfil do IAM usado com o AWS Fargate (Fargate)
+ `HYBRID_LINUX`: para um perfil do IAM usado com nós híbridos
+ `STANDARD`: tipo padrão se nenhum for especificado
+ `EC2`: para classes de nós personalizadas do Modo Automático do EKS Para obter mais informações, consulte [Criar entrada de acesso de classe de nós](create-node-class.md#auto-node-access-entry).
+ Não é possível alterar o tipo depois que a entrada de acesso é criada.
+ Não é necessário criar uma entrada de acesso para um perfil do IAM usado em um grupo de nós gerenciados ou em um perfil do Fargate. O EKS criará entradas de acesso (se habilitado), ou atualizará o mapa de configuração de autenticação (caso as entradas de acesso não estejam disponíveis).
+ Se o tipo da entrada de acesso for `STANDARD`, será possível especificar um *nome de usuário* para a entrada de acesso. Se você não especificar um valor para o nome de usuário, o Amazon EKS definirá um dos valores a seguir para você, dependendo do tipo de entrada de acesso e de se a entidade principal do IAM que você especificou é um perfil do IAM ou um usuário do IAM. A menos que você tenha um motivo específico para determinar seu próprio nome de usuário, recomendamos que não especifique um e deixe o Amazon EKS gerá-lo automaticamente para você. Se você especificar seu próprio nome de usuário:
+ Não pode começar com `system:`, `eks:`, `aws:`, `amazon:` ou `iam:`.
+ Se o nome de usuário for para um perfil do IAM, recomendamos que você adicione `{{SessionName}}` ou `{{SessionNameRaw}}` ao final do seu nome de usuário. Se você adicionar `{{SessionName}}` ou `{{SessionNameRaw}}` ao seu nome de usuário, ele deverá incluir dois pontos *antes* de \$1\$1SessionName\$1\$1. Quando esse perfil é assumido, o nome da sessão do AWS STS especificado ao assumir o perfil é automaticamente transmitido para o cluster e aparecerá nos logs do CloudTrail. Por exemplo, não é possível ter um nome de usuário `john{{SessionName}}`. O nome de usuário teria que ser `:john{{SessionName}}` ou `jo:hn{{SessionName}}`. Os dois pontos precisam vir antes de `{{SessionName}}`. O nome de usuário gerado pelo Amazon EKS na tabela a seguir inclui um ARN. Como um ARN inclui dois pontos, ele atende a esse requisito. Os dois pontos não serão necessários se você não incluir `{{SessionName}}` no seu nome de usuário. Vale ressaltar que em `{{SessionName}}`, o caractere especial “@” é substituído por “-” no nome da sessão. `{{SessionNameRaw}}` mantém todos os caracteres especiais no nome da sessão.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/eks/latest/userguide/creating-access-entries.html)
Você poderá alterar o nome de usuário depois que a entrada de acesso for criada.
+ Se o tipo de entrada de acesso for `STANDARD` e você quiser usar a autorização RBAC do Kubernetes RBAC, poderá adicionar um ou mais *nomes de grupos* à entrada de acesso. Depois de criar uma entrada de acesso, você pode adicionar e remover nomes de grupos. Para que a entidade principal do IAM tenha acesso aos objetos do Kubernetes em seu cluster, você deve criar e gerenciar objetos de autorização baseada em perfil (RBAC) do Kubernetes. Crie objetos `RoleBinding` ou `ClusterRoleBinding` do Kubernetes no cluster que especifiquem o nome do grupo como um `subject` para `kind: Group`. O Kubernetes autoriza o acesso da entidade principal do IAM a quaisquer objetos do cluster que você tenha especificado em um objeto `Role` ou `ClusterRole` do Kubernetes, que você também tenha especificado na `roleRef` da associação. Se você especificar nomes de grupo, convém familiarizar-se com os objetos de autorização com base em perfil (RBAC) do Kubernetes. Para mais informações, consulte [Usando a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
**Importante**
O Amazon EKS não confirma que nenhum objeto RBAC do Kubernetes existente no seu cluster inclua algum dos nomes de grupos que você especificar. Por exemplo, se você criar uma entrada de acesso para um grupo que ainda não existe, o EKS criará o grupo em vez de retornar um erro.
Em vez de, ou além de, o Kubernetes autorizar o acesso da entidade principal do IAM aos objetos do Kubernetes no cluster, você pode associar as *políticas de acesso* do Amazon EKS a uma entrada de acesso. O Amazon EKS autoriza as entidades principais do IAM a acessar objetos do Kubernetes no cluster com as permissões na política de acesso. Você pode definir o escopo das permissões de uma política de acesso aos namespaces do Kubernetes que você especificar. O uso de políticas de acesso não exige que você gerencie objetos RBAC do Kubernetes. Para obter mais informações, consulte [Associar políticas de acesso a entradas de acesso](access-policies.md).
+ Se você criar uma entrada de acesso com o tipo `EC2_LINUX` ou `EC2_Windows`, a entidade principal do IAM que criou a entrada de acesso deverá ter a permissão `iam:PassRole`. Para obter mais informações, consulte [Conceder permissões ao usuário para passar uma função a um produto da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_passrole.html) no *Guia do usuário do IAM*.
+ Semelhante ao [comportamento padrão do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/troubleshoot_general.html#troubleshoot_general_eventual-consistency), a criação e as atualizações de entradas de acesso acabam sendo consistentes e podem levar alguns segundos para serem efetivadas após o retorno bem-sucedido da chamada inicial de API. Suas aplicações devem ser projetadas para levar em conta esses possíveis atrasos. Recomendamos que você não inclua criações ou atualizações de entrada de acesso nos caminhos de código críticos de alta disponibilidade da sua aplicação. Em vez disso, faça alterações do em uma rotina de inicialização ou de configuração separada que você executa com menos frequência. Além disso, certifique-se de verificar se as alterações foram propagadas antes que os fluxos de trabalho de produção dependam delas.
+ As entradas de acesso não oferecem suporte para [perfis vinculados ao serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html). Não é possível criar entradas de acesso nas quais o ARN da entidade principal corresponde a um perfil vinculado ao serviço. É possível identificar perfis vinculados ao serviço pelo ARN deles, que está no formato ` arn:aws:iam::*:role/aws-service-role/*`.
Você pode criar uma entrada de acesso usando o Console de gerenciamento da AWS ou a AWS CLI.
## Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster em que você deseja criar uma entrada de acesso.
1. Escolha a guia **Acesso**.
1. Selecione **Criar entrada de acesso**.
1. Para a **entidade principal do IAM**, selecione um perfil ou usuário do IAM existente. As práticas recomendadas do IAM sugerem que você acesse o cluster usando *perfis* do IAM que têm credenciais de curto prazo, em vez de *usuários* do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte [Exigir que os usuários humanos usem a federação com um provedor de identidade para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
1. Em **Tipo**, se a entrada de acesso for para a função de nó usada para nós autogerenciados do Amazon EC2, selecione **EC2 Linux** ou **EC2 Windows**. Caso contrário, aceite o padrão (**Padrão**).
1. Se o **Tipo** escolhido for **Padrão** e você quiser especificar um **nome de usuário**, insira o nome de usuário.
1. Se o **Tipo** escolhido for **Padrão** e você quiser usar a autorização RBAC do Kubernetes para a entidade principal do IAM, especifique um ou mais nomes para **Grupos**. Se você não especificar nenhum nome de grupo e quiser usar a autorização do Amazon EKS, poderá associar uma política de acesso em uma etapa posterior ou após a criação da entrada de acesso.
1. (Opcional) Para **Tags**, atribua rótulos à entrada de acesso. Por exemplo, para facilitar a localização de todos os recursos com a mesma tag.
1. Escolha **Próximo**.
1. Na página **Adicionar política de acesso**, se o tipo escolhido for **Padrão** e você quiser que o Amazon EKS autorize a entidade principal do IAM a ter permissões para os objetos do Kubernetes em seu cluster, execute as etapas a seguir. Caso contrário, escolha **Next**.
1. Em **Nome da política**, escolha uma política de acesso. Você não pode ver as permissões das políticas de acesso, mas elas incluem permissões semelhantes às dos objetos do `ClusterRole` do Kubernetes voltados para o usuário. Para obter mais informações, consulte [User-facing roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-facing-roles) na documentação do Kubernetes.
1. Escolha uma das seguintes opções:
+ **Cluster**: escolha esta opção se quiser que o Amazon EKS autorize a entidade principal do IAM a ter as permissões na política de acesso para todos os objetos do Kubernetes no cluster.
+ **Namespace do Kubernetes**: escolha esta opção se quiser que o Amazon EKS autorize a entidade principal do IAM a ter as permissões na política de acesso para todos os objetos do Kubernetes em um namespace do Kubernetes específico no cluster. Em **Namespace**, insira o nome do namespace do Kubernetes no cluster. Se quiser adicionar mais namespaces, escolha **Adicionar novo namespace** e insira o nome do namespace.
1. Se você quiser adicionar mais políticas, escolha **Adicionar política**. Você pode definir o escopo de cada política de forma diferente, mas cada política só pode ser adicionada uma vez.
1. Escolha **Próximo**.
1. Revise a configuração da entrada de acesso. Se algo parecer errado, escolha **Anterior** para voltar às etapas anteriores e corrigir o erro. Se a configuração estiver correta, escolha **Criar**.
## AWS CLI
1. Instale a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html), no Guia do usuário da AWS Command Line Interface.
1. Para criar uma entrada de acesso Você pode usar qualquer um dos exemplos a seguir para criar entradas de acesso:
+ Crie uma entrada de acesso para um grupo de nós autogerenciado do Amazon EC2 Linux. Substitua *my-cluster* pelo nome do cluster, *111122223333* pelo ID da conta da AWS e *EKS-my-cluster-self-managed-ng-1* pelo nome do [perfil do IAM do nó](create-node-role.md). Caso seu grupo de nós seja um grupo de nós do Windows, substitua *EC2\$1LINUX* por `EC2_Windows`.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-self-managed-ng-1 --type EC2_LINUX
```
Você não pode usar a opção `--kubernetes-groups` ao especificar um tipo diferente de `STANDARD`. Você não pode associar uma política de acesso a essa entrada de acesso porque seu tipo é um valor diferente de `STANDARD`.
+ Crie uma entrada de acesso que permita um perfil do IAM que não é usado para um grupo de nós autogerenciados do Amazon EC2, com o qual você deseja que o Kubernetes autorize o acesso ao seu cluster. Substitua *my-cluster* pelo nome do cluster, *111122223333* pela ID da conta AWS e *my-role* pelo nome do perfil do IAM. Substitua *Visualizadores* pelo nome de um grupo que você especificou em um objeto `RoleBinding` ou `ClusterRoleBinding` do Kubernetes no cluster.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role --type STANDARD --user Viewers --kubernetes-groups Viewers
```
+ Crie uma entrada de acesso que permita que um usuário do IAM se autentique no seu cluster. Esse exemplo é fornecido porque isso é possível, embora as práticas recomendadas do IAM sugiram acessar seu cluster usando *perfis* do IAM que têm credenciais de curto prazo, em vez de *usuários* do IAM que têm credenciais de longo prazo. Para obter mais informações, consulte [Exigir que os usuários humanos usem a federação com um provedor de identidade para acessar a AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:user/my-user --type STANDARD --username my-user
```
Se quiser que esse usuário tenha mais acesso ao cluster do que as permissões nos perfis de descoberta da API do Kubernetes, você precisará associar uma política de acesso à entrada de acesso, já que a opção `--kubernetes-groups` não é usada. Para obter mais informações, consulte [Associar políticas de acesso a entradas de acesso](access-policies.md) e [API discovery roles](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#discovery-roles) na documentação do Kubernetes.
# Atualizar entradas de acesso
Você pode atualizar uma entrada de acesso usando o Console de gerenciamento da AWS ou a AWS CLI.
## Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster em que você deseja criar uma entrada de acesso.
1. Escolha a guia **Acesso**.
1. Selecione a entrada de acesso que você deseja atualizar.
1. Escolha **Editar**.
1. Em **Nome de usuário**, você pode alterar o valor existente.
1. Em **Grupos**, você pode remover nomes de grupos existentes ou adicionar novos nomes de grupos. Se os seguintes nomes de grupos existirem, não os remova: **system:nodes** ou **system:bootstrappers**. A remoção desses grupos pode fazer com que seu cluster funcione incorretamente. Se você não especificar nenhum nome de grupo e quiser usar a autorização do Amazon EKS, associe uma [política de acesso](access-policies.md) em uma etapa posterior.
1. Em **Tags**, você pode atribuir rótulos à entrada de acesso. Por exemplo, para facilitar a localização de todos os recursos com a mesma tag. Você também pode remover as tags existentes.
1. Escolha **Salvar alterações**.
1. Se você quiser associar uma política de acesso à entrada, consulte [Associar políticas de acesso a entradas de acesso](access-policies.md).
## AWS CLI
1. Instale a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html), no Guia do usuário da AWS Command Line Interface.
1. Para atualizar uma entrada de acesso, substitua *my-cluster* pelo nome do seu cluster, *111122223333* pelo ID da sua conta AWS e *EKS-my-cluster-my-namespace-Viewers* pelo nome de um perfil do IAM.
```
aws eks update-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/EKS-my-cluster-my-namespace-Viewers --kubernetes-groups Viewers
```
Você não poderá usar a opção `--kubernetes-groups` se o tipo da entrada de acesso for um valor diferente de `STANDARD`. Você também não pode associar uma política de acesso a uma entrada de acesso com um tipo diferente de `STANDARD`.
# Excluir entradas de acesso
Se você descobrir que excluiu uma entrada de acesso por engano, sempre poderá recriá-la. Se a entrada de acesso que você está excluindo estiver associada a alguma política de acesso, as associações serão excluídas automaticamente. Você não precisa desassociar as políticas de acesso de uma entrada de acesso antes de excluir a entrada de acesso.
Você pode excluir uma entrada de acesso usando o Console de gerenciamento da AWS ou a AWS CLI.
## Console de gerenciamento da AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Escolha o nome do cluster do qual você deseja excluir uma entrada de acesso.
1. Escolha a guia **Acesso**.
1. Na lista **Entradas de acesso**, escolha a entrada de acesso que você deseja excluir.
1. Escolha Delete.
1. Na caixa de diálogo de confirmação, escolha **Excluir**.
## AWS CLI
1. Instale a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html), no Guia do usuário da AWS Command Line Interface.
1. Para excluir uma entrada de acesso Substitua *my-cluster* pelo nome do cluster, *111122223333* pela ID da conta AWS e *my-role* pelo nome do perfil do IAM que você não deseja mais que tenha acesso ao cluster.
```
aws eks delete-access-entry --cluster-name my-cluster --principal-arn arn:aws:iam::111122223333:role/my-role
```
# Definir um nome de usuário personalizado para entradas de acesso ao EKS
Ao criar entradas de acesso para o Amazon EKS, é possível usar o nome de usuário gerado automaticamente ou especificar um personalizado. Esta página explica as duas alternativas e orienta sobre a configuração de um nome de usuário personalizado.
## Visão geral
O nome de usuário em uma entrada de acesso é usado para identificar a entidade principal do IAM em logs e trilhas de auditoria do Kubernetes. Por padrão, o Amazon EKS gera um nome de usuário com base no ARN da identidade do IAM, mas também é possível especificar um nome de usuário personalizado, se necessário.
## Geração de nome de usuário padrão
Se você não especificar um valor como nome de usuário, o Amazon EKS definirá um de maneira automática com base na identidade do IAM:
+ **Para usuários do IAM**:
+ O EKS define o nome de usuário do Kubernetes como o ARN do usuário do IAM
+ Exemplo:
```
{arn-aws}iam::<111122223333>:user/
```
+ **Para perfis do IAM**:
+ O EKS define o nome de usuário do Kubernetes como o ARN do perfil do IAM
+ O STS ARN do perfil quando ele é assumido. O Amazon EKS anexa `{{SessionName}}` ao perfil. Se o ARN do perfil que você especificou contiver um caminho, o Amazon EKS o removerá no nome de usuário gerado.
+ Exemplo:
```
{arn-aws}sts::<111122223333>:assumed-role//{{SessionName}}
```
A menos que você tenha um motivo específico para determinar seu próprio nome de usuário, recomendamos que não especifique um e deixe o Amazon EKS gerá-lo automaticamente.
## Configuração de um nome de usuário personalizado
Ao criar uma entrada de acesso, você pode especificar um nome de usuário personalizado usando o parâmetro `--username`:
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --username
```
### Requisitos para nomes de usuário personalizados
Se você especificar um nome de usuário personalizado:
+ O nome de usuário não pode começar com `system:`, `eks:`, `aws:`, `amazon:`, ou `iam:`.
+ Se o nome de usuário for para um perfil do IAM, recomendamos que você adicione `{{SessionName}}` ou `{{SessionNameRaw}}` ao final do seu nome de usuário.
+ Se você adicionar `{{SessionName}}` ou `{{SessionNameRaw}}` ao seu nome de usuário, ele deverá incluir dois pontos *antes* de \$1\$1SessionName\$1\$1.
# Criar uma entrada de acesso para um usuário ou perfil do IAM usando uma política de acesso e a AWS CLI
Crie entradas de acesso do Amazon EKS que usam políticas de acesso gerenciadas pela AWS do EKS para conceder permissões padronizadas às identidades do IAM para acessar e gerenciar clusters do Kubernetes.
## Visão geral
As entradas de acesso no Amazon EKS definem como as identidades do IAM (usuários e perfis) acessam e interagem com seus clusters do Kubernetes. Ao criar entradas de acesso com as políticas de acesso do EKS, você pode:
+ Conceda permissão a usuários ou funções específicas do IAM para acessar seu cluster do EKS
+ Controle as permissões usando políticas de acesso do EKS gerenciadas pela AWS que fornecem conjuntos de permissões padronizados e predefinidos
+ Permissões de escopo para namespaces específicos ou em todo o cluster
+ Simplifique o gerenciamento de acesso sem modificar o `aws-auth` ConfigMap ou criar recursos RBAC do Kubernetes
+ Use uma abordagem integrada com a AWS para o controle de acesso do Kubernetes que abrange casos de uso comuns, mantendo as melhores práticas de segurança
Essa abordagem é recomendada para a maioria dos casos de uso porque fornece permissões gerenciadas pela AWS e padronizadas sem exigir a configuração manual do Kubernetes RBAC. As políticas de acesso do EKS eliminam a necessidade de configurar manualmente os recursos RBAC do Kubernetes e oferecem conjuntos de permissões predefinidos que abrangem casos de uso comuns.
## Pré-requisitos
+ O *modo de autenticação* do seu cluster deve ser configurado para permitir *entradas de acesso*. Para obter mais informações, consulte [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md).
+ Instale e configure a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html), no Guia do usuário da AWS Command Line Interface.
## Etapa 1: definir a entrada de acesso
1. Encontre o ARN da identidade do IAM, como um usuário ou um perfil, ao qual você deseja conceder permissões.
+ Cada identidade do IAM pode ter somente uma entrada de acesso ao EKS.
1. Determine se você deseja que as permissões da política de acesso do Amazon EKS se apliquem somente a um namespace específico do Kubernetes ou a todo o cluster.
+ Se você quiser limitar as permissões a um namespace específico, anote o nome do namespace.
1. Selecione a política de acesso do EKS que você deseja para a identidade do IAM. Essa política fornece permissões no cluster. Anote o ARN da política.
+ Para obter uma lista de políticas, consulte as [políticas de acesso disponíveis](access-policy-permissions.md).
1. Determine se o nome de usuário gerado automaticamente é apropriado para a entrada de acesso ou se você precisa especificar manualmente um nome de usuário.
+ A AWS gera automaticamente esse valor com base na identidade do IAM. Você pode definir um nome de usuário personalizado. Isso é visível nos logs do Kubernetes.
+ Para obter mais informações, consulte [Definir um nome de usuário personalizado para entradas de acesso ao EKS](set-custom-username.md).
## Etapa 2: criar uma entrada de acesso
Depois de planejar a entrada de acesso, use a AWS CLI para criá-la.
Os exemplos a seguir abordam a maior parte dos casos de uso. [Veja a referência da CLI para todas as opções de configuração](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
Você anexará a política de acesso na próxima etapa.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD
```
## Etapa 3: associar a política de acesso
O comando difere com base em se você deseja que a política seja limitada a um namespace específico do Kubernetes.
Você precisa do ARN da política de acesso. Analise as [políticas de acesso disponíveis](access-policy-permissions.md).
### Criar uma política sem escopo de namespace
```
aws eks associate-access-policy --cluster-name --principal-arn --policy-arn
```
### Criar com escopo de namespace
```
aws eks associate-access-policy --cluster-name --principal-arn \
--access-scope type=namespace,namespaces=my-namespace1,my-namespace2 --policy-arn
```
## Próximas etapas
+ [Crie um kubeconfig para usar o kubectl com uma identidade do IAM](create-kubeconfig.md)
# Criar uma entrada de acesso usando grupos do Kubernetes com a AWS CLI
Crie entradas de acesso do Amazon EKS que usam grupos do Kubernetes para fins de autorização e exigem a configuração manual do RBAC.
**nota**
Para a maioria dos casos de uso, recomendamos usar as políticas de acesso do EKS em vez da abordagem de grupos do Kubernetes descrita nesta página. As políticas de acesso do EKS fornecem uma maneira mais simples e integrada com a AWS para gerenciar o acesso sem exigir a configuração manual do RBAC. Use a abordagem de grupos do Kubernetes somente quando precisar de um controle mais granular do que o oferecido pelas políticas de acesso do EKS.
## Visão geral
As entradas de acesso definem como as identidades do IAM (usuários e perfis) acessam seus clusters do Kubernetes. A abordagem de grupos do Kubernetes concede aos usuários ou perfis do IAM permissão para acessar seu cluster EKS por meio de grupos RBAC padrão do Kubernetes. Esse método requer a criação e o gerenciamento de recursos RBAC do Kubernetes (Roles, RoleBindings, ClusterRoles e ClusterRoleBindings) e é recomendado quando você precisa de conjuntos de permissões altamente personalizados, requisitos de autorização complexos ou deseja manter padrões de controle de acesso consistentes em ambientes híbridos do Kubernetes.
Este tópico não aborda a criação de entradas de acesso para identidades do IAM usadas para instâncias do Amazon EC2 para integrar clusters do EKS.
## Pré-requisitos
+ O *modo de autenticação* do seu cluster deve ser configurado para permitir *entradas de acesso*. Para obter mais informações, consulte [Alterar o modo de autenticação para usar entradas de acesso](setting-up-access-entries.md).
+ Instale e configure a AWS CLI, conforme descrito em [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html), no Guia do usuário da AWS Command Line Interface.
+ É recomendável familiarizar-se com o Kubernetes RBAC. Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
## Etapa 1: definir a entrada de acesso
1. Encontre o ARN da identidade do IAM, como um usuário ou um perfil, ao qual você deseja conceder permissões.
+ Cada identidade do IAM pode ter somente uma entrada de acesso ao EKS.
1. Determine quais grupos do Kubernetes você deseja associar a essa identidade do IAM.
+ Você precisará criar ou usar os recursos do Kubernetes existentes `Role`/`ClusterRole` e `RoleBinding`/`ClusterRoleBinding` que façam referência a esses grupos.
1. Determine se o nome de usuário gerado automaticamente é apropriado para a entrada de acesso ou se você precisa especificar manualmente um nome de usuário.
+ A AWS gera automaticamente esse valor com base na identidade do IAM. Você pode definir um nome de usuário personalizado. Isso é visível nos logs do Kubernetes.
+ Para obter mais informações, consulte [Definir um nome de usuário personalizado para entradas de acesso ao EKS](set-custom-username.md).
## Etapa 2: criar uma entrada de acesso para grupos do Kubernetes
Depois de planejar a entrada de acesso, use a AWS CLI para criá-la com os grupos apropriados do Kubernetes.
```
aws eks create-access-entry --cluster-name --principal-arn --type STANDARD --kubernetes-groups
```
Substitua:
+ `` com o nome do seu cluster do EKS
+ `` com o ARN do perfil ou usuário do IAM
+ `` com uma lista separada por vírgulas de grupos do Kubernetes (por exemplo, "system:developers,system:readers")
[Veja a referência da CLI para todas as opções de configuração](https://docs.aws.amazon.com/cli/latest/reference/eks/create-access-entry.html).
## Etapa 3: configurar recursos do RBAC
Para que a entidade principal do IAM tenha acesso aos objetos do Kubernetes em seu cluster, você deve criar e gerenciar objetos de controle de acesso com base em perfil (RBAC) do Kubernetes:
1. Crie objetos `Role` ou `ClusterRole` do Kubernetes que definam as permissões.
1. Crie objetos `RoleBinding` ou `ClusterRoleBinding` do Kubernetes no cluster que especifiquem o nome do grupo como um `subject` para `kind: Group`.
Para obter informações detalhadas sobre como configurar grupos e permissões no Kubernetes, consulte [Como usar a autorização RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
## Próximas etapas
+ [Crie um kubeconfig para usar o kubectl com uma identidade do IAM](create-kubeconfig.md)
# Conceder aos usuários do IAM acesso ao Kubernetes com um ConfigMap
**Importante**
O `aws-auth ConfigMap` está obsoleto. Para conhecer o método recomendado para gerenciar o acesso a APIs do Kubernetes, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md).
O acesso ao seu cluster usando [entidades principais do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) é ativado pelo [AWS IAM Authenticator for Kubernetes](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme), que é executado no ambiente de gerenciamento do Amazon EKS. O autenticador obtém suas informações de configuração do `ConfigMap` `aws-auth`. Para todas as configurações do `ConfigMap` `aws-auth`, consulte [Formato de configuração completo](https://github.com/kubernetes-sigs/aws-iam-authenticator#full-configuration-format) no GitHub.
## Adicione um usuário do IAM ao cluster do Amazon EKS
Quando você cria um cluster do Amazon EKS, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que cria o cluster, recebe automaticamente permissões `system:masters` na configuração de controle de acesso baseado em perfil (RBAC) no ambiente de gerenciamento do Amazon EKS. Como essa entidade principal não é exibida em nenhuma configuração visível, mantenha o controle de qual entidade principal criou o cluster originalmente. Para conceder a outras entidades principais do IAM a capacidade de interagir com o cluster, edite o `aws-auth ConfigMap` no Kubernetes e crie um `rolebinding` ou `clusterrolebinding` do Kubernetes com o nome de um `group` especificado no `aws-auth ConfigMap`.
**nota**
Para obter mais informações sobre a configuração de controle de acesso baseado em perfil (RBAC) do Kubernetes, consulte [Using RBAC Authorization](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
1. Determine quais credenciais o `kubectl` está usando para acessar o cluster. Em seu computador, você pode ver quais credenciais o `kubectl` usa com o comando a seguir. Substitua *\$1/.kube/config* pelo caminho do arquivo `kubeconfig` se você não usar o caminho padrão.
```
cat ~/.kube/config
```
Veja abaixo um exemplo de saída.
```
[...]
contexts:
- context:
cluster: my-cluster.region-code.eksctl.io
user: admin@my-cluster.region-code.eksctl.io
name: admin@my-cluster.region-code.eksctl.io
current-context: admin@my-cluster.region-code.eksctl.io
[...]
```
No exemplo de saída anterior, as credenciais de um usuário chamado *admin* são configuradas para um cluster chamado *my-cluster*. Se for o usuário que criou o cluster, ele já terá acesso ao cluster. Se não for o usuário que criou o cluster, será necessário concluir as etapas restantes para habilitar o acesso ao cluster para os outras entidades principais do IAM. [As melhores práticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recomendam que você conceda permissões para perfis e não para usuários. É possível ver quais outras entidades principais atualmente têm acesso ao cluster com o seguinte comando:
```
kubectl describe -n kube-system configmap/aws-auth
```
Veja um exemplo de saída abaixo.
```
Name: aws-auth
Namespace: kube-system
Labels:
Annotations:
Data
====
mapRoles:
----
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-node-role
username: system:node:{{EC2PrivateDNSName}}
BinaryData
====
Events:
```
O exemplo anterior é um `aws-auth` `ConfigMap` padrão. Apenas a função de instância de nó tem acesso ao cluster.
1. Verifique se você já tem `roles` e `rolebindings` ou `clusterroles` e `clusterrolebindings` do Kubernetes para os quais é possível mapear as entidades principais do IAM. Para saber mais sobre esses recursos, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), na documentação do Kubernetes.
1. Visualize suas `roles` ou `clusterroles` existentes do Kubernetes. `Roles` têm o escopo definido para um `namespace`, mas `clusterroles` têm o escopo definido para o cluster.
```
kubectl get roles -A
```
```
kubectl get clusterroles
```
1. Visualize os detalhes de qualquer `role` ou `clusterrole` retornada no resultado anterior e confirme que ela tem as permissões (`rules`) que você quer que as entidades principais do IAM tenham no cluster.
Substitua *role-name* por um nome de `role` retornado na saída do comando anterior. Substitua *kube-system* pelo namespace da `role`.
```
kubectl describe role role-name -n kube-system
```
Substitua *cluster-role-name* por um nome de `clusterrole` retornado na saída do comando anterior.
```
kubectl describe clusterrole cluster-role-name
```
1. Visualize suas `rolebindings` ou `clusterrolebindings` existentes do Kubernetes. `Rolebindings` têm o escopo definido para um `namespace`, mas `clusterrolebindings` têm o escopo definido para o cluster.
```
kubectl get rolebindings -A
```
```
kubectl get clusterrolebindings
```
1. Visualize os detalhes de qualquer `rolebinding` ou `clusterrolebinding` e confirme que ele tem uma `role` ou `clusterrole` da etapa anterior listada como `roleRef` e um nome de grupo listado para `subjects`.
Substitua *role-binding-name* por um nome de `rolebinding` retornado na saída do comando anterior. Substitua *kube-system* pelo `namespace` da `rolebinding`.
```
kubectl describe rolebinding role-binding-name -n kube-system
```
Veja abaixo um exemplo de saída.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: eks-console-dashboard-restricted-access-role-binding
namespace: default
subjects:
- kind: Group
name: eks-console-dashboard-restricted-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: eks-console-dashboard-restricted-access-role
apiGroup: rbac.authorization.k8s.io
```
Substitua *cluster-role-binding-name* por um nome de `clusterrolebinding` retornado na saída do comando anterior.
```
kubectl describe clusterrolebinding cluster-role-binding-name
```
Veja abaixo um exemplo de saída.
```
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: eks-console-dashboard-full-access-binding
subjects:
- kind: Group
name: eks-console-dashboard-full-access-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: eks-console-dashboard-full-access-clusterrole
apiGroup: rbac.authorization.k8s.io
```
1. Edite o `ConfigMap` `aws-auth`. É possível usar uma ferramenta como o `eksctl` para atualizar o `ConfigMap`, ou você pode atualizá-lo manualmente via edição.
**Importante**
Convém usar `eksctl` ou outra ferramenta para editar o `ConfigMap`. Para obter informações sobre outras ferramentas que você pode usar, consulte [Usar ferramentas para fazer alterações no aws-authConfigMap](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#use-tools-to-make-changes-to-the-aws-auth-configmap) nos guias de práticas recomendadas do Amazon EKS. Um `aws-auth` `ConfigMap` formatado incorretamente pode fazer com que você perca o acesso ao cluster.
+ Veja as etapas para [editar o configmap com eksctl](#configmap-eksctl).
+ Veja as etapas para [editar o configmap manualmente](#configmap-manual).
### Editar o configmap com eksctl
1. Você precisa da versão `0.215.0` ou posterior da ferramenta de linha de comando da `eksctl` instalada no seu dispositivo ou AWS CloudShell. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
1. Visualize os mapeamentos atuais no `ConfigMap`. Substitua *my-cluster* pelo nome do cluster. Substitua *region-code* pela região da AWS em que seu cluster se encontra.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Veja um exemplo de saída abaixo.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
```
1. Adicione um mapeamento referente a uma função. Substitua *my-role* pelo nome da sua função. Substitua *eks-console-dashboard-full-access-group* pelo nome do grupo especificado no objeto `RoleBinding` ou `ClusterRoleBinding` do Kubernetes. Substitua *111122223333* pelo ID da sua conta. Você pode substituir *admin* por qualquer nome que escolher.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:role/my-role --username admin --group eks-console-dashboard-full-access-group \
--no-duplicate-arns
```
**Importante**
O ARN da função não pode incluir um caminho, como `role/my-team/developers/my-role`. O formato do ARN deve ser ` arn:aws:iam::111122223333:role/my-role `. Neste exemplo, `my-team/developers/` precisa ser removido.
Veja um exemplo de saída abaixo.
```
[...]
2022-05-09 14:51:20 [ℹ] adding identity "{arn-aws}iam::111122223333:role/my-role" to auth ConfigMap
```
1. Adicione um mapeamento referente a um usuário. [As melhores práticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recomendam que você conceda permissões para perfis e não para usuários. Substitua *my-user* pelo seu nome de usuário. Substitua *eks-console-dashboard-restricted-access-group* pelo nome do grupo especificado na `RoleBinding` ou `ClusterRoleBinding` do Kubernetes. Substitua *111122223333* pelo ID da sua conta. Você pode substituir *my-user* por qualquer nome que escolher.
```
eksctl create iamidentitymapping --cluster my-cluster --region=region-code \
--arn arn:aws:iam::111122223333:user/my-user --username my-user --group eks-console-dashboard-restricted-access-group \
--no-duplicate-arns
```
Veja um exemplo de saída abaixo.
```
[...]
2022-05-09 14:53:48 [ℹ] adding identity "arn:aws:iam::111122223333:user/my-user" to auth ConfigMap
```
1. Visualize os mapeamentos no `ConfigMap` novamente.
```
eksctl get iamidentitymapping --cluster my-cluster --region=region-code
```
Veja abaixo um exemplo de saída.
```
ARN USERNAME GROUPS ACCOUNT
arn:aws:iam::111122223333:role/eksctl-my-cluster-my-nodegroup-NodeInstanceRole-1XLS7754U3ZPA system:node:{{EC2PrivateDNSName}} system:bootstrappers,system:nodes
arn:aws:iam::111122223333:role/admin my-role eks-console-dashboard-full-access-group
arn:aws:iam::111122223333:user/my-user my-user eks-console-dashboard-restricted-access-group
```
### Editar o configmap manualmente
1. Abra o `ConfigMap` para edição.
```
kubectl edit -n kube-system configmap/aws-auth
```
**nota**
Se você receber um erro informando "`Error from server (NotFound): configmaps "aws-auth" not found`", use o procedimento em [Aplicar o ConfigMap aws-auth ao seu cluster](#aws-auth-configmap) para aplicar o estoque `ConfigMap`.
1. Adicione as entidades principais do IAM ao `ConfigMap`. Um grupo do IAM não é uma entidade principal do IAM, portanto, não pode ser adicionado ao `ConfigMap`.
+ **Para adicionar uma função do IAM (por exemplo, para [usuários federados](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers.html)):** adicione os detalhes da função à seção `mapRoles` do `ConfigMap` em `data`. Adicione essa seção se ela ainda não existir no arquivo. Cada entrada oferece suporte aos seguintes parâmetros:
+ **rolearn**: o ARN da função do IAM a ser adicionada. Esse valor não pode incluir um caminho. Por exemplo, não é possível especificar um ARN como ` arn:aws:iam::111122223333:role/my-team/developers/role-name `. O ARN precisa ser ` arn:aws:iam::111122223333:role/role-name `.
+ **username**: o nome do usuário no Kubernetes a ser mapeado para a função do IAM.
+ **groups**: o grupo ou a lista de grupos do Kubernetes para o qual mapear a função. O grupo pode ser padrão ou um grupo especificado em um `clusterrolebinding` ou `rolebinding`. Para obter mais informações, consulte [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) na documentação do Kubernetes.
+ **Para adicionar um usuário do IAM:** [as melhores práticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html) recomendam que você conceda permissões para perfis e não para usuários. Adicione os detalhes do usuário à seção `mapUsers` do `ConfigMap` em `data`. Adicione essa seção se ela ainda não existir no arquivo. Cada entrada oferece suporte aos seguintes parâmetros:
+ **userarn**: o ARN do usuário do IAM a ser adicionado.
+ **username**: o nome do usuário no Kubernetes a ser mapeado para o usuário do IAM.
+ **groups**: o grupo, ou a lista de grupos, do Kubernetes para o qual mapear o usuário. O grupo pode ser padrão ou um grupo especificado em um `clusterrolebinding` ou `rolebinding`. Para obter mais informações, consulte [Default roles and role bindings](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#default-roles-and-role-bindings) na documentação do Kubernetes.
1. Por exemplo, o seguinte bloco YAML contém:
+ Uma seção `mapRoles` que mapeia a instância do nó do IAM para grupos do Kubernetes, para que os nós possam se registrar no cluster e o perfil do IAM `my-console-viewer-role` que é mapeado para um grupo do Kubernetes que pode visualizar todos os recursos do Kubernetes para todos os clusters. Para acessar uma lista das permissões de grupos do IAM e do Kubernetes necessárias para o perfil do IAM `my-console-viewer-role`, consulte [Permissões obrigatórias](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
+ Uma seção `mapUsers` que mapeia o usuário do IAM `admin` da conta da AWS padrão para o grupo do Kubernetes `system:masters` e o usuário `my-user` de uma conta da AWS diferente mapeada para um grupo do Kubernetes que pode visualizar recursos do Kubernetes de um namespace específico. Para acessar uma lista das permissões de grupos do IAM e do Kubernetes necessárias para o usuário do IAM `my-user`, consulte [Permissões obrigatórias](view-kubernetes-resources.md#view-kubernetes-resources-permissions).
Adicione ou remova linhas conforme necessário e substitua todos os valores de exemplo por seus próprios valores.
```
# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam::111122223333:role/my-role
username: system:node:{{EC2PrivateDNSName}}
- groups:
- eks-console-dashboard-full-access-group
rolearn: arn:aws:iam::111122223333:role/my-console-viewer-role
username: my-console-viewer-role
mapUsers: |
- groups:
- system:masters
userarn: arn:aws:iam::111122223333:user/admin
username: admin
- groups:
- eks-console-dashboard-restricted-access-group
userarn: arn:aws:iam::444455556666:user/my-user
username: my-user
```
1. Salve o arquivo e saia do seu editor de texto.
## Como aplicar o `ConfigMap` `aws-auth` ao seu cluster
O `ConfigMap` `aws-auth` é criado e aplicado automaticamente ao cluster ao criar um grupo de nós gerenciados ou ao criar um grupo de nós usando `eksctl`. Ele é criado inicialmente para permitir que os nós ingressem no cluster, mas você também pode usar esse `ConfigMap` para adicionar acesso com controle de acesso baseado em função (RBAC) às entidades principais do IAM. Se já tiver iniciado os nós autogerenciados, mas ainda não tiver aplicado o `ConfigMap` `aws-auth` ao seu cluster, você poderá fazer isso usando o procedimento a seguir.
1. Verifique se você já aplicou o `ConfigMap` `aws-auth`.
```
kubectl describe configmap -n kube-system aws-auth
```
Se você receber um erro informando " `Error from server (NotFound): configmaps "aws-auth" not found` ", prossiga com as etapas a seguir para aplicar o estoque `ConfigMap`.
1. Faça download, edite e aplique o mapa de configuração do autenticador da AWS.
1. Faça download do mapa de configuração.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. No arquivo `aws-auth-cm.yaml`, defina o `rolearn` como o nome de recurso da Amazon (ARN) da função do IAM associada aos seus nós. Você pode fazer isso com um editor de texto ou substituindo *my-node-instance-role* e executando o seguinte comando:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
Não modifique outras linhas do arquivo.
**Importante**
O ARN da função não pode incluir um caminho, como `role/my-team/developers/my-role`. O formato do ARN deve ser ` arn:aws:iam::111122223333:role/my-role `. Neste exemplo, `my-team/developers/` precisa ser removido.
Você pode inspecionar as saídas da pilha do AWS CloudFormation para seus grupos de nós e procurar os seguintes valores:
+ **InstanceRoleARN**: para grupos de nós que foram criados com `eksctl`
+ **NodeInstanceRole** - Para grupos de nós que foram criados com os modelos do Amazon EKS fornecidos pelo AWS CloudFormation no Console de gerenciamento da AWS
1. Aplique a configuração. Esse comando pode demorar alguns minutos para ser concluído.
```
kubectl apply -f aws-auth-cm.yaml
```
**nota**
Se você receber qualquer erro de autorização ou de tipo de recurso, consulte [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized) no tópico de solução de problemas.
1. Observe o status de seus nós e aguarde até que eles atinjam o status `Ready`.
```
kubectl get nodes --watch
```
Insira `Ctrl`\$1`C` para retornar a um prompt de shell.
# Conceder aos usuários acesso ao Kubernetes com um provedor OIDC externo
O Amazon EKS oferece suporte ao uso de provedores de identidade OpenID Connect (OIDC) como um método de autenticação de usuários no cluster. Provedores de identidade OIDC podem ser usados com ou como alternativa ao AWS Identity and Access Management (IAM). Para obter mais informações sobre como usar a IAM, consulte [Conceder aos usuários e perfis do IAM acesso às APIs do Kubernetes](grant-k8s-access.md). Depois de configurar a autenticação do cluster, você pode criar a `roles` e `clusterroles` do Kubernetes para atribuir permissões às funções e, em seguida, vincular as funções às identidades usando o Kubernetes `rolebindings` e `clusterrolebindings`. Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
+ Você pode associar um provedor de identidade OIDC ao cluster.
+ O Kubernetes não fornece um provedor de identidade OIDC. Você pode usar um provedor de identidade OIDC público existente ou executar seu próprio provedor de identidade. Para uma lista de provedores certificados, consulte [OpenID Certification](https://openid.net/certification/) (Certificação OpenID) no site OpenID.
+ O URL do emissor do provedor de identidade OIDC deve ser acessível publicamente, para que o Amazon EKS possa descobrir as chaves de assinatura. O Amazon EKS não é compatível com provedores de identidade OIDC com certificados autoassinados.
+ Não é possível desabilitar a autenticação IAM em seu cluster, porque ela ainda é necessária para juntar nós a um cluster.
+ Um cluster do Amazon EKS ainda deve ser criado por uma [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) da AWS em vez de um usuário do provedor de identidade do OIDC. Isso ocorre porque o criador do cluster interage com as APIs do Amazon EKS, em vez das APIs do Kubernetes.
+ Os usuários autenticados pelo provedor de identidade OIDC serão listados no log de auditoria do cluster se os logs do CloudWatch estiverem ativados para o ambiente de gerenciamento. Para obter mais informações, consulte [Habilitar ou desabilitar os logs do ambiente de gerenciamento](control-plane-logs.md#enabling-control-plane-log-export).
+ Não é possível fazer login no Console de gerenciamento da AWS com uma conta de um provedor OIDC. Você só pode [Visualize os recursos do Kubernetes na seção Console de gerenciamento da AWS](view-kubernetes-resources.md) fazendo login no Console de gerenciamento da AWS com uma conta do AWS Identity and Access Management.
## Associe um provedor de identidade OIDC
Antes de associar um provedor de identidade OIDC ao cluster, você precisa das seguintes informações do seu provedor:
**URL do emissor**
URL do provedor de identidade do OIDC que permite que o servidor de API descubra as chaves de assinatura públicas para verificar tokens. O URL deve começar com `https://` e deve corresponder à reivindicação `iss` nos tokens de ID do OIDC do provedor. De acordo com o padrão OIDC, os componentes de caminho são permitidos, mas os parâmetros de consulta não são. Normalmente, o URL consiste apenas em um nome de host, como `https://server.example.org` ou `https://example.com`. Este URL deve apontar para o nível abaixo de `.well-known/openid-configuration` e deve ser acessível ao público pela Internet.
**ID do cliente (também conhecido como *público*)**
O ID da aplicação do cliente que faz solicitações de autenticação ao provedor de identidades OIDC.
Você pode associar um provedor de identidade usando o `eksctl` ou o Console de gerenciamento da AWS.
### Associar um provedor de identidade usando o eksctl
1. Crie um arquivo denominado `associate-identity-provider.yaml` com os conteúdos a seguir. Substitua os valores de exemplo pelos seus próprios. Os valores na seção `identityProviders` são obtidos do seu provedor de identidade OIDC. Os valores são necessários apenas para as configurações `name`, `type`, `issuerUrl` e `clientId` em `identityProviders`.
```
---
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: my-cluster
region: your-region-code
identityProviders:
- name: my-provider
type: oidc
issuerUrl: https://example.com
clientId: kubernetes
usernameClaim: email
usernamePrefix: my-username-prefix
groupsClaim: my-claim
groupsPrefix: my-groups-prefix
requiredClaims:
string: string
tags:
env: dev
```
**Importante**
Não especifique o `system:`, ou qualquer parte dessa string, para `groupsPrefix` ou `usernamePrefix`.
1. Crie o provedor.
```
eksctl associate identityprovider -f associate-identity-provider.yaml
```
1. Para usar o `kubectl` para trabalhar com o cluster e o provedor de identidade OIDC, consulte [Utilizando kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) na documentação do Kubernetes.
### Associe um provedor de identidade usando o console AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Selecione seu cluster e, em seguida, selecione a guia **Acesso**.
1. Na seção **Provedores de identidade OIDC**, selecione\$1 Provedor de identidade do associado\$1.
1. Na página **Associate OIDC Identity Provider** (Provedor de identidade OIDC), insira ou selecione as opções a seguir e escolha **Associate** (Associar).
+ Em **Name** (Nome), insira um nome exclusivo para o provedor.
+ Para **Issuer URL** (URL do emissor), insira a URL do seu provedor. Este URL deve ser acessado pela Internet.
+ Em **ID do cliente**, insira o ID do cliente do provedor de identidade OIDC (também conhecido como **público**).
+ Para o **Username claim** (Reivindicação do usuário), insira a reivindicação a ser usada como nome de usuário.
+ Para o **Username claim** (Reivindicação do usuário), insira a reivindicação a ser usada como grupo de usuários.
+ (Opcional) Selecione **Advanced options** (Opções avançadas) e insira ou selecione as informações a seguir.
+ **Username prefix** (Prefixo do usuário): insira um prefixo para preceder as reivindicações de nome de usuário. O prefixo precede as reivindicações de nome de usuário para evitar conflitos com nomes existentes. Se você não fornecer um valor e o nome de usuário for um valor diferente de `email`, o prefixo assume como padrão o valor para a **URL do emissor**. Você pode usar o valor ` -` para desativar todos os prefixos. Não especifique o `system:`, ou qualquer parte dessa string.
+ **Groups prefix** (Prefixo de grupos): insira um prefixo para preceder as reivindicações de grupos. O prefixo precede as reivindicações de nome de usuário para evitar conflitos com nomes existentes (como ` system: groups`). Por exemplo, o valor `oidc:` cria nomes de grupos como `oidc:engineering` e `oidc:infra`. Não especifique o `system:`, ou qualquer parte dessa string.
+ **Required claims** (Reivindicações necessárias): selecione **Add claim (adicionar reivindicação)** e insira um ou mais pares de valor de chave que descrevam as reivindicações necessárias no token de ID do cliente. Os pares descrevem as reivindicações obrigatórias no token de ID. Se definido, cada reivindicação é verificada para estar presente no token de ID com um valor correspondente.
1. Para usar o `kubectl` para trabalhar com o cluster e o provedor de identidade OIDC, consulte [Utilizando kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) na documentação do Kubernetes.
## Exemplo de política do IAM
Se você quiser impedir que um provedor de identidade OIDC seja associado a um cluster, crie e associe a seguinte política do IAM às contas do IAM dos seus administradores do Amazon EKS. Para obter mais informações, consulte [Criação de políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) e [Adição de permissões de identidade do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html#add-policies-console) no *Guia do usuário do IAM* e [Ações](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelasticcontainerserviceforkubernetes.html) na Referência de autorização do serviço.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "denyOIDC",
"Effect": "Deny",
"Action": [
"eks:AssociateIdentityProviderConfig"
],
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/*"
},
{
"Sid": "eksAdmin",
"Effect": "Allow",
"Action": [
"eks:*"
],
"Resource": "*"
}
]
}
```
A política de exemplo a seguir permite a associação do provedor de identidade OIDC se o `clientID` for `kubernetes` e a `issuerUrl` for `https://cognito-idp.us-west-2amazonaws.com/*`.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowCognitoOnly",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotLikeIfExists": {
"eks:issuerUrl": "https://cognito-idp.us-west-2.amazonaws.com/*"
}
}
},
{
"Sid": "DenyOtherClients",
"Effect": "Deny",
"Action": "eks:AssociateIdentityProviderConfig",
"Resource": "arn:aws:eks:us-west-2:111122223333:cluster/my-instance",
"Condition": {
"StringNotEquals": {
"eks:clientId": "kubernetes"
}
}
},
{
"Sid": "AllowOthers",
"Effect": "Allow",
"Action": "eks:*",
"Resource": "*"
}
]
}
```
# Desassociar um provedor de identidade OIDC do cluster
Se você desassociar um provedor de identidade OIDC do cluster, os usuários incluídos no provedor não poderão mais acessar o cluster. No entanto, você ainda pode acessar o cluster com as [entidades principais do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal).
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na seção **OIDC Identity Providers** (Provedores de identidade OIDC), selecione **Disassociate** (Desassociar), insira o nome do provedor de identidade e selecione `Disassociate`.
# Visualize os recursos do Kubernetes na seção Console de gerenciamento da AWS
É possível visualizar os recursos do Kubernetes implantados no seu cluster com o Console de gerenciamento da AWS. Não é possível visualizar os recursos do Kubernetes com a AWS CLI ou o [eksctl](https://eksctl.io/). Para visualizar os recursos do Kubernetes usando uma ferramenta de linha de comando, use [kubectl](install-kubectl.md).
**nota**
Para visualizar a guia **Recursos** e a seção **Nós** na guia **Computação** no Console de gerenciamento da AWS, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que você está usando deve ter permissões específicas do IAM e do Kubernetes. Para obter mais informações, consulte [Permissões obrigatórias](#view-kubernetes-resources-permissions).
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Na lista **Clusters**, escolha o cluster que contém os recursos do Kubernetes que você deseja visualizar.
1. Selecione a guia **Recursos**.
1. Selecione um grupo **Resource type** (Tipo de recurso) cujos recursos você deseja visualizar, como **Workloads**. Você visualizará uma lista de tipos de recursos nesse grupo.
1. Selecione um tipo de recurso, como **Deployments** (Implantações), no grupo **Workloads**. Você verá uma descrição do tipo de recurso, um link para a documentação do Kubernetes para obter mais informações sobre esse tipo, bem como uma lista de recursos desse tipo implantados no cluster. Se essa lista estiver vazia, significa que não há recursos desse tipo implantados no cluster.
1. Selecione um recurso para exibir mais informações sobre ele. Teste os exemplos a seguir:
+ Selecione o grupo **Workloads**, escolha o tipo de recurso **Deployments** (Implantações) e depois selecione o recurso **coredns**. Por padrão, ao selecionar um recurso, você está em **Structured view** (Visualização estruturada). Para alguns tipos de recursos, há uma seção **Pods** em **Structured view** (Visualização estruturada). Esta seção lista os pods gerenciados pela workload. É possível selecionar qualquer pod listado para visualizar as informações sobre o pod. Nem todos os tipos de recursos mostram informações em **Structured view** (Visualização estruturada). Se a opção **Raw view** (Visualização bruta) for selecionada no canto superior direito da página do recurso, será possível ver a resposta JSON completa da API do Kubernetes para esse recurso.
+ Selecione o grupo **Cluster** e depois o tipo de recurso **Nodes** (Nós). Você verá uma lista com todos os nós do seu cluster. Esses nós podem ser de qualquer [Tipo de nó do Amazon EKS](eks-compute.md). Esta é a mesma lista visível na seção **Nodes** (Nós) ao selecionar a guia **Compute** (Computação) do seu cluster. Escolha um recurso de nó da lista. Em **Structured view** (Visualização estruturada), também é possível ver uma seção **Pods**. Esta seção mostra todos os pods em execução no nó.
## Permissões obrigatórias
Para visualizar a guia **Recursos** e a seção **Nós** na guia **Computação** no Console de gerenciamento da AWS, a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) que você está usando deve ter permissões mínimas específicas do IAM e do Kubernetes. É necessário ter as permissões de RBAC do IAM e do Kubernetes configuradas corretamente. Conclua as seguintes etapas para atribuir as permissões necessárias às entidades principais do IAM.
1. Verifique se `eks:AccessKubernetesApi` e as outras permissões necessárias do IAM para visualizar os recursos do Kubernetes estão atribuídas à entidade principal do IAM que você está usando. Para obter mais informações sobre como editar permissões para uma entidade principal do IAM, consulte [Controle de acesso das entidades principais](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-principals) no Guia do usuário do IAM. Para saber mais sobre como editar as permissões de um perfil, consulte [Modificar a política de permissões de um perfil (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/roles-managingrole-editing-console.html#roles-modify_permissions-policy), no Guia do usuário do IAM.
O exemplo de política a seguir inclui as permissões necessárias para uma entidade principal visualizar os recursos do Kubernetes de todos os clusters da conta. Substitua *111122223333* pelo ID de sua conta da AWS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks:ListFargateProfiles",
"eks:DescribeNodegroup",
"eks:ListNodegroups",
"eks:ListUpdates",
"eks:AccessKubernetesApi",
"eks:ListAddons",
"eks:DescribeCluster",
"eks:DescribeAddonVersions",
"eks:ListClusters",
"eks:ListIdentityProviderConfigs",
"iam:ListRoles"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ssm:GetParameter",
"Resource": "arn:aws:ssm:*:111122223333:parameter/*"
}
]
}
```
Para visualizar nós em [clusters conectados](eks-connector.md), o [perfil do IAM do conector do Amazon EKS](connector-iam-role.md) deve ser capaz de representar a entidade principal no cluster. Isso permite que o [Amazon EKS Connector](eks-connector.md) mapeie a entidade principal para um usuário do Kubernetes.
1. Configure as permissões de RBAC do Kubernetes usando entradas de acesso do EKS.
**O que são entradas de acesso ao EKS?**
As entradas de acesso do EKS são uma forma simplificada de conceder às entidades principais do IAM (usuários e perfis) acesso ao seu cluster de Kubernetes. Em vez de gerenciar manualmente os recursos de RBAC do Kubernetes e o `aws-auth` ConfigMap, as entradas de acesso lidam automaticamente com o mapeamento entre as permissões do IAM e do Kubernetes usando políticas gerenciadas fornecidas pela AWS. Para obter informações detalhadas sobre as entradas de acesso, consulte [Conceder aos usuários do IAM acesso ao Kubernetes com entradas de acesso ao EKS](access-entries.md). Para obter informações sobre as políticas de acesso disponíveis e suas permissões, consulte [Permissões da política de acesso](https://docs.aws.amazon.com/eks/latest/userguide/access-policy-permissions.html).
É possível conceder permissões do Kubernetes às entradas de acesso de duas maneiras:
+ **Use uma política de acesso:** as políticas de acesso são modelos de permissões do Kubernetes definidos previamente e mantidos pela AWS. Eles pela conceituação de conjuntos de permissões padronizados para casos de uso comuns.
+ **Referencie um grupo de Kubernetes**: se você associar uma identidade do IAM a um grupo do Kubernetes, será possível criar recursos do Kubernetes que concedam permissões ao grupo. Para obter mais informações, consulte [Usar a autorização de RBAC](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) na documentação do Kubernetes.
1. Crie uma entrada de acesso para sua entidade principal do IAM usando a CLI da AWS. Substitua *my-cluster* pelo nome do cluster. Substitua *111122223333* pelo ID da sua conta.
```
aws eks create-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
Veja abaixo um exemplo de saída.
```
{
"accessEntry": {
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:region-code:111122223333:access-entry/my-cluster/role/111122223333/my-console-viewer-role/abc12345-1234-1234-1234-123456789012",
"createdAt": "2024-03-15T10:30:45.123000-07:00",
"modifiedAt": "2024-03-15T10:30:45.123000-07:00",
"tags": {},
"username": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"type": "STANDARD"
}
}
```
1. Associe uma política à entrada de acesso. Para visualizar os recursos do Kubernetes, use a `AmazonEKSViewPolicy`:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster
```
Veja abaixo um exemplo de saída.
```
{
"clusterName": "my-cluster",
"principalArn": "arn:aws:iam::111122223333:role/my-console-viewer-role",
"associatedAt": "2024-03-15T10:31:15.456000-07:00"
}
```
Para acesso específico do namespace, é possível definir o escopo da política para namespaces específicos:
```
aws eks associate-access-policy \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=default,kube-system
```
1. Verifique se a entrada de acesso foi criada com êxito:
```
aws eks describe-access-entry \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
1. Liste as políticas associadas para confirmar a associação da política:
```
aws eks list-associated-access-policies \
--cluster-name my-cluster \
--principal-arn arn:aws:iam::111122223333:role/my-console-viewer-role
```
Veja abaixo um exemplo de saída.
```
{
"associatedAccessPolicies": [
{
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster"
},
"associatedAt": "2024-03-15T10:31:15.456000-07:00",
"modifiedAt": "2024-03-15T10:31:15.456000-07:00"
}
]
}
```
## Visibilidade do CloudTrail
Ao visualizar os recursos do Kubernetes, você verá o nome de operação a seguir nos seus logs do CloudTrail:
+ `AccessKubernetesApi`: ao ler ou visualizar recursos
Esse evento do CloudTrail fornece uma trilha de auditoria do acesso de leitura aos seus recursos de Kubernetes.
**nota**
Esse nome da operação aparece nos logs do CloudTrail somente para fins de auditoria. Ele não é uma ação do IAM e não podem ser usado nas declarações de política do IAM. Para controlar o acesso de leitura aos recursos do Kubernetes por meio de políticas do IAM, use a permissão `eks:AccessKubernetesApi` conforme mostrado na seção [Permissões obrigatórias](#view-kubernetes-resources-permissions).
# Concessão de acesso de gravação às APIs do Kubernetes pra serviços da AWS
## Permissões obrigatórias
Para permitir que os serviços da AWS executem operações de gravação em recursos do Kubernetes em seu cluster do Amazon EKS, é necessário conceder as permissões `eks:AccessKubernetesApi` e `eks:MutateViaKubernetesApi` do IAM.
Por exemplo, o Amazon SageMaker HyperPod usa essas permissões para permitir a implantação de modelos a partir do SageMaker AI Studio. Para obter mais informações, consulte [Configuração de permissões opcionais do SDK de JavaScript](https://docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-hyperpod-model-deployment-setup.html#sagemaker-hyperpod-model-deployment-setup-optional-js) no Guia de desenvolvedor do Amazon SageMaker AI.
**Importante**
Operações de gravação, como criar, atualizar e excluir, exigem ambas as permissões. Se alguma permissão estiver ausente, as operações de gravação falharão.
## Visibilidade do CloudTrail
Ao realizar operações de gravação em recursos do Kubernetes, você verá nomes específicos de operações em seus logs do CloudTrail:
+ `createKubernetesObject`: ao criar novos recursos
+ `updateKubernetesObject`: ao modificar os recursos existentes
+ `deleteKubernetesObject`: ao remover recursos
Esses eventos do CloudTrail fornecem trilhas de auditoria detalhadas de todas as modificações feitas em seus recursos do Kubernetes.
**nota**
Esses nomes de operação aparecem nos logs do CloudTrail somente para fins de auditoria. Eles não são ações do IAM e não podem ser usados nas declarações de política do IAM. Para controlar o acesso de gravação aos recursos do Kubernetes por meio de políticas do IAM, use a permissão `eks:MutateViaKubernetesApi` conforme mostrado na seção [Permissões obrigatórias](#mutate-kubernetes-resources-permissions).
# Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig
**dica**
[Registre-se](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) para os próximos workshops do Amazon EKS.
Neste tópico, você cria um arquivo `kubeconfig` para o cluster (ou atualiza um existente).
A ferramenta da linha de comando `kubectl` usa informações de configuração em arquivos `kubeconfig` para se comunicar com o servidor de API de um cluster. Para obter mais informações, consulte [Organizando o acesso ao cluster usando arquivos kubeconfig](https://kubernetes.io/docs/concepts/configuration/organize-cluster-access-kubeconfig/) na documentação do Kubernetes.
O Amazon EKS usa o comando `aws eks get-token` com `kubectl` para autenticação de cluster. Por padrão, a AWS CLI usa as mesmas credenciais que são retornadas com o seguinte comando:
```
aws sts get-caller-identity
```
+ Um cluster existente do Amazon EKS. Para implantar, consulte [Começar a usar o Amazon EKS](getting-started.md).
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, será possível usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ Um usuário ou perfil do IAM com permissão para usar a ação de API `eks:DescribeCluster` para o cluster que você especificar. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade do Amazon EKS](security-iam-id-based-policy-examples.md). Se você usar uma identidade do seu próprio provedor OpenID Connect para acessar o cluster, consulte [Utilizando kubectl](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#using-kubectl) na documentação do Kubernetes para criar ou atualizar o arquivo `kube config`.
## Criar arquivo `kubeconfig` automaticamente
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ Permissão para usar a ação de API `eks:DescribeCluster` para o cluster que você especificar. Para obter mais informações, consulte [Exemplos de políticas baseadas em identidade do Amazon EKS](security-iam-id-based-policy-examples.md).
1. Crie um arquivo `kubeconfig` para o cluster. Substitua *region-code* pela região AWS em que seu cluster se encontra e substitua *my-cluster* pelo nome do seu cluster.
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Por padrão, o arquivo de configuração resultante é criado no caminho padrão do `kubeconfig` (`.kube`) em seu diretório inicial ou mesclado com um `config` existente no local. É possível especificar outro caminho com a opção `--kubeconfig`.
É possível especificar um ARN de função do IAM com a opção `--role-arn` para uso na autenticação quando você emitir comandos `kubectl`. Caso contrário, será usada a [entidade principal do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) em sua cadeia de credenciais padrão da AWS CLI ou SDK. É possível visualizar sua identidade padrão AWS CLI ou SDK executando o comando `aws sts get-caller-identity`.
Para obter todas as opções disponíveis, execute o comando `aws eks update-kubeconfig help` ou consulte [update-kubeconfig](https://docs.aws.amazon.com/cli/latest/reference/eks/update-kubeconfig.html) em * AWS CLI Command Reference*.
1. Teste a configuração.
```
kubectl get svc
```
Veja um exemplo de saída abaixo.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
svc/kubernetes ClusterIP 10.100.0.1 443/TCP 1m
```
Se você receber qualquer erro de autorização ou de tipo de recurso, consulte [Acesso negado ou não autorizado (`kubectl`)](troubleshooting.md#unauthorized) no tópico de solução de problemas.
# Conceder às workloads do Kubernetes acesso a AWS usando contas de serviço do Kubernetes
[Gerenciar contas de serviço](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin)[Funções do IAM para contas de serviço](iam-roles-for-service-accounts.md)[Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md)
## Tokens de contas de serviço
O recurso [BoundServiceAccountTokenVolume](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/#bound-service-account-token-volume) é habilitado por padrão nas versões do Kubernetes. Esse recurso melhora a segurança dos tokens de contas de serviço, permitindo que workloads em execução no Kubernetes solicitem tokens da Web JSON que são público-alvo, hora e chave vinculados. Tokens de contas de serviço têm uma expiração de uma hora. Em versões anteriores do Kubernetes, os tokens não tinham expiração. Isso significa que os clientes que dependem desses tokens precisam atualizá-los em até uma hora. Os seguintes exemplos de [SDKs cliente Kubernetes](https://kubernetes.io/docs/reference/using-api/client-libraries/) atualizam tokens automaticamente no período de tempo necessário:
+ Versão do Go `0.15.7` e posteriores
+ Versão do Python `12.0.0` e posteriores
+ Versão Java `9.0.0` e posterior
+ Versão JavaScript `0.10.3` e posterior
+ Ramificação Ruby `master`
+ Versão do Haskell `0.3.0.0`
+ Versão `7.0.5` e mais recente do C\$1
Se sua workload estiver usando uma versão anterior do cliente, você deverá atualizá-la. Para possibilitar uma migração suave de clientes para os tokens de conta de serviço com limite de tempo mais recentes, o Kubernetes adiciona um período de expiração estendido ao token da conta de serviço além do tempo padrão de uma hora. Para clusters do Amazon EKS, o período de expiração prolongado equivale a 90 dias. O servidor de API do Kubernetes do cluster de Amazon EKS rejeita solicitações com tokens com mais de 90 dias. É recomendável verificar as aplicações e suas dependências para garantir que os SDKs de cliente do Kubernetes sejam iguais ou posteriores às versões listadas anteriormente.
Quando o servidor de API recebe solicitações com tokens com mais de uma hora, ele anota o evento de logs de auditoria da API com `annotations.authentication.k8s.io/stale-token`. O valor da anotação é parecido com o exemplo a seguir:
```
subject: system:serviceaccount:common:fluent-bit, seconds after warning threshold: 4185802.
```
Se o cluster tiver [registro em log do ambiente de gerenciamento](control-plane-logs.md) habilitado, as anotações estarão nos logs de auditoria. Você pode usar a seguinte consulta do [CloudWatch Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) para identificar todos os pods no cluster de Amazon EKS que estejam usando tokens obsoletos:
```
fields @timestamp
|filter @logStream like /kube-apiserver-audit/
|filter @message like /seconds after warning threshold/
|parse @message "subject: *, seconds after warning threshold:*\"" as subject, elapsedtime
```
O `subject` refere-se à conta de serviço que o pod usou. O `elapsedtime` indica o tempo decorrido (em segundos) após a leitura do token mais recente. As solicitações para o servidor de API são negadas quando o `elapsedtime` excede 90 dias (7.776.000 segundos). É necessário atualizar de forma proativa o SDK do cliente do Kubernetes das aplicações para usar uma das versões listadas anteriormente que atualizam o token de modo automático. Se o token da conta de serviço usado estiver se aproximando dos 90 dias e você não tiver tempo suficiente para atualizar as versões do SDK do cliente antes da expiração desse token, então será possível encerrar os pods existentes e criar novos. Isso provoca a reformulação do token da conta de serviço, fornecendo mais 90 dias para você atualizar os SDKs da versão do cliente.
Se o pod fizer parte de uma implantação, a maneira sugerida de encerrar pods e, ao mesmo tempo, manter a alta disponibilidade é executar uma implantação com o comando a seguir. Substitua *my-deployment* pelo nome da sua implantação.
```
kubectl rollout restart deployment/my-deployment
```
## Complementos de cluster
Os complementos de cluster a seguir foram atualizados para usar os SDKs de cliente do Kubernetes que redefinem os tokens de contas de serviço automaticamente. Convém garantir que as versões listadas ou posteriores estejam instaladas no seu cluster.
+ Versão `1.8.0` e mais recente do plug-in CNI da Amazon VPC para Kubernetes ou do auxiliar de métricas. Para verificar sua versão atual ou atualizá-la, consulte [Atribuir IPs a pods com a CNI da Amazon VPC](managing-vpc-cni.md) e [cni-metrics-helper](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/cmd/cni-metrics-helper/README.md).
+ Versão `1.8.4` e mais recente do CoreDNS. Para conferir sua versão atual ou atualizá-la, consulte [Gerenciar o CoreDNS para DNS em clusters do Amazon EKS](managing-coredns.md).
+ Versão `2.0.0` e mais recente do AWS Load Balancer Controller. Para conferir sua versão atual ou atualizá-la, consulte [Direcionar o tráfego da Internet com o AWS Load Balancer Controller](aws-load-balancer-controller.md).
+ Uma Versão atual do `kube-proxy`. Para conferir sua versão atual ou atualizá-la, consulte [Gerenciar o `kube-proxy` em clusters do Amazon EKS](managing-kube-proxy.md).
+ AWS para a versão Fluent Bit `2.25.0` ou posterior. Para atualizar sua versão atual, consulte [Releases](https://github.com/aws/aws-for-fluent-bit/releases), no GitHub
+ Versão de imagem do Fluentd [1.14.6-1.2](https://hub.docker.com/r/fluent/fluentd/tags?page=1&name=v1.14.6-1.2) ou posterior e plugin de filtro do Fluentd para metadados do Kubernetes versão [2.11.1](https://rubygems.org/gems/fluent-plugin-kubernetes_metadata_filter/versions/2.11.1) ou posterior.
## Concessão de permissões do AWS Identity and Access Management para workloads em clusters do Amazon Elastic Kubernetes Service
O Amazon EKS oferece duas maneiras de conceder permissões de gerenciamento de acesso e identidade AWS a workloads executadas em clusters do Amazon EKS: *Funções de IAM para contas de serviço* e *identidades de pod do EKS*.
**Perfis do IAM para contas de serviço**
Os *perfis do IAM para contas de serviço (IRSA)* configuram aplicações Kubernetes em execução na AWS com permissões minuciosas do IAM para acessar vários outros recursos da AWS, como buckets do Amazon S3, tabelas do Amazon DynamoDB e muito mais. É possível executar várias aplicações juntas no mesmo cluster de Amazon EKS e garantir que cada aplicação tenha apenas o conjunto mínimo de permissões de que precisa. O IRSA foi criado para ser compatível com várias opções de implementação do Kubernetes com suporte da AWS, como o Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service na AWS e clusters autogerenciados do Kubernetes em instâncias do Amazon EC2. Assim, o IRSA foi criado usando um serviço da AWS básico, como o IAM, e não dependia diretamente do serviço Amazon EKS e da API do EKS. Para obter mais informações, consulte [Funções do IAM para contas de serviço](iam-roles-for-service-accounts.md).
**EKS Pod Identities**
O EKS Pod Identity oferece aos administradores de clusters um fluxo de trabalho simplificado para autenticar aplicações para acessar vários outros recursos da AWS, como buckets do Amazon S3, tabelas do Amazon DynamoDB e muito mais. O EKS Pod Identity é somente para EKS e, como resultado, simplifica como os administradores de cluster podem configurar aplicações Kubernetes para obter permissões do IAM. Essas permissões agora podem ser facilmente configuradas com menos etapas diretamente no Console de gerenciamento da AWS, na API do EKS e na AWS CLI, e não há nenhuma ação a ser executada dentro do cluster em nenhum objeto do Kubernetes. Os administradores de cluster não precisam alternar entre os serviços EKS e IAM nem usar operações privilegiadas do IAM para configurar as permissões exigidas por suas aplicações. Os perfis do IAM agora podem ser usados em vários clusters sem a necessidade de atualizar a política de confiança do perfil ao criar novos clusters. As credenciais do IAM fornecidas pelo EKS Pod Identity incluem tags de sessão de perfil, com atributos como nome do cluster, namespace e nome da conta de serviço. As tags de sessão de perfil permitem que os administradores criem um único perfil que pode funcionar em várias contas de serviço, permitindo o acesso aos recursos da AWS com base em tags correspondentes. Para obter mais informações, consulte [Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md).
### Comparação entre o EKS Pod Identity e o IRSA
Em alto nível, tanto o EKS Pod Identity quanto o IRSA permitem conceder permissões do IAM para aplicações executadas em clusters do Kubernetes. No entanto, eles são fundamentalmente diferentes na forma como você os configura, nos limites aceitos e nos recursos ativados. A seguir, comparamos algumas das principais características de ambas as soluções.
**nota**
A AWS recomenda usar as Identidades de Pod do EKS para conceder acesso aos recursos da AWS dos seus pods sempre que possível. Para obter mais informações, consulte [Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS](pod-identities.md).
| Atributo | EKS Pod Identity | IRSA |
| --- | --- | --- |
| Extensibilidade de perfis | É necessário configurar cada perfil uma vez para estabelecer confiança com a recém-introduzida entidade principal do serviço Amazon EKS `pods.eks.amazonaws.com`. Após essa etapa única, não será necessário atualizar a política de confiança do perfil sempre que ela for usada em um novo cluster. | Você precisará atualizar a política de confiança do perfil do IAM com o novo endpoint do provedor OIDC do cluster de EKS sempre que quiser usar o perfil em um novo cluster. |
| Escalabilidade de clusters | O EKS Pod Identity não exige que os usuários configurem o provedor OIDC do IAM, portanto, esse limite não se aplica. | Cada cluster de EKS tem um URL do emissor do OpenID Connect (OIDC) associado a ele. Para usar o IRSA, é necessário criar um provedor OpenID Connect exclusivo para cada cluster de EKS no IAM. O IAM tem um limite global padrão de cem provedores OIDC para cada conta da AWS. Se você planeja ter mais de cem clusters do EKS para cada conta da AWS com o IRSA, você atingirá o limite do provedor OIDC do IAM. |
| Escalabilidade de funções | O EKS Pod Identity não exige que os usuários definam uma relação de confiança entre o perfil do IAM e a conta de serviço na política de confiança, portanto, esse limite não se aplica. | No IRSA, é necessário definir a relação de confiança entre um perfil do IAM e uma conta de serviço na política de confiança do perfil. Por padrão, a duração do tamanho da política de confiança é `2048`. Isso significa que você pode definir quatro relações de confiança normalmente em uma única política de confiança. Embora seja possível aumentar o limite de duração da política de confiança, em geral você tem um limite máximo de 8 relações de confiança em uma única política de confiança. |
| Uso da cota da API do STS | A Identidade de Pods do EKS simplifica a entrega de credenciais da AWS aos seus pods e não exige que seu código faça chamadas diretamente com o AWS Security Token Service (STS). O serviço EKS lida com a atribuição de perfis e fornece credenciais para aplicações escritas usando o AWS SDK em seus pods sem que eles se comuniquem com o AWS STS ou usem a cota da API STS. | No IRSA, aplicações escritas usando o AWS SDK em seus pods usam tokens para chamar a API `AssumeRoleWithWebIdentity` no AWS Security Token Service (STS). Dependendo da lógica do seu código no AWS SDK, é possível que seu código faça chamadas desnecessárias para o AWS STS e receba erros de limitação. |
| Reutilização de perfis | AWS As credenciais temporárias do STS fornecidas pelo EKS Pod Identity incluem tags de sessão de perfil, como nome do cluster, namespace, nome da conta de serviço. As tags de sessão de perfil permitem que os administradores criem um único perfil do IAM que pode ser usado com várias contas de serviço, com diferentes permissões efetivas, permitindo acesso a recursos da AWS com base nas tags anexadas a elas. Isso também é chamado controle de acesso por atributo (ABAC). Para obter mais informações, consulte [Conceder acesso dos pods a recursos da AWS baseados em tags](pod-id-abac.md). | AWS Não há suporte para tags de sessão STS. Você pode reutilizar um perfil entre clusters, mas cada pod recebe todas as permissões do perfil. |
| Ambientes compatíveis | O EKS Pod Identity só está disponível no Amazon EKS. | O IRSA pode ser usado como o Amazon EKS, Amazon EKS Anywhere, Red Hat OpenShift Service na AWS e clusters autogerenciados do Kubernetes em instâncias do Amazon EC2. |
| Versões do EKS compatíveis | Todas as versões de cluster de EKS compatíveis. Para obter números de versão específicos, consulte [Versões de cluster do EKS Pod Identity](pod-identities.md#pod-id-cluster-versions). | Todas as versões de cluster de EKS compatíveis. |
# Funções do IAM para contas de serviço
**dica**
[Registre-se](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) para os próximos workshops do Amazon EKS.
Os aplicações nos contêineres de um Pod podem usar um SDK AWS ou a CLI AWS para fazer solicitações de API para serviços AWS usando permissões de gerenciamento de identidade e acesso (IAM) AWS. As aplicações devem assinar suas solicitações de API da AWS com as credenciais da AWS. **Os perfis do IAM para contas de serviço (IRSA)** permitem gerenciar credenciais para suas aplicações, de modo semelhante à forma como os perfis de instância do Amazon EC2 fornecem credenciais para instâncias do Amazon EC2. Em vez de criar e distribuir as credenciais da AWS para os contêineres ou usar o perfil da instância do Amazon EC2, você pode associar um perfil do IAM a uma conta de serviço do Kubernetes e configurar os pods para usar a conta de serviço. Não é possível usar perfis do IAM para contas de serviço com [clusters locais para o Amazon EKS no AWS Outposts](eks-outposts-local-cluster-overview.md).
Os perfis do IAM para contas de serviço oferecem as seguintes vantagens:
+ **Privilégio mínimo**: você pode definir o escopo das permissões do IAM para uma conta de serviço, e somente os pods que usarem essa conta de serviço terão acesso a essas permissões. Esse recurso também elimina a necessidade de soluções de terceiros, como o `kiam` ou o `kube2iam`.
+ **Isolamento de credenciais**: quando o acesso ao [serviço de metadados de instância (IMDS) do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) estiver restrito, um contêiner de pods só poderá recuperar as credenciais do perfil do IAM que estiver associado à conta de serviço que o contêiner usa. Um contêiner nunca tem acesso a credenciais usadas por outros contêineres em outros pods. Se o IMDS não estiver restrito, os contêineres do pod também terão acesso ao [perfil do IAM do nó do Amazon EKS](create-node-role.md), e os contêineres poderão obter acesso às credenciais dos perfis do IAM de outros pods no mesmo nó. Para obter mais informações, consulte [Restringir o acesso ao perfil de instância atribuído ao nó de processamento](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**nota**
Os pods configurados com `hostNetwork: true` sempre terão acesso ao IMDS, mas a CLI e os SDKs da AWS usarão as credenciais do IRSA quando habilitados.
+ **Auditabilidade**: o log de acesso e de eventos está disponível no AWS CloudTrail para ajudar a garantir a auditoria retrospectiva.
**Importante**
Os contêineres não são um limite de segurança, e o uso dos perfis do IAM para contas de serviço não muda isso. Os pods atribuídos ao mesmo nó compartilharão um kernel e possivelmente outros recursos, dependendo da configuração do pod. Embora os pods executados em nós separados sejam isolados na camada de computação, existem aplicações de nós que têm permissões adicionais na API do Kubernetes além do escopo de uma instância individual. Alguns exemplos são `kubelet`, `kube-proxy`, drivers de armazenamento CSI ou suas próprias aplicações do Kubernetes.
Habilite perfis do IAM para contas de serviço concluindo os seguintes procedimentos:
1. [Criar um provedor OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md): você só deve concluir esse procedimento uma vez para cada cluster.
**nota**
Se você habilitou o endpoint da VPC do EKS, o endpoint de serviço de OIDC do EKS não poderá ser acessado de dentro dessa VPC. Consequentemente, suas operações, como a criação de um provedor de OIDC `eksctl` dentro da VPC, não funcionarão e resultarão em um tempo limite ao tentar solicitar `https://oidc.eks.region.amazonaws.com`. Segue um exemplo de mensagem de erro:
```
server cant find oidc.eks.region.amazonaws.com: NXDOMAIN
```
Para concluir essa etapa, você pode executar o comando fora da VPC, por exemplo, no AWS CloudShell ou em um computador conectado à Internet. Como alternativa, você pode criar um resolvedor condicional de horizonte segmentado na VPC, como o Route 53 Resolver, para usar um resolvedor diferente para o URL do emissor do OIDC e não usar o DNS da VPC para ela. Para ver um exemplo de encaminhamento condicional em CoreDNS, consulte [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038) no GitHub.
1. [Atribuir perfis do IAM a contas de serviço do Kubernetes](associate-service-account-role.md): conclua este procedimento para cada conjunto exclusivo de permissões que você deseja que uma aplicação tenha.
1. [Configurar pods para usar uma conta de serviço do Kubernetes](pod-configuration.md): conclua este procedimento para cada pod que precisa de acesso aos serviços da AWS.
1. [Usar IRSA com o AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md): verifique se a workload usa um AWS SDK de uma versão compatível e se a workload usa a cadeia de credenciais padrão.
## Informações de contexto sobre IAM, Kubernetes e OpenID Connect (OIDC)
Em 2014, o AWS Identity and Access Management adicionou suporte para identidades federadas usando o OpenID Connect (OIDC). Esse recurso permite que você autentique chamadas de API da AWS com provedores de identidade compatíveis e receba um token de web JSON (JWT) OIDC válido. É possível passar esse token para a operação da API AWS STS `AssumeRoleWithWebIdentity` e receber credenciais de perfil temporária do IAM. É possível usar essas credenciais para interagir com qualquer serviço do AWS, inclusive o Amazon S3 e o DynamoDB.
Cada token JWT é assinado por um par de chaves de assinatura. As chaves são servidas no provedor OIDC gerenciado pelo Amazon EKS e a chave privada é trocada a cada 7 dias. O Amazon EKS mantém as chaves públicas até a sua expiração. Se você conectar clientes OIDC externos, esteja ciente de que precisará atualizar as chaves de assinatura antes que a chave pública expire. Saiba como [Buscar chaves de assinatura para validar tokens OIDC](irsa-fetch-keys.md).
O Kubernetes usa há muito tempo contas de serviço como seu próprio sistema de identidade interno. Os pods podem ser autenticados com o servidor de API do Kubernetes usando um token montado automaticamente (que era um JWT não OIDC) que somente o servidor de API do Kubernetes podia validar. Esses tokens de conta de serviço legados não expiram, e a rotação da chave de assinatura é um processo difícil. Na versão `1.12` do Kubernetes, foi adicionado suporte para um novo recurso `ProjectedServiceAccountToken`. Esse recurso é um JSON web token do OIDC que também contém a identidade da conta de serviço e é compatível com um público configurável.
O Amazon EKS hospeda um endpoint público de descoberta do OIDC em cada cluster que contém as chaves de assinatura para JSON web tokens `ProjectedServiceAccountToken`, de modo que sistemas externos, como o IAM, possam validar e aceitar os tokens do OIDC emitidos pelo Kubernetes.
# Criar um provedor de identidade OIDC do IAM para o cluster
O cluster tem um URL do emissor do [OpenID Connect](https://openid.net/connect/) (OIDC) associado a ele. Para usar os perfis do AWS Identity and Access Management (IAM) para contas de serviço, deve haver um provedor OIDC do IAM para o URL do emissor do OIDC do cluster.
## Pré-requisitos
+ Um cluster existente do Amazon EKS. Para implantar, consulte [Começar a usar o Amazon EKS](getting-started.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Um arquivo `kubectl` `config` existente que contém a configuração do seu cluster. Para criar um arquivo `kubectl` `config`, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
Você pode criar um provedor OIDC do IAM para o cluster usando o `eksctl` ou o Console de gerenciamento da AWS.
## Criar provedor OIDC (eksctl)
1. Versão `0.215.0` ou posterior da ferramenta de linha de comando da `eksctl` instalada no seu dispositivo ou AWS CloudShell. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
1. Determine o ID do emissor do OIDC para o cluster.
Recupere o ID do emissor do OIDC do cluster e armazene-o em uma variável. Substitua `` pelos seus próprios valores.
```
cluster_name=
oidc_id=$(aws eks describe-cluster --name $cluster_name --query "cluster.identity.oidc.issuer" --output text | cut -d '/' -f 5)
echo $oidc_id
```
1. Determine se um provedor OIDC do IAM com o ID do emissor do cluster já está em sua conta.
```
aws iam list-open-id-connect-providers | grep $oidc_id | cut -d "/" -f4
```
Caso retorne um resultado, significa que você já tem um provedor OIDC do IAM para o cluster e pode pular a próxima etapa. Se nenhum resultado for retornado, você deverá criar um provedor OIDC do IAM do seu cluster.
1. Crie o provedor de identidade OIDC do IAM para o cluster com o comando a seguir.
```
eksctl utils associate-iam-oidc-provider --cluster $cluster_name --approve
```
**nota**
Se você habilitou o endpoint da VPC do EKS, o endpoint de serviço de OIDC do EKS não poderá ser acessado de dentro dessa VPC. Consequentemente, suas operações, como a criação de um provedor de OIDC com o `eksctl` na VPC, não funcionarão e resultarão em um tempo limite. Segue um exemplo de mensagem de erro:
```
** server cant find oidc.eks..amazonaws.com: NXDOMAIN
```
Para concluir essa etapa, você pode executar o comando fora da VPC, por exemplo, no AWS CloudShell ou em um computador conectado à Internet. Como alternativa, você pode criar um resolvedor condicional de horizonte segmentado na VPC, como o Route 53 Resolver, para usar um resolvedor diferente para o URL do emissor do OIDC e não usar o DNS da VPC para ela. Para ver um exemplo de encaminhamento condicional em CoreDNS, consulte [Amazon EKS feature request](https://github.com/aws/containers-roadmap/issues/2038) no GitHub.
## Criar provedor OIDC (console do AWS)
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel esquerdo, selecione **Clusters** e, em seguida, selecione o nome do cluster na página **Clusters**.
1. Na seção **Details** (Detalhes) da guia **Overview** (Visão geral), observe o valor de **OpenID Connect provider URL** (URL do provedor OpenID Connect).
1. Abra o console do IAM em https://console.aws.amazon.com/iam/.
1. No painel de navegação à esquerda, escolha **Identity Providers** (Provedores de identidade) em **Access management** (Gerenciamento de acesso). Se um **fornecedor** listado corresponder à URL do cluster, então você já tem um provedor para o cluster. Se um provedor não estiver listado que corresponda à URL do seu cluster, você deverá criar um.
1. Para criar um provedor, selecione **Add provider** (Adicionar provedor).
1. Em **Tipo de provedor**, selecione **OpenID Connect**.
1. Em **URL do provedor**, insira o URL do provedor OIDC do cluster.
1. Em **Público**, insira `sts.amazonaws.com`.
1. (Opcional) Adicione qualquer tag, por exemplo, uma tag para identificar qual cluster destina-se a esse provedor.
1. Escolha **Add provider** (Adicionar provedor).
Próxima etapa: [Atribuir perfis do IAM às contas de serviço do Kubernetes](associate-service-account-role.md)
# Atribuir perfis do IAM às contas de serviço do Kubernetes
Este tópico aborda como configurar uma conta de serviço do Kubernetes para assumir um perfil do AWS Identity and Access Management (IAM). Qualquer pod que esteja configurado para usar a conta de serviço pode acessar qualquer serviço da AWS que o perfil tenha permissão para acessar.
## Pré-requisitos
+ Um cluster existente. Se você não tiver um, poderá criá-lo seguindo um dos guias em [Começar a usar o Amazon EKS](getting-started.md).
+ Um provedor do IAM OpenID Connect (OIDC) para o cluster. Para saber se você já tem um ou como criar um, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Um arquivo `kubectl` `config` existente que contém a configuração do seu cluster. Para criar um arquivo `kubectl` `config`, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
## Etapa 1: criar a política do IAM
Se você quiser associar uma política do IAM existente ao seu perfil do IAM, vá para a próxima etapa.
1. Crie uma política do IAM. É possível criar a sua própria política ou copiar uma política gerenciada da AWS que já conceda algumas das permissões de que você precisa e a personalizar de acordo com seus requisitos específicos. Para obter mais informações, consulte [Criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do usuário do IAM*.
1. Crie um arquivo que inclua as permissões para os serviços da AWS que você deseja que os pods acessem. Para obter uma lista de todas as ações de todos os serviços do AWS, consulte a [Referência de autorização de serviço](https://docs.aws.amazon.com/service-authorization/latest/reference/).
É possível executar o comando a seguir para criar um arquivo de política de exemplo que permita acesso somente leitura a um bucket do Amazon S3. Você pode, opcionalmente, armazenar informações de configuração ou um script de bootstrap nesse bucket, e os contêineres no pod podem ler o arquivo do bucket e carregá-lo na aplicação. Se você quiser criar esse exemplo de política, copie o conteúdo a seguir para o seu dispositivo. Substitua *my-pod-secrets-bucket* pelo nome do seu bucket e execute o comando.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Crie a política do IAM.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
## Etapa 2: criar e associar o perfil do IAM
Crie um perfil do IAM e associe-o a uma conta de serviço do Kubernetes. Você pode usar o `eksctl` ou a AWS CLI.
### Criar e associar um perfil (eksctl)
Esse comando `eksctl` cria uma conta de serviço do Kubernetes no namespace especificado, cria um perfil do IAM (se não existir) com o nome especificado, anexa um ARN de política do IAM existente ao perfil e anota a conta de serviço com o ARN do perfil do IAM. Certifique-se de substituir os valores de espaço reservado de exemplo neste comando por seus valores específicos. Para instalar ou atualizar o `eksctl`, consulte [Instalação](https://eksctl.io/installation) na documentação do `eksctl`.
```
eksctl create iamserviceaccount --name my-service-account --namespace default --cluster my-cluster --role-name my-role \
--attach-policy-arn arn:aws:iam::111122223333:policy/my-policy --approve
```
**Importante**
Se a função ou a conta de serviço já existir, o comando anterior poderá falhar. O `eksctl` tem opções diferentes que você pode oferecer nessas situações. Para obter mais informações, execute `eksctl create iamserviceaccount --help`.
### Criar e associar um perfil (AWS CLI)
Se você já tem um conta de serviço do Kubernetes na qual deseja assumir um perfil do IAM, você pode ignorar esta etapa.
1. Crie uma conta de serviço do Kubernetes. Copie o conteúdo a seguir para o seu dispositivo. Substitua *my-service-account* pelo nome desejado e *default* (padrão) por um namespace diferente, se necessário. Se você alterar o *padrão*, o namespace já deve existir.
```
cat >my-service-account.yaml <
1. Confirme se a política de confiança do perfil do IAM está configurada corretamente.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Veja abaixo um exemplo de saída.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account",
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
1. Confirme se a política que você anexou ao seu perfil em uma etapa anterior está vinculada ao perfil.
```
aws iam list-attached-role-policies --role-name my-role --query "AttachedPolicies[].PolicyArn" --output text
```
Veja um exemplo de saída abaixo.
```
arn:aws:iam::111122223333:policy/my-policy
```
1. Defina uma variável para armazenar o nome do recurso da Amazon (ARN) da política que deseja usar. Substitua *my-policy* pelo nome da política para a qual deseja confirmar permissões.
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. Visualize a versão padrão da política.
```
aws iam get-policy --policy-arn $policy_arn
```
Veja abaixo um exemplo de saída.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Confira o conteúdo da política para garantir que ela inclua todas as permissões de que seu pod precisa. Se necessário, substitua*1* no comando a seguir pela versão retornada na saída anterior.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Veja abaixo um exemplo de saída.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Se você criou a política de exemplo em uma etapa anterior, sua saída será a mesma. Se você criou uma política diferente, então o *exemplo* de conteúdo é diferente.
1. Verifique se a conta do serviço do Kubernetes está anotada com o perfil.
```
kubectl describe serviceaccount my-service-account -n default
```
Veja abaixo um exemplo de saída.
```
Name: my-service-account
Namespace: default
Annotations: eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
Image pull secrets:
Mountable secrets: my-service-account-token-qqjfl
Tokens: my-service-account-token-qqjfl
[...]
```
## Próximas etapas
+ [Configurar pods para usar uma conta de serviço do Kubernetes](pod-configuration.md)
# Configurar pods para usar uma conta de serviço do Kubernetes
Se um pod precisar acessar os serviços da AWS, você deverá configurá-lo para usar uma conta de serviço do Kubernetes. A conta de serviço deve estar associada a um perfil do AWS Identity and Access Management (IAM) que tenha permissões para acessar os serviços da AWS.
+ Um cluster existente. Se não tiver um, você poderá criá-lo usando um dos guias em [Começar a usar o Amazon EKS](getting-started.md).
+ Um provedor do IAM OpenID Connect (OIDC) para o cluster. Para saber se você já tem um ou como criar um, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ Uma conta de serviço existente do Kubernetes que é associada a um perfil do IAM. A conta de serviço deve ser anotada com o nome do recurso da Amazon (ARN) do perfil do IAM. O perfil deve ter uma política do IAM associada que contenha as permissões que você deseja que os pods tenham para usar os serviços da AWS. Para obter mais informações sobre como criar a conta de serviço e como configurá-la, consulte [Atribuir perfis do IAM às contas de serviço do Kubernetes](associate-service-account-role.md).
+ Versão `2.12.3` ou posterior ou versão `1.27.160` ou posterior da AWS Command Line Interface (AWS CLI) instalada e configurada no seu dispositivo ou no AWS CloudShell. Para verificar sua versão atual, use `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Installing](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Quick configuration with aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no *Guia do usuário da AWS Command Line Interface*. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no * Guia do usuário do AWS CloudShell*.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Um arquivo `kubectl` `config` existente que contém a configuração do seu cluster. Para criar um arquivo `kubectl` `config`, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
1. Use o comando a seguir para criar um manifesto de implantação com o qual é possível implantar um pod para confirmar a configuração. Substitua os valores de exemplo por seus próprios valores.
```
cat >my-deployment.yaml <
Se estiver usando uma conta de serviço do Kubernetes [com perfis de IAM para contas de serviço](iam-roles-for-service-accounts.md), você poderá configurar o tipo de endpoint do AWS Security Token Service usado pela conta de serviço.
A AWS recomenda usar os endpoints regionais do AWS STS em vez do endpoint global. Isso reduz a latência, fornece redundância integrada e aumenta a validade do token da sessão. O AWS Security Token Service deve estar ativo na região da AWS onde o pod está sendo executado. Além disso, sua aplicação deve ter redundância integrada para uma região da AWS diferente no caso de uma falha do serviço na região da AWS. Para obter mais informações, consulte [Gerenciar o AWS STS em uma região da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_enable-regions.html), no Guia do usuário do IAM.
+ Um cluster existente. Se não tiver um, você poderá criá-lo usando um dos guias em [Começar a usar o Amazon EKS](getting-started.md).
+ Um provedor de OIDC do IAM existente para o cluster. Para obter mais informações, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ Uma conta de serviço existente do Kubernetes configurada para uso com o recurso [Amazon EKS IAM para contas de serviço](iam-roles-for-service-accounts.md).
Todos os exemplos a seguir usam a conta de serviço aws-node do Kubernetes usada pelo [plug-in CNI da Amazon VPC](cni-iam-role.md). É possível substituir os *valores de exemplo* pelas suas próprias contas de serviço, pods, namespaces e outros recursos.
1. Selecione um pod que use uma conta de serviço para a qual você deseja alterar o endpoint. Determine em qual região da AWS o pod é executado. Substitua *aws-node-6mfgv* pelo nome do pod e *kube-system* pelo namespace do seu pod.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep Node:
```
Veja abaixo um exemplo de saída.
```
ip-192-168-79-166.us-west-2/192.168.79.166
```
Na saída anterior, o pod está sendo executado em um nó na região us-west-2 da AWS.
1. Determine o tipo de endpoint que a conta de serviço do pod estará usando.
```
kubectl describe pod aws-node-6mfgv -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Veja abaixo um exemplo de saída.
```
AWS_STS_REGIONAL_ENDPOINTS: regional
```
Se o endpoint atual for global, `global` será retornado na saída. Se nenhuma saída for retornada, significa que tipo de endpoint padrão está em uso e não foi substituído.
1. Se a versão do cluster ou plataforma for a mesma ou posterior à da tabela, você poderá alterar o tipo de endpoint utilizado pela conta de serviço do tipo padrão para um tipo diferente, usando um dos comandos a seguir. Substitua *aws-node* pelo nome da conta de serviço e *aws-node* pelo namespace da sua conta de serviço.
+ Se o tipo de endpoint padrão ou atual for global e você quiser modificá-lo para regional:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=true
```
Se você estiver usando [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md) para gerar URLs do S3 pré-assinados na aplicação em execução em contêineres de pods, o formato do URL para endpoints regionais será semelhante ao seguinte exemplo:
```
https://bucket.s3.us-west-2.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
+ Se o tipo de endpoint padrão ou atual for global, e você quiser modificá-lo para regional:
```
kubectl annotate serviceaccount -n kube-system aws-node eks.amazonaws.com/sts-regional-endpoints=false
```
Se a sua aplicação estiver fazendo solicitações explicitamente para endpoints globais do AWS STS e você não substituir o comportamento padrão de usar endpoints regionais em clusters do Amazon EKS, as solicitações falharão com um erro. Para obter mais informações, consulte [Os contêineres do pod recebem o seguinte erro: `An error occurred (SignatureDoesNotMatch) when calling the GetCallerIdentity operation: Credential should be scoped to a valid region`](security-iam-troubleshoot.md#security-iam-troubleshoot-wrong-sts-endpoint).
Se você estiver usando [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md) para gerar URLs do S3 pré-assinados na sua aplicação em execução em contêineres de pods, o formato do URL para endpoints globais será semelhante ao seguinte exemplo:
```
https://bucket.s3.amazonaws.com/path?...&X-Amz-Credential=your-access-key-id/date/us-west-2/s3/aws4_request&...
```
Se você tem uma automação que espera o URL pré-assinado em um determinado formato ou se a sua aplicação ou dependências downstream que usam URLs pré-assinados têm expectativas para a região da AWS visada, faça as alterações necessárias para usar o endpoint do AWS STS apropriado.
1. Exclua e recrie os pods existentes associados à conta de serviço para aplicar as variáveis de credenciais do ambiente. O webhook de mutação não as aplica aos pods que já estão em execução. É possível substituir *pods*, *kube-system* e *-l k8s-app=aws-node* pelas informações dos pods para os quais você definiu sua anotação.
```
kubectl delete Pods -n kube-system -l k8s-app=aws-node
```
1. Verifique se todos os pods foram reiniciados.
```
kubectl get Pods -n kube-system -l k8s-app=aws-node
```
1. Visualize as variáveis de ambiente de um dos pods. Verifique se o valor `AWS_STS_REGIONAL_ENDPOINTS` é o que você o definiu em uma etapa anterior.
```
kubectl describe pod aws-node-kzbtr -n kube-system |grep AWS_STS_REGIONAL_ENDPOINTS
```
Veja abaixo um exemplo de saída.
```
AWS_STS_REGIONAL_ENDPOINTS=regional
```
# Autenticar em outra conta com IRSA
É possível configurar permissões entre contas do IAM criando um provedor de identidade do cluster de outra conta ou usando operações `AssumeRole` encadeadas. Nos exemplos a seguir, a *Conta A* tem um cluster do Amazon EKS compatível com perfis do IAM para contas de serviço. Os pods em execução nesse cluster devem assumir as permissões do IAM da *Conta B*.
+ A **Opção 1** é mais simples, mas exige que a Conta B crie e gerencie um provedor de identidade OIDC para o cluster da Conta A.
+ A **Opção 2** mantém o gerenciamento do OIDC na Conta A, mas exige o encadeamento de funções por meio de duas chamadas `AssumeRole`.
## Opção 1: Criar um provedor de identidade a partir do cluster de outra conta
Neste exemplo, a Conta A fornece à Conta B o URL do emissor de OpenID Connect (OIDC) de seu cluster. A conta B segue as instruções em [Criar um provedor OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md) e [Atribuir perfis do IAM às contas de serviço do Kubernetes](associate-service-account-role.md) usando o URL do emissor do OIDC do cluster da Conta A. Em seguida, um administrador de cluster anota a conta de serviço no cluster da Conta A para usar o perfil da Conta B (*444455556666*).
```
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::444455556666:role/account-b-role
```
## Opção 2: Usar operações `AssumeRole` encadeadas
Nessa abordagem, cada conta cria um perfil do IAM. O perfil da Conta B confia no perfil da Conta A, e o perfil da Conta A utiliza a federação OIDC para obter credenciais do cluster. Em seguida, o Pod encadeia as duas funções usando perfis da AWS CLI.
### Passo 1: Crie o perfil de destino na Conta B
A Conta B (*444455556666*) cria um perfil do IAM com as permissões necessárias para os pods no cluster da Conta A. A conta B atribui a política de permissões desejada a esse perfil e, em seguida, adiciona a seguinte política de confiança.
**Política de confiança para o perfil da Conta B**: essa política permite que o perfil IRSA específico da Conta A assuma esse perfil.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}
]
}
```
**Importante**
Para aplicar o princípio do privilégio mínimo, faça a troca do ARN `Principal` pelo ARN do perfil específico da Conta A, em vez de usar a conta raiz (`arn:aws:iam::111122223333:root`). O uso da conta root permite que *qualquer* entidade principal do IAM na Conta A assuma esse perfil.
### Passo 2: Criar o perfil IRSA na Conta A
A conta A (*111122223333*) cria um perfil com uma política de confiança que obtém credenciais do provedor de identidade criado com o endereço do emissor de OIDC do cluster.
**Política de confiança para o perfil da Conta A (federação OIDC)**: essa política permite que o provedor OIDC do cluster do EKS emita credenciais para este perfil.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::111122223333:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"oidc.eks.us-east-1.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:aud": "sts.amazonaws.com"
}
}
}
]
}
```
**Importante**
Para aplicar o princípio do privilégio mínimo, adicione uma condição `StringEquals` à reivindicação `sub` para restringir esse perfil a uma conta de serviço específica do Kubernetes. Sem nenhuma condição `sub`, qualquer conta de serviço no cluster pode assumir esse perfil. O valor `sub` segue o formato `system:serviceaccount:NAMESPACE:SERVICE_ACCOUNT_NAME `. Por exemplo, para restringir a uma conta de serviço cujo nome `my-service-account` consta no namespace `default`:
```
"oidc.eks.region-code.amazonaws.com/id/EXAMPLED539D4633E53DE1B71EXAMPLE:sub": "system:serviceaccount:default:my-service-account"
```
### Etapa 3: atribuir a permissão AssumeRole ao perfil da Conta A
A conta A atribui uma política de permissões ao perfil criado na Etapa 2. Essa política permite que o perfil assuma o perfil da Conta B.
**Política de permissões para o perfil da Conta A**: essa política concede `sts:AssumeRole` sobre o perfil alvo da Conta B.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "arn:aws:iam::444455556666:role/account-b-role"
}
]
}
```
### Etapa 4: Configurar o Pod para encadeamento de perfis
A aplicação cria o código para que os pods assumam que o perfil da Conta B usa dois perfis: `account_b_role` e `account_a_role`. O perfil `account_b_role` usa o perfil `account_a_role` como origem. Para a CLI AWS, o arquivo `~/.aws/config` é semelhante ao seguinte.
```
[profile account_b_role]
source_profile = account_a_role
role_arn=arn:aws:iam::444455556666:role/account-b-role
[profile account_a_role]
web_identity_token_file = /var/run/secrets/eks.amazonaws.com/serviceaccount/token
role_arn=arn:aws:iam::111122223333:role/account-a-role
```
Para especificar perfis encadeados para outras SDKs da AWS, consulte a documentação do SDK em uso. Para obter mais informações, consulte [Ferramentas para criar na AWS](https://aws.amazon.com/developer/tools/).
# Usar o IRSA com o AWS SDK
**Usar as credenciais**
Para usar as credenciais dos perfis do IAM para contas de serviço (IRSA), seu código pode usar qualquer SDK da AWS para criar um cliente para um serviço da AWS com um SDK e, por padrão, o SDK pesquisa em uma cadeia de locais as credenciais do AWS Identity and Access Management a serem usadas. As credenciais do perfis do IAM para contas de serviço serão usadas se você não especificar um provedor de credenciais ao criar o cliente ou ao inicializar o SDK.
Isso funciona porque os perfis do IAM para contas de serviço foram adicionados como uma etapa na cadeia de credenciais padrão. Se suas workloads usam no momento credenciais mais antigas na cadeia de credenciais, essas credenciais continuarão sendo usadas mesmo se você configurar perfis do IAM para contas de serviço para a mesma workload.
O SDK troca automaticamente o token OIDC da conta de serviço por credenciais temporárias do AWS Security Token Service usando a ação `AssumeRoleWithWebIdentity`. O Amazon EKS e essa ação do SDK continuam alternando as credenciais temporárias, renovando-as antes que elas expirem.
Ao usar [perfis do IAM para contas de serviço](iam-roles-for-service-accounts.md), os contêineres nos pods devem usar uma versão do AWS SDK que permita assumir um perfil do IAM por meio de um arquivo de token de identidade da web do OpenID Connect. Certifique-se de usar as seguintes versões, ou versões posteriores, do AWS SDK:
+ Java (versão 2): [2.10.11](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.10.11)
+ Java: [1.12.782](https://github.com/aws/aws-sdk-java/releases/tag/1.12.782)
+ AWS SDK para Go v1: [1.23.13](https://github.com/aws/aws-sdk-go/releases/tag/v1.23.13)
+ AWS SDK para Go v2: suporte para todas as versões
+ Python (Boto3): [1.9.220](https://github.com/boto/boto3/releases/tag/1.9.220)
+ Python (botocore): [1.12.200](https://github.com/boto/botocore/releases/tag/1.12.200)
+ AWS CLI – [1.16.232](https://github.com/aws/aws-cli/releases/tag/1.16.232)
+ Node: [2.525.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.525.0) e [3.27.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.27.0)
+ Ruby: [3.58.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#3580-2019-07-01)
+ C\$1\$1: [1.7.174](https://github.com/aws/aws-sdk-cpp/releases/tag/1.7.174)
+ .NET: [3.3.659.1](https://github.com/aws/aws-sdk-net/releases/tag/3.3.659.1) - Você também deve incluir o `AWSSDK.SecurityToken`.
+ PHP: [3.110.7](https://github.com/aws/aws-sdk-php/releases/tag/3.110.7)
Muitos complementos populares do Kubernetes, como o [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler), o [Roteamento do tráfego da internet com o AWS Load Balancer Controller](aws-load-balancer-controller.md) e o [plug-in CNI da Amazon VPC para Kubernetes](cni-iam-role.md), são compatíveis com perfis do IAM para contas de serviço.
Para garantir que você esteja usando um SDK compatível, siga as instruções de instalação do SDK de sua preferência em [Ferramentas para desenvolver na AWS](https://aws.amazon.com/tools/) quando estiver criando seus contêineres.
## Considerações
### Java
Quando usar o Java, você *deve* incluir o `sts` no caminho da classe. Para obter mais informações, consulte [WebIdentityTokenFileCredentialsProvider](https://sdk.amazonaws.com/java/api/latest/software/amazon/awssdk/auth/credentials/WebIdentityTokenFileCredentialsProvider.html) nos documentos SDK do Java.
# Obter as chaves de assinatura para validar os tokens OIDC
O Kubernetes emite um `ProjectedServiceAccountToken` para cada conta de serviço do Kubernetes. Este token é um token OIDC, que também é um tipo de JSON web token (JWT). O Amazon EKS hospeda um endpoint público do OIDC em cada cluster que contém as chaves de assinatura para o token de modo que sistemas externos possam validá-lo.
Para validar um `ProjectedServiceAccountToken`, você precisa buscar as chaves públicas de assinatura do OIDC, também denominadas JSON Web Key Set (JWKS). Use essas chaves em sua aplicação para validar o token. Por exemplo, você pode usar a [biblioteca PyJWT Python](https://pyjwt.readthedocs.io/en/latest/) para validar tokens usando essas chaves. Para obter mais informações sobre o `ProjectedServiceAccountToken`, consulte o [Informações de contexto sobre IAM, Kubernetes e OpenID Connect (OIDC)](iam-roles-for-service-accounts.md#irsa-oidc-background).
## Pré-requisitos
+ Um provedor AWS Identity and Access Management (IAM) OpenID Connect (OIDC) para o seu cluster. Para determinar se você tem ou para criar uma, consulte [Criar um provedor de identidade OIDC do IAM para o cluster](enable-iam-roles-for-service-accounts.md).
+ ** AWS CLI**- Uma ferramenta de linha de comando para trabalhar com os serviços AWS, incluindo o Amazon EKS. Para obter mais informações, consulte [Instalação](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) no Guia do Usuário da Interface de Linha de Comando AWS. Depois de instalar a AWS CLI, recomendamos que você também a configure. Para saber mais, consulte [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no Guia do usuário da AWS Command Line Interface.
## Procedimento
1. Recupere o URL do OIDC para o cluster do Amazon EKS usando a AWS CLI.
```
$ aws eks describe-cluster --name my-cluster --query 'cluster.identity.oidc.issuer'
"https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE"
```
1. Recupere a chave de assinatura pública usando o curl ou uma ferramenta similar. O resultado é um [JSON Web Key Set (JWKS)](https://www.rfc-editor.org/rfc/rfc7517#section-5).
**Importante**
O Amazon EKS controla a utilização das chamadas para o endpoint do OIDC. Você deve armazenar em cache a chave pública de assinatura. Respeite o cabeçalho `cache-control` incluído na resposta.
**Importante**
O Amazon EKS alterna a chave de assinatura do OIDC a cada sete dias.
```
$ curl https://oidc.eks.us-west-2.amazonaws.com/id/8EBDXXXX00BAE/keys
{"keys":[{"kty":"RSA","kid":"2284XXXX4a40","use":"sig","alg":"RS256","n":"wklbXXXXMVfQ","e":"AQAB"}]}
```
# Saiba como a Identidade de Pods do EKS concede aos pods acesso aos serviços da AWS
Os aplicações nos contêineres de um Pod podem usar um SDK AWS ou a CLI AWS para fazer solicitações de API para serviços AWS usando permissões de gerenciamento de identidade e acesso (IAM) AWS. As aplicações devem assinar suas solicitações de API da AWS com as credenciais da AWS.
Os *EKS Pod Identities* permitem gerenciar credenciais para suas aplicações de forma semelhante a como os perfis de instância do Amazon EC2 fornecem credenciais para instâncias do Amazon EC2. Em vez de criar e distribuir as credenciais da AWS para os contêineres ou usar o perfil da instância do Amazon EC2, você pode associar um perfil do IAM a uma conta de serviço do Kubernetes e configurar os pods para usar a conta de serviço.
[](http://www.youtube.com/watch?v=https://www.youtube.com/embed/aUjJSorBE70?rel=0)
Cada associação ao EKS Pod Identity mapeia um perfil a uma conta de serviço em um namespace no cluster especificado. Se você tiver a mesma aplicação em vários clusters, poderá fazer associações idênticas em cada cluster sem modificar a política de confiança do perfil.
Se um pod usa uma conta de serviço que tem uma associação, o Amazon EKS define variáveis de ambiente nos contêineres do pod. As variáveis de ambiente configuram os SDKs da AWS, incluindo a AWS CLI, para usar as credenciais de Identidade de pods do EKS.
## Benefícios dos EKS Pod Identities
Os EKS Pod Identities fornecem os seguintes benefícios:
+ **Privilégio mínimo**: você pode definir o escopo das permissões do IAM para uma conta de serviço, e somente os pods que usarem essa conta de serviço terão acesso a essas permissões. Esse recurso também elimina a necessidade de soluções de terceiros, como o `kiam` ou o `kube2iam`.
+ **Isolamento de credenciais**: quando o acesso ao [serviço de metadados de instância (IMDS) do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) estiver restrito, um contêiner de pods só poderá recuperar as credenciais do perfil do IAM que estiver associado à conta de serviço que o contêiner usa. Um contêiner nunca tem acesso a credenciais usadas por outros contêineres em outros pods. Se o IMDS não estiver restrito, os contêineres do pod também terão acesso ao [perfil do IAM do nó do Amazon EKS](create-node-role.md), e os contêineres poderão obter acesso às credenciais dos perfis do IAM de outros pods no mesmo nó. Para obter mais informações, consulte [Restringir o acesso ao perfil da instância atribuído ao nó de processamento](https://docs.aws.amazon.com/eks/latest/best-practices/identity-and-access-management.html#_identities_and_credentials_for_eks_pods_recommendations).
**nota**
Os pods configurados com `hostNetwork: true` sempre terão acesso ao IMDS, mas a CLI e os SDKs da AWS usarão as credenciais da Identidade de Pods quando ativados.
+ **Auditabilidade**: o log de acesso e de eventos está disponível no AWS CloudTrail para ajudar a facilitar a auditoria retrospectiva.
**Importante**
Os contêineres não são um limite de segurança, e o uso da Identidade de Pods não muda isso. Os pods atribuídos ao mesmo nó compartilharão um kernel e possivelmente outros recursos, dependendo da configuração do pod. Embora os pods executados em nós separados sejam isolados na camada de computação, existem aplicações de nós que têm permissões adicionais na API do Kubernetes além do escopo de uma instância individual. Alguns exemplos são `kubelet`, `kube-proxy`, drivers de armazenamento CSI ou suas próprias aplicações do Kubernetes.
O Identidade de Pods do EKS é um método mais simples do que [Funções do IAM para contas de serviço](iam-roles-for-service-accounts.md), pois esse método não usa provedores de identidade OIDC. O EKS Pod Identity oferece os seguintes aprimoramentos:
+ **Operações independentes**: em muitas organizações, criar provedores de identidade OIDC é responsabilidade de equipes diferentes da administração dos clusters do Kubernetes. O EKS Pod Identity tem uma separação clara dos deveres em que toda a configuração das associações ao EKS Pod Identity é feita no Amazon EKS e toda a configuração das permissões do IAM é feita no IAM.
+ **Reutilização**: o EKS Pod Identity usa uma única entidade principal do IAM em vez das entidades principais separadas para cada cluster que os perfis do IAM para contas de serviço utilizam. Seu administrador do IAM adiciona a seguinte entidade principal à política de confiança de qualquer perfil para torná-la utilizável pelo EKS Pod Identities.
```
"Principal": {
"Service": "pods.eks.amazonaws.com"
}
```
+ **Escalabilidade**: cada conjunto de credenciais temporárias é assumido pelo serviço de autenticação no EKS na Identidade de Pods do EKS, em vez de cada AWS SDK que você executa em cada pod. Em seguida, o Amazon EKS Pod Identity Agent executado em cada nó emite as credenciais para os SDKs. Assim, a carga é reduzida para uma vez para cada nó e não é duplicada em cada pod. Para obter mais detalhes do processo, consulte [Como a Identidade de Pods do EKS funciona](pod-id-how-it-works.md).
Para obter mais informações sobre como comparar as duas alternativas, consulte [Conceder às workloads do Kubernetes acesso a AWS usando contas de serviço do Kubernetes](service-accounts.md).
## Visão geral da configuração do EKS Pod Identities
Ative o EKS Pod Identities concluindo os seguintes procedimentos:
1. [Configurar o atndente do Identidade de Pods do Amazon EKS](pod-id-agent-setup.md): esse procedimento é realizado apenas uma vez para cada cluster. Você não precisará concluir esta etapa se o Modo Automático do EKS estiver habilitado no cluster.
1. [Atribuir um perfil do IAM a uma conta de serviço do Kubernetes](pod-id-association.md): conclua esse procedimento para cada conjunto exclusivo de permissões que você deseja que uma aplicação tenha.
1. [Configurar pods para acessar serviços da AWS com contas de serviço](pod-id-configure-pods.md): conclua este procedimento para cada pod que precisa de acesso aos serviços da AWS.
1. [Usar identidade de pods com o AWS SDK](pod-id-minimum-sdk.md): confirme que a workload usa um AWS SDK de uma versão compatível e que essa workload usa a cadeia de credenciais padrão.
## Limites
+ São aceitas até 5 mil associações de Identidades de Pods do EKS por cluster para mapear perfis do IAM para contas de serviço do Kubernetes.
## Considerações
+ **Associação de perfil do IAM**: cada conta de serviço do Kubernetes em um cluster pode ser associada a um perfil do IAM da mesma conta da AWS que o cluster. Para alterar o perfil, edite a associação de Identidades de Pods do EKS. Para acesso entre contas, delegue o acesso ao perfil usando perfis do IAM. Para obter mais informações, consulte [Delegar acesso entre contas da AWS usando perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html) no *Guia do usuário do IAM*.
+ **Agente da Identidade de Pods do EKS**: o agente da Identidade de Pods é necessário para usar a Identidade de Pods do EKS. O agente é executado como um `DaemonSet` do Kubernetes em nós de cluster, fornecendo credenciais somente para pods no mesmo nó. Ele usa o `hostNetwork` do nó, ocupando a porta `80` e a `2703` no endereço local do link (`169.254.170.23` para IPv4, `[fd00:ec2::23]` para IPv6). Se o IPv6 estiver desabilitado em seu cluster, desabilite o IPv6 para o agente da Identidade de Pods. Para saber mais, consulte [Desabilitar o IPv6 no agente da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-config-ipv6.html).
+ **Consistência eventual**: as associações de Identidades de Pods do EKS acabam sendo consistentes, com possíveis atrasos de vários segundos após as chamadas de API. Evite criar ou atualizar associações em caminhos de código críticos e de alta disponibilidade. Em vez disso, execute essas ações em rotinas de inicialização ou configuração separadas e menos frequentes. Para saber mais, consulte [Security Groups Per Pod](https://docs.aws.amazon.com/eks/latest/best-practices/sgpp.html) no *EKS Best Practices Guide*.
+ **Considerações sobre proxy e grupos de segurança**: para pods que usam um proxy, adicione `169.254.170.23` (IPv4) e `[fd00:ec2::23]` (IPv6) às variáveis de ambiente `no_proxy/NO_PROXY` para evitar falhas nas solicitações ao agente da Identidade de Pods do EKS. Se estiver usando grupos de segurança para pods com a CNI da AWS VPC, defina a sinalização `ENABLE_POD_ENI` como “true” e a sinalização `POD_SECURITY_GROUP_ENFORCING_MODE` como “standard”. Para saber mais, consulte [Atribuir grupos de segurança a pods individuais](https://docs.aws.amazon.com/eks/latest/userguide/security-groups-for-pods.html).
### Versões de cluster do EKS Pod Identity
Para usar a Identidade de Pods do EKS, o cluster deve ter uma versão da plataforma igual ou posterior à versão listada na tabela a seguir, ou uma versão do Kubernetes posterior às versões listadas na tabela. Para encontrar a versão sugerida do agente da Identidade de Pods do EKS para uma versão do Kubernetes, consulte [Verificar a compatibilidade da versão do complemento do Amazon EKS com um cluster](addon-compat.md).
| Versão do Kubernetes | Versão da plataforma |
| --- | --- |
| Versões do Kubernetes não listadas | Todas as versões compatíveis da plataforma |
| `1.28` | `eks.4` |
### Restrições do EKS Pod Identity
Os EKS Pod Identities estão disponíveis em:
+ Versões de cluster do Amazon EKS listadas no tópico [Versões de cluster do EKS Pod Identity](#pod-id-cluster-versions) anterior.
+ Nós de processamento no cluster que são instâncias do Linux do Amazon EC2.
Os EKS Pod Identities não estão disponíveis em:
+ AWS Outposts.
+ Amazon EKS Anywhere
+ Clusters do Kubernetes que você cria e executa no Amazon EC2. Os componentes do EKS Pod Identity estão disponíveis somente no Amazon EKS.
Não é possível usar o EKS Pod Identities com:
+ Pods executados em qualquer lugar, exceto instâncias do Linux do Amazon EC2. Não há suporte para pods Linux e Windows executados em AWS Fargate (Fargate). Não há suporte a pods executados em instâncias do Windows do Amazon EC2.
# Como a Identidade de Pods do EKS funciona
As associações do Amazon EKS Pod Identity permitem gerenciar credenciais para suas aplicações de forma semelhante a como os perfis de instância do Amazon EC2 fornecem credenciais para instâncias do Amazon EC2.
O Amazon EKS Pod Identity fornece credenciais para suas workloads com uma API *EKS Auth* adicional e um pod de agente que é executado em cada nó.
Em seus complementos, como os *complementos do Amazon EKS* e controladores autogerenciados, operadores e outros complementos, o autor precisa atualizar o software para usar os AWS SDKs mais recentes. Para ver a lista de compatibilidade entre o EKS Pod Identity e os complementos produzidos pelo Amazon EKS, consulte a seção [Restrições do EKS Pod Identity](pod-identities.md#pod-id-restrictions) anterior.
## Usar o EKS Pod Identities em seu código
É possível usar os AWS SDKs no código para acessar os serviços da AWS. Você escreve um código para criar um cliente para um serviço AWS com um SDK e, por padrão, o SDK pesquisa em uma cadeia de locais as credenciais do AWS Identity and Access Management a serem usadas. Depois que as credenciais válidas são encontradas, a pesquisa é interrompida. Para obter mais informações sobre os locais padrão usados, consulte a [Cadeia de provedores de credenciais](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) no Guia de referência de SDKs e ferramentas da AWS.
As identidades do EKS Pod foram adicionadas ao *Provedor de credenciais do container*, o qual é pesquisado em uma etapa na cadeia de credenciais padrão. Se atualmente suas workloads usam credenciais mais antigas na cadeia de credenciais, elas continuarão sendo usadas mesmo se você configurar uma associação do EKS Pod Identity para a mesma workload. Dessa forma, você pode migrar com segurança de outros tipos de credenciais criando a associação antes de remover as credenciais antigas.
O provedor de credenciais do contêiner fornece credenciais temporárias de um agente executado em cada nó. No Amazon EKS, o agente é o Amazon EKS Pod Identity Agent e, no Amazon Elastic Container Service, o agente é o `amazon-ecs-agent`. Os SDKs usam variáveis de ambiente para localizar os agentes ao qual se conectarão.
Por outro lado, *as perfis de IAM para contas de serviço* fornecem um token *de identidade da Web* que o SDK AWS deve trocar com o Serviço de token de segurança AWS usando `AssumeRoleWithWebIdentity`.
## Como a Identidade de Pods do EKS funciona com um Pod
1. Quando o Amazon EKS inicia um novo pod que usa uma conta de serviço com uma associação da Identidade de Pods do EKS, o cluster adiciona o seguinte conteúdo ao manifesto de pods:
```
env:
- name: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE
value: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token"
- name: AWS_CONTAINER_CREDENTIALS_FULL_URI
value: "http://169.254.170.23/v1/credentials"
volumeMounts:
- mountPath: "/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/"
name: eks-pod-identity-token
volumes:
- name: eks-pod-identity-token
projected:
defaultMode: 420
sources:
- serviceAccountToken:
audience: pods.eks.amazonaws.com
expirationSeconds: 86400 # 24 hours
path: eks-pod-identity-token
```
1. O Kubernetes seleciona em qual nó o pod será executado. Em seguida, o Amazon EKS Pod Identity Agent no nó usa a ação [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html) para recuperar credenciais temporárias da API de autenticação do EKS.
1. O EKS Pod Identity Agent disponibiliza essas credenciais para os AWS SDKs que você executa em seus contêineres.
1. Você usa o SDK em sua aplicação sem especificar um provedor de credenciais para usar a cadeia de credenciais padrão. Ou você especifica o provedor de credenciais do contêiner. Para obter mais informações sobre os locais padrão usados, consulte a [Cadeia de provedores de credenciais](https://docs.aws.amazon.com/sdkref/latest/guide/standardized-credentials.html#credentialProviderChain) no Guia de referência de SDKs e ferramentas da AWS.
1. O SDK usa as variáveis de ambiente para se conectar ao EKS Pod Identity Agent e recuperar as credenciais.
**nota**
Se suas workloads usam no momento credenciais mais antigas na cadeia de credenciais, essas credenciais continuarão sendo usadas mesmo se você configurar uma associação do EKS Pod Identity para a mesma workload.
# Configurar o atndente do Identidade de Pods do Amazon EKS
As associações de Identidade de Pods do Amazon EKS permitem gerenciar credenciais para suas aplicações de forma semelhante a como os perfis de instância do Amazon EC2 fornecem credenciais para instâncias do Amazon EC2.
A Identidade de Pods do Amazon EKS fornece credenciais para suas workloads com uma API *EKS Auth* adicional e um pod de atendente executado em cada nó.
**dica**
Você não precisa instalar o atendente da Identidade de Pods nos clusters do Modo automático do EKS. Essa capacidade é integrada ao Modo automático do EKS.
## Considerações
+ Por padrão, o atendente de Identidade de Pods do EKS é pré-instalado nos clusters do EKS em modo automático. Para saber mais, consulte [Automatizar a infraestrutura de clusters com o Modo Automático do EKS](automode.md).
+ Por padrão, o atendente de Identidade de Pods do EKS escuta em um endereço `IPv4` e `IPv6` para os pods para solicitar credenciais. O atendente usa o endereço IP de loopback (localhost) `169.254.170.23` para `IPv4` e o endereço IP de localhost `[fd00:ec2::23]` para `IPv6`.
+ Se você desabilitar endereços `IPv6` ou de alguma forma impedir endereços IP `IPv6` do localhost, o atendente não poderá iniciar. Para iniciar o atendente em nós que não podem usar `IPv6`, siga as etapas em [Desabilitar o `IPv6` no EKS Pod Identity Agent](pod-id-agent-config-ipv6.md) para desabilitar a configuração de `IPv6`.
## Criar o atendente de Identidade de Pods do Amazon EKS
### Pré-requisitos do atendente
+ Um cluster existente do Amazon EKS. Para implantar, consulte [Começar a usar o Amazon EKS](getting-started.md). A versão do cluster e a versão da plataforma devem ser iguais ou posteriores às versões listadas em [Versões de clusters da Identidade de Pods do EKS](pod-identities.md#pod-id-cluster-versions).
+ O perfil de nó tem permissões para o atendente realizar a ação `AssumeRoleForPodIdentity` na API de autenticação do EKS. Você pode usar a [política gerenciada da AWS: AmazonEKSWorkerNodePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksworkernodepolicy) ou adicionar uma política personalizada semelhante à seguinte:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"eks-auth:AssumeRoleForPodIdentity"
],
"Resource": "*"
}
]
}
```
Esta ação pode ser limitada por tags para restringir quais funções podem ser assumidas pelos pods que usam o atendente.
+ Os nós podem acessar e baixar imagens do Amazon ECR. A imagem de contêiner do complemento está nos registros listados em [Visualizar registros de imagem de contêiner da Amazon para complementos do Amazon EKS](add-ons-images.md).
Observe que você pode alterar o local da imagem e fornecer `imagePullSecrets` para complementos EKS nas **definições de configuração opcionais** em Console de gerenciamento da AWS e em `--configuration-values` na CLI de AWS.
+ Os nós podem acessar a API de autenticação do Amazon EKS. Para clusters privados, é necessário o endpoint `eks-auth` em AWS PrivateLink.
### Configurar o atendente com o console do AWS
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação esquerdo, selecione **Clusters** e depois o nome do cluster para o qual você deseja configurar o complemento do atendente de Identidade de Pods do EKS.
1. Escolha a guia **Add-ons** (Complementos).
1. Escolha **Obter mais complementos**.
1. Selecione a caixa no canto superior direito da caixa do complemento do atentente de Identidade de Pods do EKS e escolha **Editar**.
1. Na página **Configurar complementos selecionados**, selecione qualquer versão na lista suspensa **Versão**.
1. (Opcional) Expanda **Configurações opcionais** para inserir configurações adicionais. Por exemplo, é possível indicar um local alternativo para a imagem do contêiner e `ImagePullSecrets`. O esquema JSON com chaves aceitas é mostrado no **Esquema de configuração do complemento**.
Insira as chaves e os valores de configuração em **Valores de configuração**.
1. Escolha **Próximo**.
1. Confirme que os pods do atentente de Identidade de Pods do EKS estão em execução no cluster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Veja abaixo um exemplo de saída.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Agora é possível usar associações da Identidade de Pods do EKS em seu cluster. Para obter mais informações, consulte [Atribuir um perfil do IAM a uma conta de serviço do Kubernetes](pod-id-association.md).
### Configurar o atendente com a AWS CLI
1. Execute o seguinte comando da AWS CLI. Substitua o `my-cluster` pelo nome do cluster.
```
aws eks create-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent --addon-version v1.0.0-eksbuild.1
```
**nota**
O atentente de Identidade de Pods do EKS não usa o `service-account-role-arn` para *perfis do IAM para contas de serviço*. Você deve fornecer ao atentente de Identidade de Pods do EKS as permissões no perfil de nó.
1. Confirme que os pods do atentente de Identidade de Pods do EKS estão em execução no cluster.
```
kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'
```
Veja abaixo um exemplo de saída.
```
eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h
eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h
```
Agora é possível usar associações da Identidade de Pods do EKS em seu cluster. Para obter mais informações, consulte [Atribuir um perfil do IAM a uma conta de serviço do Kubernetes](pod-id-association.md).
# Atribuir um perfil do IAM a uma conta de serviço do Kubernetes
Este tópico aborda como configurar uma conta de serviço do Kubernetes para assumir um perfil do AWS Identity and Access Management (IAM) com a Identidade de Pods do EKS. Qualquer pod que esteja configurado para usar a conta de serviço pode acessar qualquer serviço da AWS que o perfil tenha permissão para acessar.
Para criar uma associação de identidade de pod do EKS, há apenas uma única etapa; você cria a associação no EKS por meio de Console de gerenciamento da AWS, AWS CLI, AWS SDKs, AWS CloudFormation e outras ferramentas. Não há dados ou metadados sobre as associações dentro do cluster em nenhum objeto do Kubernetes, e você não adiciona anotações às contas de serviço.
**Pré-requisitos**
+ Um cluster existente. Se você não tiver um, poderá criá-lo seguindo um dos guias em [Começar a usar o Amazon EKS](getting-started.md).
+ A entidade principal do IAM que está criando a associação deve ter o `iam:PassRole`.
+ A versão mais recente da AWS CLI instalada e configurada em seu dispositivo ou no AWS CloudShell. É possível verificar sua versão atual com `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no Guia do usuário da AWS Command Line Interface. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no Guia do usuário do AWS CloudShell.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, será possível usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Um arquivo `kubectl` `config` existente que contém a configuração do seu cluster. Para criar um arquivo `kubectl` `config`, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
## Criar uma associação de identidade de pod (console do AWS )
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação esquerdo, selecione **Clusters** e depois o nome do cluster para o qual você deseja configurar o complemento do atendente de Identidade de Pods do EKS.
1. Escolha a guia **Acesso**.
1. Nas **Associações do Pod Identity**, escolha **Criar**.
1. Para o **Perfil do IAM**, selecione o perfil do IAM com as permissões que você deseja que a workload tenha.
**nota**
A lista contém apenas perfis que têm a política de confiança a seguir que permite que o EKS Pod Identity as use.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
`sts:AssumeRole`: a Identidade de Pods do EKS usa `AssumeRole` para assumir o perfil do IAM antes de passar as credenciais temporárias para os pods.
`sts:TagSession`: a Identidade de Pods do EKS usa `TagSession` para incluir *etiquetas de sessão* nas solicitações para o AWS STS.
É possível usar essas tags nas *chaves de condição* na política de confiança para restringir quais contas de serviço, namespaces e clusters podem usar esse perfil.
Para obter uma lista de chaves de condição do Amazon EKS, consulte [Condições definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) na *Referência de autorização de serviço*. Para saber com quais ações e recursos você pode usar a chave de condição, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).
1. Em **Namespace do Kubernetes**, selecione o namespace do Kubernetes que contém a conta de serviço e a workload. Opcionalmente, é possível especificar um namespace por nome que não existe no cluster.
1. Em **conta de serviço do Kubernetes**, selecione a conta de serviço do Kubernetes a ser usada. O manifesto da workload do Kubernetes deve especificar essa conta de serviço. Opcionalmente, é possível especificar uma conta de serviço por nome que não existe no cluster.
1. (Opcional) Selecione **Desabilitar tags de sessão** para desabilitar as tags de sessão padrão que a Identidade de Pods adiciona automaticamente quando assume o perfil.
1. (Opcional) Alterne **Configurar política de sessão** para configurar uma política do IAM para aplicar restrições adicionais a essa associação de Identidade de Pods além das permissões definidas na política do IAM anexada ao perfil do IAM.
**nota**
Uma política de sessão só pode ser aplicada quando a configuração **Desabilitar tags de sessão** está marcada.
1. (Opcional) Para as **Tags**, escolha **Adicionar tag** para adicionar metadados em um par de chave e valor. Essas tags são aplicadas à associação e podem ser usadas nas políticas do IAM.
Repita essa etapa para adicionar várias tags.
1. Escolha **Criar**.
## Criar uma associação de identidade de pod (AWS CLI)
1. Se você quiser associar uma política do IAM existente ao seu perfil do IAM, vá para a próxima etapa.
Crie uma política do IAM. É possível criar a sua própria política ou copiar uma política gerenciada da AWS que já conceda algumas das permissões de que você precisa e a personalizar de acordo com seus requisitos específicos. Para obter mais informações, consulte [Criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do usuário do IAM*.
1. Crie um arquivo que inclua as permissões para os serviços da AWS que você deseja que os pods acessem. Para obter uma lista de todas as ações de todos os serviços do AWS, consulte a [Referência de autorização de serviço](https://docs.aws.amazon.com/service-authorization/latest/reference/).
É possível executar o comando a seguir para criar um arquivo de política de exemplo que permita acesso somente leitura a um bucket do Amazon S3. É possível, opcionalmente, armazenar informações de configuração ou um script de bootstrap nesse bucket, e os contêineres no pod podem ler o arquivo do bucket e carregá-lo na aplicação. Se você quiser criar esse exemplo de política, copie o conteúdo a seguir para o seu dispositivo. Substitua *my-pod-secrets-bucket* pelo nome do seu bucket e execute o comando.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
1. Crie a política do IAM.
```
aws iam create-policy --policy-name my-policy --policy-document file://my-policy.json
```
1. Crie um perfil do IAM e associe-o a uma conta de serviço do Kubernetes.
1. Se você já tem um conta de serviço do Kubernetes na qual deseja assumir um perfil do IAM, você pode ignorar esta etapa.
Crie uma conta de serviço do Kubernetes. Copie o conteúdo a seguir para o seu dispositivo. Substitua *my-service-account* pelo nome desejado e *default* (padrão) por um namespace diferente, se necessário. Se você alterar o *padrão*, o namespace já deve existir.
```
cat >my-service-account.yaml <
1. Confirme se a política de confiança do perfil do IAM está configurada corretamente.
```
aws iam get-role --role-name my-role --query Role.AssumeRolePolicyDocument
```
Veja abaixo um exemplo de saída.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "Allow EKS Auth service to assume this role for Pod Identities",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
1. Confirme se a política que você anexou ao seu perfil em uma etapa anterior está vinculada ao perfil.
```
aws iam list-attached-role-policies --role-name my-role --query 'AttachedPolicies[].PolicyArn' --output text
```
Veja um exemplo de saída abaixo.
```
arn:aws:iam::111122223333:policy/my-policy
```
1. Defina uma variável para armazenar o nome do recurso da Amazon (ARN) da política que deseja usar. Substitua *my-policy* pelo nome da política para a qual deseja confirmar permissões.
```
export policy_arn=arn:aws:iam::111122223333:policy/my-policy
```
1. Visualize a versão padrão da política.
```
aws iam get-policy --policy-arn $policy_arn
```
Veja abaixo um exemplo de saída.
```
{
"Policy": {
"PolicyName": "my-policy",
"PolicyId": "EXAMPLEBIOWGLDEXAMPLE",
"Arn": "arn:aws:iam::111122223333:policy/my-policy",
"Path": "/",
"DefaultVersionId": "v1",
[...]
}
}
```
1. Confira o conteúdo da política para garantir que ela inclua todas as permissões de que seu pod precisa. Se necessário, substitua*1* no comando a seguir pela versão retornada na saída anterior.
```
aws iam get-policy-version --policy-arn $policy_arn --version-id v1
```
Veja abaixo um exemplo de saída.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-pod-secrets-bucket"
}
]
}
```
Se você criou a política de exemplo em uma etapa anterior, sua saída será a mesma. Se você criou uma política diferente, então o *exemplo* de conteúdo é diferente.
## Próximas etapas
[Configurar pods para acessar serviços da AWS com contas de serviço](pod-id-configure-pods.md)
# Acessar Recursos da AWS usando os perfis do IAM de destino da Identidade de Pods do EKS
Ao executar aplicações no Amazon Elastic Kubernetes Service (Amazon EKS), talvez você precise acessar recursos da AWS que existem em diferentes contas da AWS. Este guia mostra como configurar o acesso entre contas usando a Identidade de Pods do EKS, que permite que seus pods do Kubernetes acessem outros recursos da AWS usando perfis de destino.
## Pré-requisitos
Antes de começar, certifique-se de ter concluído as seguintes etapas:
+ [Configurar o agente da Identidade de Pods do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html)
+ [Criar perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html)
## Como funciona
A Identidade de Pods permite que as aplicações em seu cluster de EKS acessem recursos da AWS em várias contas por meio de um processo chamado encadeamento de perfis.
Ao criar uma associação da Identidade de Pods, é possível fornecer dois perfis do IAM: um [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) na mesma conta do cluster de EKS e um perfil do IAM de destino da conta que contém os recursos da AWS (como buckets do S3 ou bancos de dados RDS). O [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) deve estar na conta do cluster de EKS devido aos requisitos do [IAM PassRole](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_iam-passrole-service.html), enquanto o perfil do IAM de destino pode estar em qualquer conta da AWS. O PassRole permite que uma entidade da AWS delegue a suposição de perfil a outro serviço. A Identidade de Pods do EKS usa o PassRole para conectar um perfil a uma conta de serviço do Kubernetes, exigindo que o perfil e a identidade que a transmitem estejam na mesma conta da AWS que o cluster de EKS. Quando o pod da aplicação precisa acessar os recursos da AWS, ele solicita as credenciais da Identidade de Pods. Em seguida, a Identidade de Pods executa automaticamente duas suposições de perfil em sequência: primeiro, assumindo o [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) e, em seguida, usando essas credenciais para assumir o perfil do IAM de destino. Esse processo fornece ao seu pod credenciais temporárias que têm as permissões definidas no perfil de destino, permitindo acesso seguro aos recursos em outras contas da AWS.
## Considerações sobre armazenamento em cache
Devido aos mecanismos de armazenamento em cache, as atualizações de um perfil do IAM em uma associação existente da Identidade de Pods podem não entrar em vigor imediatamente nos pods em execução no cluster de EKS. O agente da Identidade de Pods armazena em cache as credenciais do IAM com base na configuração da associação no momento em que as credenciais são obtidas. Se a associação incluir apenas um [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) e nenhum perfil do IAM de destino, a duração das credenciais em cache será de seis horas. Se a associação incluir o ARN do [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) e um perfil do IAM de destino, as credenciais em cache vão durar 59 minutos. Modificar uma associação existente, como atualizar o ARN do [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) ou adicionar um perfil do IAM de destino, não redefine o cache existente. Como resultado, o agente não reconhecerá as atualizações até que as credenciais em cache sejam atualizadas. Para aplicar as alterações antes, você pode recriar os pods existentes; caso contrário, você precisará esperar que o cache expire.
## Etapa 1: criar e associar um perfil do IAM de destino
Nesta etapa, você estabelecerá uma cadeia de confiança segura criando e configurando um perfil do IAM de destino. Para fins de demonstração, criaremos um novo perfil do IAM de destino para estabelecer uma cadeia de confiança entre duas contas da AWS: o [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) (por exemplo, `eks-pod-identity-primary-role`) na conta da AWS do cluster de EKS ganha permissão para assumir o perfil do IAM de destino (por exemplo, `eks-pod-identity-aws-resources`) em sua conta de destino, permitindo o acesso a recursos da AWS como buckets do Amazon S3.
### Criar perfil do IAM de destino
1. Abra o [console do Amazon IAM](https://console.aws.amazon.com/iam/home).
1. Na barra de navegação superior, verifique se você fez login na conta que contém os recursos da AWS (como buckets do S3 ou tabelas do DynamoDB) para o perfil do IAM de destino.
1. No painel de navegação à esquerda, selecione **Perfis**.
1. Escolha o botão **Criar perfil** e, em seguida, **Conta da AWS** em "Tipo de entidade confiável".
1. Escolha **Outra conta da AWS**, insira o número da sua conta da AWS (a conta em que seu [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) existe) e escolha **Avançar**.
1. Adicione as políticas de permissão que você gostaria de associar ao perfil (por exemplo, AmazonS3FullAccess) e escolha **Avançar**.
1. Insira um nome de perfil, como `MyCustomIAMTargetRole`, e escolha **Criar perfil**.
### Atualizar a política de confiança de um perfil do IAM de destino
1. Depois de criar o perfil, você retornará à lista de **Perfis**. Encontre e selecione o novo perfil que você criou na etapa anterior (por exemplo, `MyCustomIAMTargetRole`).
1. Selecione a guia **Relações de confiança**.
1. Clique em **Editar política de confiança** no lado direito.
1. No editor de políticas, substitua a política JSON padrão pela sua política de confiança. Substitua os valores do espaço reservado pelo nome do perfil e `111122223333` no ARN do perfil do IAM pelo ID da conta da AWS que hospeda o cluster de EKS. Opcionalmente, você também pode usar PrincipalTags na política de confiança do perfil para autorizar somente contas de serviço específicas de um determinado cluster e namespace a assumir seu perfil de destino. Por exemplo:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/eks-cluster-arn": "arn:aws:eks:us-east-1:111122223333:cluster/example-cluster",
"aws:RequestTag/kubernetes-namespace": "ExampleNameSpace",
"aws:RequestTag/kubernetes-service-account": "ExampleServiceAccountName"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
}
]
}
```
A política acima permite que o perfil `eks-pod-identeity-primary-role` da conta da AWS 111122223333 com as tags de sessão de [Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html) relevantes assumam esse perfil.
Se você [desativou as tags de sessão](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-abac.html#pod-id-abac-tags) na sua Identidade de Pods do EKS, a Identidade de Pods do EKS também define `sts:ExternalId` com informações sobre o cluster, namespace e conta de serviço de um pod ao assumir um perfil de destino.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"sts:ExternalId": "region/111122223333/cluster-name/namespace/service-account-name"
},
"ArnEquals": {
"aws:PrincipalARN": "arn:aws:iam::111122223333:role/eks-pod-identity-primary-role"
}
}
},
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "sts:TagSession"
}
]
}
```
A política acima ajuda a garantir que somente o cluster, namespace e conta de serviço esperados possam assumir o perfil de destino.
### Atualizar a política de permissão para o perfil da Identidade de Pods do EKS
Nesta etapa, você atualizará a política de permissão do [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) associada ao cluster do Amazon EKS adicionando o ARN do perfil do IAM de destino como um recurso.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, selecione **Clusters** e depois o nome do seu cluster de EKS.
1. Escolha a guia **Acesso**.
1. Em **Associações da Identidade de Pods**, selecione seu [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. Escolha **Permissões**, **Adicionar permissões** e **Criar política em linha**.
1. Escolha **JSON** no lado direito.
1. No editor de políticas, substitua a política JSON padrão pela sua política de permissão. Substitua o valor do espaço reservado pelo nome do perfil e `222233334444` no ARN do perfil do IAM pelo perfil do IAM de destino. Por exemplo:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Resource": "arn:aws:iam::222233334444:role/eks-pod-identity-aws-resources"
}
]
}
```
## Etapa 2: associar o perfil do IAM de destino a uma conta de serviço do Kubernetes
Nesta etapa, você criará uma associação entre o perfil do IAM de destino e a conta de serviço do Kubernetes no cluster de EKS.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, selecione **Clusters** e depois o nome do cluster para o qual você deseja adicionar a associação.
1. Escolha a guia **Acesso**.
1. Nas **Associações do Pod Identity**, escolha **Criar**.
1. Escolha o [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html) em **Perfil do IAM** para que suas workloads assumam.
1. Escolha o perfil do IAM de destino em **Perfil do IAM de destino** que será assumido pelo [perfil da Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-role.html).
1. No campo **Namespace do Kubernetes**, insira o nome do namespace em que você deseja criar a associação (por exemplo, `my-app-namespace`). Isso definirá onde a conta de serviço vai residir.
1. No campo **Conta de serviço do Kubernetes**, insira o nome da conta de serviço (por exemplo, `my-service-account`) que usará as credenciais do IAM. Isso vinculará o perfil do IAM à conta de serviço.
1. (Opcional) Selecione **Desabilitar tags de sessão** para desabilitar as tags de sessão padrão que a Identidade de Pods adiciona automaticamente quando assume o perfil.
1. (Opcional) Alterne **Configurar política de sessão** para configurar uma política do IAM para aplicar restrições adicionais a essa associação de Identidade de Pods além das permissões definidas na política do IAM anexada ao **perfil do IAM de destino**.
**nota**
1. Uma política de sessão só pode ser aplicada quando a configuração **Desabilitar tags de sessão** está marcada. 2. Se você especificar uma política de sessão, as restrições da política se aplicarão às permissões do **perfil do IAM de destino**, e não ao **perfil do IAM** associado a essa associação de Identidade de Pods.
1. Escolha **Criar** para criar a associação.
# Configurar pods para acessar serviços da AWS com contas de serviço
Se um pod precisar acessar os serviços da AWS, você deverá configurá-lo para usar uma conta de serviço do Kubernetes. A conta de serviço deve estar associada a um perfil do AWS Identity and Access Management (IAM) que tenha permissões para acessar os serviços da AWS.
+ Um cluster existente. Se não tiver um, você poderá criá-lo usando um dos guias em [Começar a usar o Amazon EKS](getting-started.md).
+ Uma associação existente entre a conta de serviço do Kubernetes e a Identidade de Pods do EKS que associa a conta de serviço a um perfil do IAM. O perfil deve ter uma política do IAM associada que contenha as permissões que você deseja que os pods tenham para usar os serviços da AWS. Para obter mais informações sobre como criar a conta de serviço e como configurá-la, consulte [Atribuir um perfil do IAM a uma conta de serviço do Kubernetes](pod-id-association.md).
+ A versão mais recente da AWS CLI instalada e configurada em seu dispositivo ou no AWS CloudShell. É possível verificar sua versão atual com `aws --version | cut -d / -f2 | cut -d ' ' -f1`. Os gerenciadores de pacotes, como `yum`, `apt-get` ou Homebrew para macOS, geralmente estão várias versões atrás da versão mais recente da AWS CLI. Para instalar a versão mais recente, consulte [Instalar](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) e [Configuração rápida com aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config), no Guia do usuário da AWS Command Line Interface. A versão da AWS CLI instalada no AWS CloudShell também pode estar várias versões atrás da versão mais recente. Para atualizá-lo, consulte [Instalar a AWS CLI no seu diretório pessoal](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software), no Guia do usuário do AWS CloudShell.
+ A ferramenta da linha de comando `kubectl` está instalada no seu dispositivo ou no AWS CloudShell. A versão pode ser a mesma ou até uma versão secundária anterior ou posterior à versão do Kubernetes do seu cluster. Por exemplo, se a versão do cluster for a `1.29`, você poderá usar o `kubectl` versão `1.28`, `1.29` ou `1.30` com ele. Para instalar ou atualizar o `kubectl`, consulte [Configurar o `kubectl` e o `eksctl`](install-kubectl.md).
+ Um arquivo `kubectl` `config` existente que contém a configuração do seu cluster. Para criar um arquivo `kubectl` `config`, consulte [Conecte o kubectl a um cluster de EKS criando um arquivo kubeconfig](create-kubeconfig.md).
1. Use o comando a seguir para criar um manifesto de implantação com o qual é possível implantar um pod para confirmar a configuração. Substitua os valores de exemplo por seus próprios valores.
```
cat >my-deployment.yaml <
O controle de acesso por atributo (ABAC) concede direitos aos usuários por meio de políticas que combinam os atributos. A Identidade de Pods do EKS anexa tags às credenciais temporárias de cada pod com atributos como nome do cluster, namespace e nome da conta de serviço. Essas tags de sessão de perfil permitem que os administradores criem um único perfil que pode funcionar em várias contas de serviço, permitindo o acesso aos recursos da AWS com base em tags correspondentes. Ao adicionar suporte a tags de sessão de perfil, você pode impor limites de segurança mais rígidos entre clusters e workloads dentro dos clusters enquanto reutilizam os mesmos perfis e políticas do IAM.
## Exemplo de política com tags
Confira abaixo um exemplo de política do IAM que concede permissões `s3:GetObject` quando o objeto correspondente é marcado com o nome do cluster do EKS.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectTagging"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"s3:ExistingObjectTag/eks-cluster-name": "${aws:PrincipalTag/eks-cluster-name}"
}
}
}
]
}
```
## Habilitar ou desabilitar tags de sessão
A Identidade de Pods do EKS adiciona um conjunto predefinido de tags de sessão quando assume o perfil. Essas tags de sessão permitem que os administradores criem um único perfil que pode funcionar em vários recursos, permitindo o acesso aos recursos da AWS com base em tags correspondentes.
### Habilitar tags de sessão
As tags de sessão são automaticamente habilitadas com a Identidade de Pods do EKS. Nenhuma ação é necessária de sua parte. Por padrão, a Identidade de Pods do EKS anexa um conjunto de tags predefinidas à sua sessão. Para referenciar essas tags nas políticas, use a sintaxe `${aws:PrincipalTag/` seguida pela chave da tag. Por exemplo, `${aws:PrincipalTag/kubernetes-namespace}`.
+ `eks-cluster-arn`
+ `eks-cluster-name`
+ `kubernetes-namespace`
+ `kubernetes-service-account`
+ `kubernetes-pod-name`
+ `kubernetes-pod-uid`
### Desabilitar tags de sessão
A AWS compacta políticas de sessão em linha, ARNs de política gerenciada e tags de sessão em um formato binário compactado que tem um limite separado. Caso receba um erro `PackedPolicyTooLarge` indicando que o formato binário compactado excedeu o limite de tamanho, você pode tentar reduzir o tamanho desabilitando as tags de sessão adicionadas pela Identidade de Pods do EKS. Para desabilitar essas tags de sessão, siga estas etapas:
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação à esquerda, selecione **Clusters** e depois o nome do cluster que você deseja modificar.
1. Escolha a guia **Acesso**.
1. Nas **Associações de Identidade de Pods**, escolha o ID da associação que você gostaria de modificar em **ID da associação** e depois **Editar**.
1. Em **Tags de sessão**, escolha **Desabilitar tags de sessão**.
1. Escolha **Salvar alterações**.
## Cópia entre contas
Todas as tags de sessão adicionadas pelo EKS Pod Identity são *transitivas*; as chaves e os valores das tags são passados para quaisquer ações `AssumeRole` usadas por suas workloads para trocar de perfil para outra conta. Você pode usar essas tags em políticas de outras contas para limitar o acesso em cenários entre contas. Para obter mais informações, consulte [Encadeamento de funções com tags de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_session-tags.html#id_session-tags_role-chaining) no *Guia do usuário do IAM*.
## Tags personalizadas
O EKS Pod Identity não pode adicionar outras tags personalizadas à ação `AssumeRole` que ele mesmo executa. No entanto, as tags que você aplica ao perfil do IAM estão sempre disponíveis no mesmo formato: `${aws:PrincipalTag/` seguida pela chave, por exemplo, `${aws:PrincipalTag/MyCustomTag}`.
**nota**
As tags adicionadas à sessão por meio da solicitação `sts:AssumeRole` têm precedência em caso de conflito. Por exemplo, vamos supor que:
O Amazon EKS adiciona uma chave `eks-cluster-name` e um valor `my-cluster` à sessão quando o EKS assume o perfil de cliente.
Você adiciona uma tag `eks-cluster-name` ao perfil do IAM com o valor `my-own-cluster`.
Nesse caso, o primeiro tem precedência e o valor da tag `eks-cluster-name` será `my-cluster`.
# Usar identidade de pods com o AWS SDK
## Usar as credenciais da Identidade de Pods do EKS
Para usar as credenciais de uma associação de identidade de pod EKS, seu código pode usar qualquer SDK AWS para criar um cliente para um serviço AWS com um SDK e, por padrão, o SDK pesquisa em uma cadeia de locais as credenciais de gerenciamento de identidade e acesso AWS a serem usadas. As credenciais da Identidade de Pods do EKS serão usadas se você não especificar um provedor de credenciais ao criar o cliente ou ao inicializar o SDK.
Isso funciona porque as identidades de Pods do EKS foram adicionadas ao *Provedor de credenciais do contêiner*, o qual é pesquisado em uma etapa na cadeia de credenciais padrão. Se suas workloads usam no momento credenciais mais antigas na cadeia de credenciais, essas credenciais continuarão sendo usadas mesmo se você configurar uma associação da Identidade de Pods do EKS para a mesma workload.
Para obter mais informações sobre como as identidades do EKS Pod funcionam, consulte [Como a Identidade de Pods do EKS funciona](pod-id-how-it-works.md).
Ao usar [Saiba como Identidade de Pods do EKS concede acesso a serviços da AWS para pods](pod-identities.md), os contêineres nos pods devem usar uma versão do AWS SDK que permita assumir um perfil do IAM do atendente da Identidade de Pods do EKS. Certifique-se de usar as seguintes versões, ou versões posteriores, do AWS SDK:
+ Java (versão 2): [2.21.30](https://github.com/aws/aws-sdk-java-v2/releases/tag/2.21.30)
+ Java: [1.12.746](https://github.com/aws/aws-sdk-java/releases/tag/1.12.746)
+ Go v1: [v1.47.11](https://github.com/aws/aws-sdk-go/releases/tag/v1.47.11)
+ Go v2: [release-2023-11-14](https://github.com/aws/aws-sdk-go-v2/releases/tag/release-2023-11-14)
+ Python (Boto3): [1.34.41](https://github.com/boto/boto3/releases/tag/1.34.41)
+ Python (botocore): [1.34.41](https://github.com/boto/botocore/releases/tag/1.34.41)
+ AWS CLI: [1.30.0](https://github.com/aws/aws-cli/releases/tag/1.30.0)
AWS CLI – [2.15.0](https://github.com/aws/aws-cli/releases/tag/2.15.0)
+ JavaScript v2: [2.1550.0](https://github.com/aws/aws-sdk-js/releases/tag/v2.1550.0)
+ JavaScript v3: [3.458.0](https://github.com/aws/aws-sdk-js-v3/releases/tag/v3.458.0)
+ Kotlin: [v1.0.1](https://github.com/awslabs/aws-sdk-kotlin/releases/tag/v1.0.1)
+ Ruby: [3.188.0](https://github.com/aws/aws-sdk-ruby/blob/version-3/gems/aws-sdk-core/CHANGELOG.md#31880-2023-11-22)
+ Rust: [release-2024-03-13](https://github.com/awslabs/aws-sdk-rust/releases/tag/release-2024-03-13)
+ C\$1\$1: [1.11.263](https://github.com/aws/aws-sdk-cpp/releases/tag/1.11.263)
+ .NET: [3.7.734.0](https://github.com/aws/aws-sdk-net/releases/tag/3.7.734.0)
+ PowerShell: [4.1.502](https://www.powershellgallery.com/packages/AWS.Tools.Common/4.1.502)
+ PHP: [3.289.0](https://github.com/aws/aws-sdk-php/releases/tag/3.287.1)
Para garantir que você esteja usando um SDK compatível, siga as instruções de instalação do SDK de sua preferência em [Ferramentas para desenvolver na AWS](https://aws.amazon.com/tools/) quando estiver criando seus contêineres.
Para obter uma lista de complementos compatíveis com Identidade de Pods do EKS, consulte [Referência de suporte de Identidade de Pods](retreive-iam-info.md#pod-id-add-on-versions).
# Desabilitar o `IPv6` no EKS Pod Identity Agent
## Console de gerenciamento da AWS
1. Para desabilitar o `IPv6` no EKS Pod Identity Agent, adicione a configuração a seguir às **Configurações opcionais** do EKS Add-on.
1. Abra o [console do Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. No painel de navegação esquerdo, selecione **Clusters** e depois o nome do cluster para o qual você deseja configurar o complemento.
1. Escolha a guia **Add-ons** (Complementos).
1. Selecione a caixa no canto superior direito da caixa do complemento do EKS Pod Identity Agent e escolha **Editar**.
1. Na página **Configurar o EKS Pod Identity Agent**:
1. Selecione a **Versão** que você deseja usar. Recomendamos manter a mesma versão da etapa anterior e atualizar a versão e a configuração em ações separadas.
1. Expanda **Definições de configuração opcionais**.
1. Insira a chave JSON `"agent":` e o valor de um objeto JSON aninhado com uma chave `"additionalArgs":` em **Valores de configuração**. O texto resultante deve ser um objeto JSON válido. Se esse par de chave e valor for o único dado na caixa de texto, coloque-o entre colchetes `{ }`. O exemplo apresentado a seguir mostra que a política de rede está habilitada:
```
{
"agent": {
"additionalArgs": {
"-b": "169.254.170.23"
}
}
}
```
Essa configuração define o endereço `IPv4` como o único usado pelo agente.
1. Para aplicar a nova configuração substituindo os pods do EKS Pod Identity Agent, escolha **Salvar alterações**.
O Amazon EKS aplica as alterações nos complementos do EKS usando uma *distribuição* do `DaemonSet` do Kubernetes para o agente da Identidade de Pods do EKS. É possível acompanhar o status da implantação no **Histórico de atualizações** do complemento no Console de gerenciamento da AWS e com `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
`kubectl rollout` oferece os seguintes comandos:
```
$ kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Se a distribuição demorar muito, o Amazon EKS desfará a distribuição e uma mensagem com o tipo **Atualização do complemento** e o status **Falha** será adicionada ao **Histórico de atualizações** do complemento. Para investigar qualquer problema, comece com o histórico da distribuição e execute `kubectl logs` em um pod do EKS Pod Identity Agent para ver os logs do EKS Pod Identity Agent.
1. Se a nova entrada no **Histórico de atualizações** tiver o status de **Êxito**, a distribuição foi concluída e o complemento está usando a nova configuração em todos os pods do EKS Pod Identity Agent.
## AWS CLI
1. Para desabilitar o `IPv6` no EKS Pod Identity Agent, adicione a seguinte configuração aos **valores de configuração** do EKS Add-on.
Execute o seguinte comando da AWS CLI. Substitua `my-cluster` pelo nome do cluster e o ARN do perfil do IAM pelo perfil que você está usando.
```
aws eks update-addon --cluster-name my-cluster --addon-name eks-pod-identity-agent \
--resolve-conflicts PRESERVE --configuration-values '{"agent":{"additionalArgs": { "-b": "169.254.170.23"}}}'
```
Essa configuração define o endereço `IPv4` como o único usado pelo agente.
O Amazon EKS aplica as alterações nos complementos do EKS usando uma *distribuição* do DaemonSet do Kubernetes para o agente da Identidade de Pods do EKS. É possível acompanhar o status da implantação no **Histórico de atualizações** do complemento no Console de gerenciamento da AWS e com `kubectl rollout status daemonset/eks-pod-identity-agent --namespace kube-system`.
`kubectl rollout` oferece os seguintes comandos:
```
kubectl rollout
history -- View rollout history
pause -- Mark the provided resource as paused
restart -- Restart a resource
resume -- Resume a paused resource
status -- Show the status of the rollout
undo -- Undo a previous rollout
```
Se a distribuição demorar muito, o Amazon EKS desfará a distribuição e uma mensagem com o tipo **Atualização do complemento** e o status **Falha** será adicionada ao **Histórico de atualizações** do complemento. Para investigar qualquer problema, comece com o histórico da distribuição e execute `kubectl logs` em um pod do EKS Pod Identity Agent para ver os logs do EKS Pod Identity Agent.
# Criar um perfil do IAM com a política de confiança exigida pela Identidade de Pods do EKS
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
** `sts:AssumeRole` **
A Identidade de Pods do EKS usa `AssumeRole` para assumir o perfil do IAM antes de passar as credenciais temporárias para seus pods.
** `sts:TagSession` **
A Identidade de Pods do EKS usa `TagSession` para incluir *tags de sessão* nas solicitações para AWS STS.
**Configuração de condições**
É possível usar essas tags nas *chaves de condição* na política de confiança para restringir quais contas de serviço, namespaces e clusters podem usar esse perfil. Para ter acesso à lista de tags de solicitação disponível com a Identidade de Pods, consulte [Habilitar ou desabilitar tags de sessão](pod-id-abac.md#pod-id-abac-tags).
Por exemplo, você pode restringir quais pods podem assumir o papel de um perfil do IAM de Identidade de Pods para uma `ServiceAccount` e `Namespace` específicos com a seguinte Política de confiança com a adição de `Condition`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowEksAuthToAssumeRoleForPodIdentity",
"Effect": "Allow",
"Principal": {
"Service": "pods.eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/kubernetes-namespace": [
"Namespace"
],
"aws:RequestTag/kubernetes-service-account": [
"ServiceAccount"
]
}
}
}
]
}
```
Para obter uma lista de chaves de condição do Amazon EKS, consulte [Condições definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-policy-keys) na *Referência de autorização de serviço*. Para saber com quais ações e recursos você pode usar a chave de condição, consulte [Ações definidas pelo Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions).