Como resolver o erro "Your current user or role does not have access to Kubernetes objects" no AWS EKS

Ao usar o Amazon Elastic Kubernetes Service (EKS), você já se deparou com a mensagem de erro "Your current user or role does not have access to Kubernetes objects on this EKS cluster"? Esse erro pode confundir bastante, ainda mais quando você é super admin global e ouve que não tem permissão. Neste artigo, vamos detalhar o que esse erro significa e mostrar um passo a passo de como resolvê-lo.

access

Exemplo retirado da interface do console da AWS

AWS

Exemplo do kubectl CLI em um cluster EKS

Entendendo o problema

Para visualizar recursos do Kubernetes no AWS Management Console, o usuário ou role do AWS IAM precisa estar mapeado no aws-auth``ConfigMap do cluster EKS. Esse mapeamento é essencial porque, quando alguém cria um cluster EKS, seu usuário ou role do IAM recebe automaticamente a permissão system:masters na configuração de RBAC (Role-Based Access Control) do cluster. Com isso, é possível visualizar recursos do Kubernetes pelo console do EKS e também editar o aws-auth``ConfigMap dentro do Kubernetes, dando a outros usuários ou roles da AWS a possibilidade de interagir com o cluster.

Por padrão, o usuário/role do AWS IAM que cria o cluster tem acesso exclusivo tanto ao AWS Console quanto ao kubectl. Ao contrário do que se espera, o motivo de não conseguir visualizar itens no AWS Console é a falta de uma configuração adequada de mapeamento entre as permissões de RBAC do Kubernetes e o IAM no aws-auth``ConfigMap.

Como resolver o problema

Identificando o criador do cluster

Você precisa descobrir quem criou o cluster EKS. Uma forma é consultar os logs do AWS CloudTrail. O AWS CloudTrail registra todas as chamadas de API da AWS, incluindo as feitas pelo AWS Management Console, SDKs e CLI. Portanto, se o CloudTrail estiver habilitado na sua conta, você consegue descobrir a identidade do usuário que criou o cluster EKS.

Veja o passo a passo:

Faça login no AWS Management Console.
Acesse o CloudTrail pelo AWS Management Console — basta digitar 'CloudTrail' na barra de busca de serviços e selecioná-lo no menu suspenso.
No dashboard do CloudTrail, selecione 'Event history' na barra lateral.
Na página de Event history, você verá filtros no topo. Defina o filtro 'Event name' como 'CreateCluster', que é a chamada de API que cria um novo cluster EKS.
Se você souber o nome do cluster EKS, também pode filtrar por 'Resource name' e informar o nome do cluster.
Depois de aplicar os filtros, você verá uma lista de eventos 'CreateCluster'. Clique no evento para ver os detalhes. O campo 'User name' nos detalhes do evento mostra a identidade do usuário que criou o cluster EKS.

Lembrando que essa abordagem só funciona se o CloudTrail estava ativado na conta AWS no momento da criação do cluster EKS — algo que normalmente vem habilitado por padrão. Se o CloudTrail não estava ativo nesse momento, não dá para determinar quem criou o cluster EKS. Nesse caso, o ideal é pedir ajuda a um administrador AWS, DevOps, SRE ou especialista da sua organização que possa ajudar a localizar o criador do cluster.

Identificando o ARN da identidade IAM

Identifique o usuário ou role do IAM que você está usando para acessar o console. Para obter o ARN da identidade IAM, execute o seguinte comando da AWS CLI:

aws sts get-caller-identity --query Arn

Adicionando um usuário ou role do IAM ao aws-auth ConfigMap

Para conceder acesso ao seu cluster EKS, o criador do cluster pode adicionar um usuário ou role do IAM ao aws-auth``ConfigMap. Isso permite que o usuário ou role interaja com o cluster sem complicações. Veja exemplos de como fazer isso usando kubectl ou eksctl:

kubectl

Recupere o ConfigMap atual:

kubectl get -n kube-system configmap/aws-auth -o yaml

Esse comando exibirá o aws-auth``ConfigMap atual, que deve ser parecido com isto:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes

Para adicionar um novo usuário ou role do IAM, modifique este YAML e inclua o novo usuário ou role em mapRoles ou mapUsers. Veja um exemplo de como pode ficar:

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::11122223333:role/EKS-Worker-NodeInstanceRole-1I00GBC9U4U7B
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:bootstrappers
        - system:nodes
    - rolearn: arn:aws:iam::11122223333:role/YourNewRole
      username: system:node:{{EC2PrivateDNSName}}
      groups:
        - system:masters
  mapUsers: |
    - userarn: arn:aws:iam::11122223333:user/YourNewUser
      username: YourNewUser
      groups:
        - system:masters

Neste exemplo, substitua arn:aws:iam::11122223333:role/YourNewRole pelo ARN da sua nova role do IAM, e arn:aws:iam::11122223333:user/YourNewUser pelo ARN do seu novo usuário do IAM. Substitua também YourNewUser pelo nome do novo usuário do IAM.

3. Feitas as modificações, aplique o novo ConfigMap com o seguinte comando:

