As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Habilitar perfis do IAM para o cluster do EKS Os tópicos a seguir detalham as opções para habilitar perfis do IAM. **Topics** + [Opção 1: habilitar a Identidade de Pods do EKS no cluster do EKS](setting-up-enable-IAM.md) + [Opção 2: habilitar perfis do IAM para contas de serviço (IRSA) no cluster do EKS](setting-up-enable-IAM-service-accounts.md) # Opção 1: habilitar a Identidade de Pods do EKS no cluster do 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ó. O Amazon EMR no EKS começa a oferecer suporte à identidade de pod do EKS desde o lançamento do emr-7.3.0 para o modelo de envio. StartJobRun Para obter mais informações sobre identidades de pods do EKS, consulte [Como funciona a Identidade de Pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-how-it-works.html). ## Por que trabalhar com Identidades de pods do EKS? Como parte da configuração do EMR, o perfil de execução de tarefas precisa estabelecer limites de confiança entre o perfil do IAM e contas de serviço em um namespace específico (de clusters virtuais do EMR). Com o IRSA, isso foi alcançado através da atualização da política de confiança do Perfil de execução de trabalho do EMR. No entanto, devido ao limite rígido de 4096 caracteres no comprimento da política de confiança do IAM, havia uma restrição para compartilhar um único perfil do IAM de execução de trabalho em um máximo de doze (12) clusters do EKS. Com o suporte do EMR para identidades de pods, o limite de confiança entre as funções do IAM e as contas de serviço agora está sendo gerenciado pela equipe do EKS por meio da associação da identidade do pod do EKS. APIs **nota** A fronteira de segurança para identidade de pods do EKS ainda está no nível da conta de serviço, e não no nível do pod. ## Considerações sobre Identidade de Pods Para obter informações sobre as Limitações de identidade de pods, consulte [Considerações sobre Identidade de pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-identities.html#pod-id-considerations). ## Preparar a identidade de pods do EKS no cluster do EKS ### Verifique se a permissão necessária existe em NodeInstanceRole O perfil de nó `NodeInstanceRole` precisa de permissão o agente realizar a ação `AssumeRoleForPodIdentity` na API de autenticação do EKS. Você pode adicionar o seguinte à [Amazon EKSWorker NodePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/security-iam-awsmanpol.html#security-iam-awsmanpol-amazoneksworkernodepolicy), que é definida no Guia do usuário do Amazon EKS, ou usar uma política personalizada. Se seu cluster EKS foi criado com a versão eksctl superior a **0.181.0,** a Amazon, incluindo a `AssumeRoleForPodIdentity` permissão necessária EKSWorkerNodePolicy, será anexada automaticamente à função de nó. Se a permissão não estiver presente, adicione manualmente a seguinte permissão à Amazon, EKSWorker NodePolicy que permite assumir uma função para a identidade do pod. Essa permissão é necessária pelo agente de identidade de pods do EKS para recuperar credenciais para pods. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks-auth:AssumeRoleForPodIdentity" ], "Resource": [ "*" ], "Sid": "AllowEKSAUTHAssumeroleforpodidentity" } ] } ``` ------ ### Criar complemento do agente de identidade do pod do EKS Use o comando a seguir para criar o complemento Agente de identidade de pods do EKS com a versão mais recente: ``` aws eks create-addon --cluster-name cluster-name --addon-name eks-pod-identity-agent kubectl get pods -n kube-system | grep 'eks-pod-identity-agent' ``` Use as etapas a seguir para criar o complemento Agente de identidade de pods do EKS no console do Amazon EKS: 1. Abra o console do Amazon EKS: [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 se os pods do agente estão em execução no seu cluster por meio da CLI. `kubectl get pods -n kube-system | grep 'eks-pod-identity-agent'` Veja a seguir um exemplo de saída: ``` NAME READY STATUS RESTARTS AGE eks-pod-identity-agent-gmqp7 1/1 Running 1 (24h ago) 24h eks-pod-identity-agent-prnsh 1/1 Running 1 (24h ago) 24h ``` Isso configura um novo DaemonSet no `kube-system` namespace. O Amazon EKS Pod Identity Agent, executado em cada nó do EKS, usa a [AssumeRoleForPodIdentity](https://docs.aws.amazon.com/eks/latest/APIReference/API_auth_AssumeRoleForPodIdentity.html)ação para recuperar credenciais temporárias da API EKS Auth. Essas credenciais são então disponibilizadas para AWS SDKs que você execute dentro de seus contêineres. Para obter mais informações, verifique o pré-requisito no documento público: [Configurar o Agente de identidade de pods do EKS](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-agent-setup.html). ## Criar um perfil de execução de trabalho ### Criar ou atualizar o perfil de execução de trabalhos que permite a Identidade de Pods do EKS Para executar workloads no Amazon EMR no EKS, você precisa criar um perfil do IAM. Referimo-nos a esse perfil como perfil de execução de trabalho nesta documentação. Para obter mais informações sobre como criar o perfil do IAM, consulte [Criação de perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) no Guia do usuário. Além disso, você deve criar uma política do IAM que especifique as permissões necessárias para o perfil de execução de trabalho e, em seguida, anexar essa política ao perfil para habilitar a Identidade de Pods do EKS. Por exemplo, você tem o seguinte perfil de execução de trabalho. Para obter mais informações, consulte [Criar um perfil de execução de trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html). ``` arn:aws:iam::111122223333:role/PodIdentityJobExecutionRole ``` **Importante** O Amazon EMR no EKS cria contas de serviço do Kubernetes automaticamente, com base no nome do perfil de execução do trabalho. Certifique-se de que o nome do perfil não seja muito longo, pois seu trabalho poderá falhar se a combinação de `cluster_name`, `pod_name`, `service_account_name` e exceder o limite de comprimento. **Configuração do perfil de execução de trabalho**: certifique-se de que o perfil de execução de trabalho seja criado com a permissão de confiança abaixo para a Identidade de Pods do EKS. Para atualizar um perfil de execução de trabalho existente, configure-o para confiar na seguinte entidade principal de serviço do EKS como uma permissão adicional na política de confiança. Essa permissão de confiança pode coexistir com as políticas de confiança do IRSA existentes. ``` cat >trust-relationship.json < ### Pré-requisito Certifique-se de que a identidade do IAM que cria a associação de identidade de pods, como um usuário administrador do EKS, tenha a permissão `eks:CreatePodIdentityAssociation` e `iam:PassRole`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "eks:CreatePodIdentityAssociation" ], "Resource": [ "arn:aws:eks:*:*:cluster/*" ], "Sid": "AllowEKSCreatepodidentityassociation" }, { "Effect": "Allow", "Action": [ "iam:PassRole" ], "Resource": [ "arn:aws:iam::*:role/*" ], "Condition": { "StringEquals": { "iam:PassedToService": "pods.eks.amazonaws.com" } }, "Sid": "AllowIAMPassrole" } ] } ``` ------ ### Criar associações para o perfil e a conta de serviço do EMR ------ #### [ Create EMR role associations through the AWS CLI ] Quando você envia um trabalho para um namespace do Kubernetes, um administrador deve criar associações entre o perfil de execução do trabalho e a identidade da conta de serviço gerenciada do EMR. Observe que a conta de serviço gerenciado do EMR é criada automaticamente no envio do trabalho, com escopo definido para o namespace no qual o trabalho é enviado. Com a versão 2.24.0 AWS CLI (acima), execute o comando a seguir para criar associações de função com a identidade do pod. Execute o seguinte comando para criar associações de perfil com a identidade do pod: ``` aws emr-containers create-role-associations \ --cluster-name mycluster \ --namespace mynamespace \ --role-name JobExecutionRoleIRSAv2 ``` Observação: + Cada cluster pode ter um limite de 1.000 associações. Para cada mapeamento de perfil de execução de trabalho - namespace, será necessário três associados para os pods de remetente, driver e executor de trabalho. + Você só pode associar funções que estejam na mesma AWS conta do cluster. É possível delegar o acesso de outra conta ao perfil nessa conta configurada por você para o EKS Pod Identities usar. Para ver um tutorial sobre delegação de acesso`AssumeRole`, consulte o [tutorial do IAM: Delegar acesso entre AWS contas usando funções do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html). ------ #### [ Create EMR role associations through Amazon EKS ] O EMR cria uma conta de serviço com um determinado padrão de nomenclatura quando um trabalho é enviado. Para fazer associações manuais ou integrar esse fluxo de trabalho ao AWS SDK, siga estas etapas: Nome da conta de serviço do constructo: ``` emr-containers-sa-spark-%(SPARK_ROLE)s-%(AWS_ACCOUNT_ID)s-%(BASE36_ENCODED_ROLE_NAME)s ``` Os exemplos abaixo criam uma associação de função para um exemplo de função de execução de Job JobExecutionRoleIRSAv2. **Exemplos de associações de perfis:** ``` RoleName: JobExecutionRoleIRSAv2 Base36EncodingOfRoleName: 2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe ``` **Exemplo de comando CLI:** ``` # setup for the client service account (used by job runner pod) # emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-client-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe # driver service account # emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-driver-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe # executor service account # emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe aws eks create-pod-identity-association --cluster-name mycluster --role-arn arn:aws:iam::111122223333:role/JobExecutionRoleIRSAv2 --namespace mynamespace --service-account emr-containers-sa-spark-executor-111122223333-2eum5fah1jc1kwyjc19ikdhdkdegh1n26vbe ``` ------ Depois de concluir todas as etapas necessárias para a Identidade de Pods do EKS, você pode pular as etapas a seguir para a configuração do IRSA: + [Ativar funções do IAM para contas de serviço (IRSA) no cluster EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-enable-IAM.html) + [Crie uma função de execução de tarefas](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/creating-job-execution-role.html) + [Atualize a política de confiança da função de execução do trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-trust-policy.html) É possível avançar diretamente para a etapa seguinte: [Conceder aos usuários acesso ao Amazon EMR no EKS](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/setting-up-iam.html) ## Excluir associações de perfil Sempre que você excluir um cluster virtual ou um perfil de execução de trabalho e não quiser mais conceder acesso ao EMR às suas contas de serviço, você deverá excluir as associações do perfil. Isso ocorre porque o EKS permite associações com recursos inexistentes (namespace e conta de serviço). O Amazon EMR no EKS recomenda excluir as associações se o namespace for excluído ou se o perfil não estiver mais em uso, para liberar espaço para outras associações. **nota** As associações persistentes podem afetar sua capacidade de escalar se você não as excluir, pois o EKS tem limitações no número de associações que você pode criar (limite flexível: 1000 associações por cluster). Você pode listar as associações de identidades de pods em um determinado namespace para verificar se há alguma associação remanescente que precisa ser limpa: ``` aws eks list-pod-identity-associations --cluster-name mycluster --namespace mynamespace ``` Com a AWS CLI (versão 2.24.0 ou superior), execute o seguinte comando emr-containers para excluir as associações de função do EMR: ``` aws emr-containers delete-role-associations \ --cluster-name mycluster \ --namespace mynamespace \ --role-name JobExecutionRoleIRSAv2 ``` ## Migrar automaticamente o IRSA existente para a Identidade de Pods Você pode usar a ferramenta eksctl para migrar perfis do IAM existentes para contas de serviço (IRSA) para associações de identidade de pods: ``` eksctl utils migrate-to-pod-identity \ --cluster mycluster \ --remove-oidc-provider-trust-relationship \ --approve ``` A execução do comando sem o sinalizador `--approve` produzirá apenas um plano que reflete as etapas da migração, e nenhuma migração real ocorrerá. ## Solução de problemas ### Meu trabalho falhou com NoClassDefinitionFound ou com ClassNotFound exceção do provedor de credenciais, ou falhou em obter o provedor de credenciais. A Identidade de Pods do EKS usa o Provedor de credenciais de contêiner para recuperar as credenciais necessárias. Se você especificou um provedor de credenciais personalizado, verifique se ele está funcionando corretamente. Como alternativa, verifique se você está usando uma versão correta do AWS SDK compatível com o EKS Pod Identity. Para obter mais informações, consulte [Conceitos básicos do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html). ### O trabalho falhou com o erro “Falha na recuperação de credenciais devido ao limite de tamanho [x]” mostrado no eks-pod-identity-agent registro. O EMR no EKS cria contas de serviço do Kubernetes com base no nome do perfil de execução do trabalho. Se o nome do perfil for muito longo, o EKS Auth não conseguirá recuperar as credenciais porque a combinação de `cluster_name`, `pod_name` e `service_account_name` excede o limite de comprimento. Identifique qual componente está ocupando mais espaço e ajuste o tamanho de acordo. ### O trabalho falhou com o erro “Failed to Retrieve Credentials xxx” exibido no eks-pod-identity registro. Uma possível causa desse problema pode ser que o cluster EKS esteja configurado em sub-redes privadas sem ser configurado corretamente PrivateLink para o cluster. Verifique se seu cluster está em uma rede privada e configure AWS PrivateLink para resolver o problema. Para obter instruções detalhadas, consulte [Comece a usar o Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html). # Opção 2: habilitar perfis do IAM para contas de serviço (IRSA) no cluster do EKS O recurso de perfis do IAM para contas de serviço está disponível nas versões 1.14 e posteriores do Amazon EKS e para clusters do EKS atualizados para as versões 1.13 ou posteriores ou após 3 de setembro de 2019. Para usar esse recurso, é possível atualizar os clusters do EKS existentes para a versão 1.14 ou posterior. Para obter mais informações, consulte [Atualizar uma versão do Kubernetes do cluster do Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/update-cluster.html). Se o seu cluster oferecer suporte para perfis do IAM para contas de serviço, ele terá um URL do emissor [OpenID Connect](https://openid.net/connect/) associado a ele. Você pode visualizar essa URL no console do Amazon EKS ou usar o AWS CLI comando a seguir para recuperá-la. **Importante** Você deve usar a versão mais recente do AWS CLI para receber a saída adequada desse comando. ``` aws eks describe-cluster --name cluster_name --query "cluster.identity.oidc.issuer" --output text ``` A saída esperada é semelhante à apresentada a seguir. ``` https://oidc.eks..amazonaws.com/id/EXAMPLED539D4633E53DE1B716D3041E ``` Para usar perfis do IAM para contas de serviço em seu cluster, é necessário criar um provedor de identidades OIDC usando o [eksctl](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-eksctl) ou o [Console de gerenciamento da AWS](https://docs.aws.amazon.com/eks/latest/userguide/enable-iam-roles-for-service-accounts.html#create-oidc-console). ## Para criar um provedor de identidade OIDC do IAM para o cluster com o `eksctl` Verifique a versão do `eksctl` com o comando a seguir. Este procedimento pressupõe que você instalou o `eksctl` e que a versão do `eksctl` seja 0.32.0 ou posterior. ``` eksctl version ``` Para obter mais informações sobre como instalar ou atualizar o eksctl, consulte [Instalar ou atualizar o eksctl](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html#installing-eksctl). Crie o provedor de identidade OIDC para o cluster com o seguinte comando. Substitua *cluster\$1name* pelos seus próprios valores. ``` eksctl utils associate-iam-oidc-provider --cluster cluster_name --approve ``` ## Para criar um provedor de identidade IAM OIDC para seu cluster com o Console de gerenciamento da AWS Recupere a URL do emissor do OIDC na descrição do console Amazon EKS do seu cluster ou use o comando a seguir. AWS CLI Use o comando apresentado a seguir para recuperar o URL do emissor OIDC da AWS CLI. ``` aws eks describe-cluster --name --query "cluster.identity.oidc.issuer" --output text ``` Use as etapas apresentadas a seguir para recuperar o URL do emissor OIDC do console do Amazon EKS. 1. Abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. No painel de navegação, escolha **Provedores de identidade** e, em seguida, selecione **Criar provedor**. 1. Para **Tipo de provedor**, escolha **Escolher um tipo de provedor** e escolha **OpenID Connect**. 1. Em **Provider URL (URL do provedor)**, cole o URL emissor OIDC do cluster. 1. Para Público, digite sts.amazonaws.com e escolha **Próxima etapa**. 1. Verifique se as informações do provedor estão corretas e escolha **Create (Criar)** para criar seu provedor de identidade. # Criação de um perfil de execução de trabalho Para executar workloads no Amazon EMR no EKS, você precisa criar um perfil do IAM. Referimo-nos a esse perfil como *perfil de execução de trabalho* nesta documentação. Para obter mais informações sobre como criar perfis do IAM, consulte [Criação de perfis do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) no Guia do usuário do IAM. Você também deve criar uma política do IAM que especifique as permissões para o perfil de execução de trabalho e, em seguida, anexar a política do IAM ao perfil de execução de trabalho. A política a seguir para a função de execução do trabalho permite acesso a destinos de recursos, Amazon S3 e. CloudWatch Essas permissões são necessárias para monitorar trabalhos e acessar logs. Para seguir o mesmo processo usando o AWS CLI: Crie o perfil do IAM para execução do trabalho: vamos criar o perfil que o EMR usará para a execução do trabalho. Essa é o perfil que os trabalhos do EMR assumirão quando forem executados no EKS. ``` cat < ~/environment/emr-trust-policy.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "elasticmapreduce.amazonaws.com" }, "Action": "sts:AssumeRole" } ] } EoF aws iam create-role --role-name EMRContainers-JobExecutionRole --assume-role-policy-document file://~/environment/emr-trust-policy.json ``` Em seguida, precisamos anexar as políticas do IAM necessárias ao perfil para que ele possa gravar logs no S3 e no cloudwatch. ``` cat < ~/environment/EMRContainers-JobExecutionRole.json { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": "arn:aws:s3:::amzn-s3-demo-bucket" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ] } ] } EoF aws iam put-role-policy --role-name EMRContainers-JobExecutionRole --policy-name EMR-Containers-Job-Execution --policy-document file://~/environment/EMRContainers-JobExecutionRole.json ``` **nota** O acesso deve ter um escopo adequado e não ser concedido a todos os objetos do S3 no perfil de execução de trabalho. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject", "s3:ListBucket" ], "Resource": [ "arn:aws:s3:::amzn-s3-demo-bucket" ], "Sid": "AllowS3Putobject" }, { "Effect": "Allow", "Action": [ "logs:PutLogEvents", "logs:CreateLogStream", "logs:DescribeLogGroups", "logs:DescribeLogStreams" ], "Resource": [ "arn:aws:logs:*:*:*" ], "Sid": "AllowLOGSPutlogevents" } ] } ``` ------ Para obter mais informações, consulte [Usando funções de execução de trabalho](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/iam-execution-role.html), [Configurar uma execução de trabalho para usar registros do S3](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-s3) e [Configurar uma execução de trabalho para usar CloudWatch registros](https://docs.aws.amazon.com/emr/latest/EMR-on-EKS-DevelopmentGuide/emr-eks-jobs-CLI.html#emr-eks-jobs-cloudwatch). # Atualização da política de confiança do perfil de execução de trabalho Ao usar perfis do IAM para contas de serviço (IRSA) com a finalidade de executar trabalhos em um namespace do Kubernetes, um administrador deve criar uma relação de confiança entre o perfil de execução de trabalho e a identidade da conta de serviço gerenciado do EMR. A relação de confiança pode ser criada ao atualizar a política de confiança do perfil de execução de trabalho. Observe que a conta de serviço gerenciado do EMR é criada automaticamente no envio do trabalho, com escopo definido para o namespace no qual o trabalho é enviado. Execute o comando apresentado a seguir para atualizar a política de confiança. ``` aws emr-containers update-role-trust-policy \ --cluster-name cluster \ --namespace namespace \ --role-name iam_role_name_for_job_execution ``` Para obter mais informações, consulte [Uso de perfis de execução de trabalho com o Amazon EMR no EKS](iam-execution-role.md). **Importante** O operador que executa o comando acima deve ter estas permissões: `eks:DescribeCluster`, `iam:GetRole` e `iam:UpdateAssumeRolePolicy`.