Cómo resolver el error "Your current user or role does not have access to Kubernetes objects" en AWS EKS

¿Te has topado con el mensaje "Your current user or role does not have access to Kubernetes objects on this EKS cluster" al usar Amazon Elastic Kubernetes Service (EKS)? Es un error que descoloca, sobre todo cuando eres super admin global y te dicen que no tienes permisos. En este artículo te explicamos qué significa y cómo resolverlo paso a paso.

"access

Ejemplo tomado de la interfaz de la consola de AWS

"AWS

Ejemplo desde la CLI de kubectl contra un cluster de EKS

En qué consiste el problema

Para ver los recursos de Kubernetes en la AWS Management Console, el usuario o rol de AWS IAM debe estar mapeado al aws-auth``ConfigMap del cluster de EKS. Este mapeo es esencial porque, cuando alguien crea un cluster de EKS, su usuario o rol de IAM recibe automáticamente permisos system:masters en la configuración de RBAC (Role-Based Access Control) del cluster. Esto le permite consultar los recursos de Kubernetes desde la consola de EKS y editar el aws-auth``ConfigMap dentro de Kubernetes, dándole a otros usuarios o roles de AWS la posibilidad de interactuar con el cluster.

Por defecto, el usuario o rol de AWS IAM que crea el cluster es el único con acceso tanto a la AWS Console como a la herramienta kubectl. Aunque parezca contraintuitivo, la razón por la que no se ven los elementos en la AWS Console es la falta de un mapeo adecuado entre los permisos de RBAC de Kubernetes y los de IAM en el aws-auth``ConfigMap.

Cómo resolver el problema

Identificar al creador del cluster

Lo primero es identificar quién creó el cluster de EKS. Una forma de hacerlo es revisar los logs de AWS CloudTrail. AWS CloudTrail registra todas las llamadas a la API de AWS, incluidas las que se hacen desde la AWS Management Console, los SDKs y la CLI. Por eso, si tienes CloudTrail habilitado en tu cuenta, deberías poder encontrar la identidad del usuario que creó el cluster de EKS.

Aquí tienes una guía paso a paso:

Inicia sesión en la AWS Management Console.
Ve a CloudTrail desde la AWS Management Console; lo encuentras escribiendo "CloudTrail" en la barra de búsqueda de servicios y seleccionándolo del menú desplegable.
En el dashboard de CloudTrail, selecciona "Event history" en la barra lateral.
En la página de Event history verás filtros en la parte superior. Configura el filtro "Event name" en "CreateCluster", que es la llamada a la API que crea un nuevo cluster de EKS.
Si conoces el nombre del cluster de EKS, también puedes filtrar por "Resource name" e ingresar el nombre del cluster.
Después de aplicar los filtros, verás una lista de eventos "CreateCluster". Haz clic en el evento para ver los detalles. El campo "User name" en los detalles del evento corresponde a la identidad del usuario que creó el cluster de EKS.

Ten en cuenta que este método solo funciona si CloudTrail estaba activado en la cuenta de AWS al momento de crear el cluster de EKS, lo cual suele venir habilitado por defecto. Si no lo estaba, no será posible determinar quién creó el cluster. En ese caso, lo recomendable es pedir ayuda a un administrador de AWS, DevOps, SRE o un experto del tema dentro de tu organización que pueda orientarte para dar con el creador del cluster.

Identificar el ARN de la identidad de IAM

Identifica el usuario o rol de IAM que estás usando para acceder a la consola. Puedes obtener el ARN de la identidad de IAM ejecutando el siguiente comando de la AWS CLI:

aws sts get-caller-identity --query Arn

Agregar un usuario o rol de IAM al aws-auth ConfigMap

Para otorgar acceso a tu cluster de EKS, el creador del cluster puede agregar un usuario o rol de IAM al aws-auth``ConfigMap. Así, el usuario o rol podrá interactuar con el cluster sin contratiempos. A continuación tienes ejemplos de cómo hacerlo con kubectl o con eksctl:

kubectl

Obtén el ConfigMap actual:

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

Este comando mostrará el aws-auth``ConfigMap actual. Debería verse algo así:

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 agregar un nuevo usuario o rol de IAM, modifica este YAML para incluirlo bajo mapRoles o mapUsers. Aquí un ejemplo de cómo se vería:

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

En este ejemplo, reemplaza arn:aws:iam::11122223333:role/YourNewRole con el ARN de tu nuevo rol de IAM, y arn:aws:iam::11122223333:user/YourNewUser con el ARN de tu nuevo usuario de IAM. También reemplaza YourNewUser con el nombre del nuevo usuario de IAM.

3. Una vez hechas las modificaciones, aplica el nuevo ConfigMap con el siguiente comando:

kubectl apply -f aws-auth-configmap.yaml

