**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.

# Funções do IAM para contas de serviço
<a name="iam-roles-for-service-accounts"></a>

**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)
<a name="irsa-oidc-background"></a>

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
<a name="enable-iam-roles-for-service-accounts"></a>

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
<a name="_prerequisites"></a>
+ 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)
<a name="_create_oidc_provider_eksctl"></a>

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 `<my-cluster>` pelos seus próprios valores.

   ```
   cluster_name=<my-cluster>
   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.<region-code>.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)
<a name="create_oidc_provider_shared_aws_console"></a>

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
<a name="associate-service-account-role"></a>

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
<a name="_prerequisites"></a>
+ 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
<a name="irsa-associate-role-procedure"></a>

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
<a name="_step_2_create_and_associate_iam_role"></a>

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)
<a name="_create_and_associate_role_eksctl"></a>

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)
<a name="create_and_associate_role_shared_aws_cli"></a>

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 <<EOF
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-service-account
     namespace: default
   EOF
   kubectl apply -f my-service-account.yaml
   ```

1. Defina o ID da conta da AWS como uma variável de ambiente com o comando a seguir.

   ```
   account_id=$(aws sts get-caller-identity --query "Account" --output text)
   ```

1. Defina o provedor de identidade OIDC do cluster como uma variável de ambiente com o comando a seguir. Substitua *my-cluster* pelo nome do cluster.

   ```
   oidc_provider=$(aws eks describe-cluster --name my-cluster --region $AWS_REGION --query "cluster.identity.oidc.issuer" --output text | sed -e "s/^https:\/\///")
   ```

1. Defina variáveis para o namespace e o nome da conta de serviço. Substitua *my-service-account* pela conta de serviço do Kubernetes que você deseja que assuma o perfil. Substitua *default* (padrão) pelo namespace da conta de serviço.

   ```
   export namespace=default
   export service_account=my-service-account
   ```

1. Execute o seguinte comando para criar um arquivo de política de confiança para o perfil do IAM. Se você quiser permitir que todas as contas de serviço em um namespace usem o perfil, copie o conteúdo a seguir para o seu dispositivo. Substitua *StringEquals* por `StringLike` e substitua *\$1service\$1account* por `*`. É possível adicionar várias entradas nas condições `StringEquals` ou `StringLike` abaixo para permitir que várias contas de serviço ou namespaces assumam o perfil. Para permitir que perfis de uma conta da AWS diferente da conta em que seu cluster está assumam o perfil, consulte [Autenticar em outra conta com IRSA](cross-account-access.md) para obter mais informações.

   ```
   {
     "Version":"2012-10-17",		 	 	 
     "Statement": [
       {
         "Effect": "Allow",
         "Principal": {
           "Federated": "arn:aws:iam::123456789012:oidc-provider/$oidc_provider"
         },
         "Action": "sts:AssumeRoleWithWebIdentity",
         "Condition": {
           "StringEquals": {
             "$oidc_provider:aud": "sts.amazonaws.com",
             "$oidc_provider:sub": "system:serviceaccount:$namespace:$service_account"
           }
         }
       }
     ]
   }
   ```

1. Crie a função. Substitua *my-role* por um nome para seu perfil do IAM e *my-role-description* por uma descrição para seu perfil.

   ```
   aws iam create-role --role-name my-role --assume-role-policy-document file://trust-relationship.json --description "my-role-description"
   ```

1. Associe uma política do IAM ao seu perfil. Substitua *my-role* pelo nome do seu perfil do IAM e *my-policy* pelo nome de uma política existente que você criou.

   ```
   aws iam attach-role-policy --role-name my-role --policy-arn=arn:aws:iam::$account_id:policy/my-policy
   ```

1. Anote sua conta de serviço com o nome do recurso da Amazon (ARN) do perfil do IAM que você deseja que a conta de serviço assuma. Substitua *my-role* pelo nome do seu perfil do IAM existente. Suponha que você tenha permitido que um perfil de uma conta AWS diferente da conta na qual seu cluster está assumisse o perfil em uma etapa anterior. Em seguida, certifique-se de especificar a conta AWS e o perfil da outra conta. Para obter mais informações, consulte [Autenticar em outra conta com IRSA](cross-account-access.md).

   ```
   kubectl annotate serviceaccount -n $namespace $service_account eks.amazonaws.com/role-arn=arn:aws:iam::$account_id:role/my-role
   ```

1. (Opcional) [Configure o endpoint do AWS Security Token Service para uma conta de serviço.](configure-sts-endpoint.md) A AWS recomenda o uso de um endpoint regional 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.