kubectl apply -f aws-auth-configmap.yaml

No comando acima, substitua aws-auth-configmap.yaml pelo nome do arquivo do seu ConfigMap modificado.

eksctl

Para adicionar um usuário do IAM:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:user/YourNewUser --group system:masters

Para adicionar uma role do IAM:

eksctl create iamidentitymapping --region region-code --cluster cluster-name --arn arn:aws:iam::11122223333:role/YourNewRole --group system:masters

Nos exemplos acima:

Substitua region-code pelo código da região AWS (por exemplo, us-west-2).
Substitua cluster-name pelo nome do cluster EKS.
Substitua arn:aws:iam::11122223333:role/YourNewRole pelo ARN da nova role do IAM, e arn:aws:iam::11122223333:user/YourNewUser pelo ARN do novo usuário do IAM.
Substitua system:masters pelo grupo apropriado do Kubernetes. Veja a seção Grupos do Kubernetes abaixo para mais detalhes.

Grupos do Kubernetes

No Kubernetes, um grupo é um conjunto de usuários com as mesmas permissões. Veja alguns dos grupos padrão:

system:authenticated: inclui todos os usuários autenticados.
system:unauthenticated: inclui todos os usuários não autenticados.
system:masters: tem acesso total ao cluster e pode realizar qualquer ação dentro dele. Geralmente está associado às roles do criador do cluster.
system:serviceaccounts:<namespace>: inclui todas as service accounts no namespace <namespace>.

O grupo system:masters dá acesso total ao cluster, incluindo a capacidade de criar, ler, atualizar e excluir qualquer recurso. Por isso, tenha cuidado ao adicionar usuários ou roles a esse grupo. Adicione apenas usuários ou roles confiáveis e sempre aplique o princípio do menor privilégio. Esse conceito consiste em conceder a um usuário ou role apenas os níveis de acesso ou permissões necessários para realizar suas tarefas, reduzindo o risco de atividades maliciosas ou violações ao diminuir a superfície de ataque.

Problemas de acesso recorrentes

Se o problema persistir mesmo após atualizar o aws-auth ConfigMap, isso pode ser por causa da política do IAM que não foi atualizada ou do RBAC do Kubernetes que não está reconhecendo as alterações. Como já comentamos, as permissões do IAM são separadas das permissões do Kubernetes, e ambas precisam estar configuradas corretamente para que o usuário consiga interagir com a API do Kubernetes.

Veja uma lista de passos de troubleshooting:

Confirme se o aws-auth ConfigMap no namespace kube-system foi atualizado corretamente:

kubectl -n kube-system describe configmap aws-auth

A saída deve mostrar o usuário ou role do IAM em mapRoles ou mapUsers. Se não estiver lá, é porque o ConfigMap não foi atualizado corretamente ou pode estar mal-formado. Um ConfigMap mal-formado no Kubernetes funciona como se tivesse sido excluído, podendo bloquear o acesso de todo mundo, exceto do criador do cluster. Por isso, vale ter cautela e validar o YAML com ferramentas como o YAML Lint para conferir sua configuração.

2. Confira o usuário ou role do IAM para garantir que é exatamente aquele que foi adicionado ao aws-auth``ConfigMap. Erro de digitação no ARN do usuário ou role do IAM é bem comum.

3. Garanta que o usuário ou role do IAM tenha as permissões AWS necessárias. Para isso, verifique as políticas do IAM associadas ao usuário ou role. Se você precisa gerenciar o cluster EKS e os nodes, as políticas AmazonEKSClusterPolicy e AmazonEKSWorkerNodePolicy concedem as permissões necessárias. Consulte o guia AWS managed policies for Amazon Elastic Kubernetes Service para mais detalhes.

Você também pode criar uma política de IAM personalizada que inclua permissões somente leitura para as ações eks:Describe* e eks:List*, permitindo ao usuário ou role visualizar informações sobre recursos do EKS.

4. Confirme se o usuário e os grupos do Kubernetes mapeados para a entidade IAM têm as permissões necessárias no Kubernetes. Para isso, consulte o guia Kubernetes RBAC roles and bindings.

Lembre-se de sempre seguir o princípio do menor privilégio ao conceder permissões, tanto na AWS quanto no Kubernetes. Conceda apenas as permissões necessárias para que o usuário ou role realize suas tarefas.

Vale ressaltar também que, se o aws-auth ConfigMap for removido, contiver erros de sintaxe ou estiver formatado de forma incorreta, todos os usuários — exceto o criador do cluster — perderão o acesso. O criador do cluster é a única pessoa capaz de corrigir essa situação.

Lidar com o cenário complexo dos erros do AWS EKS pode, sem dúvida, ser desafiador, mas com a combinação certa de conhecimento, ferramentas e visão prática dá para superar esses obstáculos. Entender como as identidades do IAM e do Kubernetes se relacionam é uma peça-chave do quebra-cabeça, assim como dominar as nuances de manipular o aws-auth ConfigMap. Espero que este guia seja um recurso útil — seja você um veterano experiente em EKS ou alguém que está começando agora na plataforma.