En el comando anterior, reemplaza aws-auth-configmap.yaml con el nombre del archivo de tu ConfigMap modificado.

eksctl

Para agregar un usuario de IAM:

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

Para agregar un rol de IAM:

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

En los ejemplos anteriores:

Reemplaza region-code con el código de región de AWS (por ejemplo, us-west-2).
Reemplaza cluster-name con el nombre del cluster de EKS.
Reemplaza arn:aws:iam::11122223333:role/YourNewRole con el ARN del nuevo rol de IAM, y arn:aws:iam::11122223333:user/YourNewUser con el ARN del nuevo usuario de IAM.
Reemplaza system:masters con el grupo de Kubernetes que corresponda. Consulta la sección Grupos de Kubernetes más abajo para más detalles.

Grupos de Kubernetes

En Kubernetes, un grupo es un conjunto de usuarios que comparten los mismos permisos. Estos son algunos de los grupos por defecto:

system:authenticated: incluye a todos los usuarios autenticados.
system:unauthenticated: incluye a todos los usuarios no autenticados.
system:masters: este grupo tiene acceso completo al cluster y puede ejecutar cualquier acción dentro de él. Suele estar asociado a los roles del creador del cluster.
system:serviceaccounts:<namespace>: incluye todas las service accounts del namespace <namespace>.

El grupo system:masters da acceso completo al cluster, lo que incluye crear, leer, actualizar y eliminar cualquier recurso. Por eso conviene ser cuidadoso al agregar usuarios o roles a este grupo. Solo deberían añadirse usuarios o roles de confianza, aplicando siempre el principio de mínimo privilegio: otorgar únicamente los niveles de acceso o permisos necesarios para cumplir con las tareas. Este principio sirve para reducir el riesgo de actividad maliciosa o brechas, disminuyendo la superficie de ataque.

Problemas de acceso persistentes

Si después de actualizar el aws-auth ConfigMap sigues teniendo problemas, puede deberse a que la política de IAM no se actualizó o a que el RBAC de Kubernetes no reconoce los cambios. Como ya se mencionó, los permisos de IAM son independientes de los de Kubernetes, y ambos deben estar bien configurados para que el usuario pueda interactuar con la API de Kubernetes.

Aquí tienes una lista de pasos de troubleshooting:

Verifica que el aws-auth ConfigMap del namespace kube-system se haya actualizado correctamente:

kubectl -n kube-system describe configmap aws-auth

La salida debería mostrar el usuario o rol de IAM bajo mapRoles o mapUsers. Si no aparece, significa que el ConfigMap no se actualizó correctamente o que está mal formado. Si tu ConfigMap en Kubernetes está mal formado, es como si lo hubieran eliminado, y puede dejar fuera a todos menos al creador del cluster. Por eso es importante actuar con cautela y aplicar linting de YAML con herramientas como YAML Lint para validar tu configuración.

2. Verifica que el usuario o rol de IAM sea efectivamente el que se agregó al aws-auth``ConfigMap. Escribir mal el ARN del usuario o rol de IAM es un error frecuente.

3. Asegúrate de que el usuario o rol de IAM tenga los permisos necesarios en AWS. Esto se verifica revisando las políticas de IAM asociadas al usuario o rol. Si necesitas administrar el cluster de EKS y los nodos, las políticas AmazonEKSClusterPolicy y AmazonEKSWorkerNodePolicy otorgarán los permisos necesarios. Consulta la guía AWS managed policies for Amazon Elastic Kubernetes Service para más detalles.

También puedes crear una política de IAM personalizada que incluya permisos de solo lectura para las acciones eks:Describe* y eks:List*, lo que le permite al usuario o rol ver información sobre los recursos de EKS.

4. Asegúrate de que los usuarios y grupos de Kubernetes mapeados a la entidad de IAM tengan los permisos necesarios en Kubernetes. Esto se hace consultando la guía de roles y bindings de RBAC en Kubernetes.

Recuerda aplicar siempre el principio de mínimo privilegio al otorgar permisos, tanto en AWS como en Kubernetes. Otorga únicamente los permisos necesarios para que el usuario o rol pueda cumplir con sus tareas.

También vale la pena destacar que si el aws-auth ConfigMap se elimina, contiene errores de sintaxis o tiene un formato incorrecto, todos los usuarios menos el creador del cluster perderán el acceso. El creador del cluster es la única persona capaz de corregir esta situación.

Moverse por el complejo panorama de los errores de AWS EKS puede ser todo un reto, pero con la combinación adecuada de conocimiento, herramientas y criterio práctico, estos obstáculos se superan. Entender la intrincada relación entre las identidades de IAM y de Kubernetes es una pieza clave del rompecabezas, igual que dominar los matices del manejo del aws-auth ConfigMap. Espero que esta guía te resulte útil, ya seas un veterano de EKS o estés dando tus primeros pasos en la plataforma.