## Etapa 3: confirmar a configuração
<a name="irsa-confirm-role-configuration"></a>

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:  <none>
   Mountable secrets:   my-service-account-token-qqjfl
   Tokens:              my-service-account-token-qqjfl
   [...]
   ```

## Próximas etapas
<a name="_next_steps"></a>
+  [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
<a name="pod-configuration"></a>

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 <<EOF
     apiVersion: apps/v1
     kind: Deployment
     metadata:
       name: my-app
     spec:
       selector:
         matchLabels:
           app: my-app
       template:
         metadata:
           labels:
             app: my-app
         spec:
           serviceAccountName: my-service-account
           containers:
           - name: my-app
             image: public.ecr.aws/nginx/nginx:X.XX
     EOF
     ```

  1. Implante o manifesto no seu cluster.

     ```
     kubectl apply -f my-deployment.yaml
     ```

  1. Verifique se as variáveis de ambiente necessárias existem para o pod.

     1. Visualize os pods que foram implantados na implantação da etapa anterior.

        ```
        kubectl get pods | grep my-app
        ```

        Veja abaixo um exemplo de saída.

        ```
        my-app-6f4dfff6cb-76cv9   1/1     Running   0          3m28s
        ```

     1. Visualize o ARN do perfil do IAM que o pod está usando.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_ROLE_ARN:
        ```

        Veja abaixo um exemplo de saída.

        ```
        AWS_ROLE_ARN:                 arn:aws:iam::111122223333:role/my-role
        ```

        O ARN do perfil deve corresponder ao ARN do perfil com o qual você anotou a conta de serviço existente. Para saber mais sobre como fazer anotações na conta de serviço, consulte [Atribuir perfis do IAM às contas de serviço do Kubernetes](associate-service-account-role.md).

     1. Verifique se o pod tem um arquivo de token de identidade da web montado.

        ```
        kubectl describe pod my-app-6f4dfff6cb-76cv9 | grep AWS_WEB_IDENTITY_TOKEN_FILE:
        ```

        Veja abaixo um exemplo de saída.

        ```
        AWS_WEB_IDENTITY_TOKEN_FILE:  /var/run/secrets/eks.amazonaws.com/serviceaccount/token
        ```

        O `kubelet` solicita e armazena o token em nome do pod. Por padrão, o `kubelet` atualiza o token se ele for mais antigo do que 80% do seu tempo de vida total, ou se o token tiver mais de 24 horas. Você pode modificar a duração da expiração de qualquer conta, exceto a conta de serviço padrão, usando as configurações na especificação do pod. Para obter mais informações, consulte [Service Account Token Volume Projection](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection) (Projeção do volume de tokens da conta de serviço) na documentação do Kubernetes.

        O [Webhook de Identidade de Pods do Amazon EKS](https://github.com/aws/amazon-eks-pod-identity-webhook#amazon-eks-pod-identity-webhook) no cluster observa os pods que usam uma conta de serviço com a seguinte anotação:

        ```
        eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/my-role
        ```

        O webhook aplica as variáveis de ambiente anteriores a esses pods. Seu cluster não precisa usar o webhook para configurar as variáveis de ambiente e montagens de arquivos do token. Você pode configurar manualmente os pods para ter essas variáveis de ambiente. As [versões compatíveis do SDK da AWS](iam-roles-for-service-accounts-minimum-sdk.md) procuram essas variáveis de ambiente primeiro no fornecedor da cadeia de credenciais. As credenciais de perfil são usadas para os pods que atendem a esses critérios.

  1. Verifique se os pods podem interagir com os serviços da AWS usando as permissões que você atribuiu na política do IAM anexada ao seu perfil.
**nota**  
Quando um pod usa as credenciais da AWS de um perfil do IAM associado a uma conta de serviço, a AWS CLI ou outros SDKs nos contêineres desse pod usam as credenciais fornecidas por esse perfil. Se você não restringir o acesso às credenciais fornecidas ao [perfil do IAM do nó do Amazon EKS](create-node-role.md), o pod ainda terá acesso a elas. Para obter mais informações, consulte [Restringir o acesso ao perfil de instância atribuído ao nó de processamento](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).

     Se os pods não conseguirem interagir com os serviços conforme o esperado, conclua as etapas a seguir para verificar se tudo está configurado corretamente.

     1. Verifique se os pods usam 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. Para obter mais informações, consulte [Usar o IRSA com o AWS SDK](iam-roles-for-service-accounts-minimum-sdk.md).

     1. Confirme se a implantação está usando a conta de serviço.

        ```
        kubectl describe deployment my-app | grep "Service Account"
        ```

        Veja abaixo um exemplo de saída.

        ```
        Service Account:  my-service-account
        ```

     1. Se os pods ainda não conseguirem acessar os serviços, revise as [etapas](associate-service-account-role.md#irsa-confirm-role-configuration) descritas em [Atribuir perfis do IAM a contas de serviço do Kubernetes](associate-service-account-role.md) para verificar se seu perfil e conta de serviço estão configurados corretamente.

# Configurar o endpoint do AWS Security Token Service para uma conta de serviço
<a name="configure-sts-endpoint"></a>

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
<a name="cross-account-access"></a>

É 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
<a name="_option_1_create_an_identity_provider_from_another_accounts_cluster"></a>

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
<a name="_option_2_use_chained_assumerole_operations"></a>

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 name="_step_1_create_the_target_role_in_account_b"></a>

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 name="_step_2_create_the_irsa_role_in_account_a"></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 name="_step_3_attach_the_assumerole_permission_to_account_as_role"></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 name="_step_4_configure_the_pod_to_chain_roles"></a>

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
<a name="iam-roles-for-service-accounts-minimum-sdk"></a>

**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
<a name="_considerations"></a>

### Java
<a name="_java"></a>

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
<a name="irsa-fetch-keys"></a>

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
<a name="_prerequisites"></a>
+ 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
<a name="_procedure"></a>

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