Amazon EKS simplifica el acceso a clústeres con acceso en un clic desde CloudShell

Introducción

Hasta hoy, los equipos de DevOps y SRE debían mantener configuraciones locales de kubectl y kubeconfig actualizadas para interactuar con clústeres de Amazon EKS. Esto generaba fricción en entornos compartidos, ralentizaba la resolución de incidentes y aumentaba el riesgo de errores por configuraciones desactualizadas. Según el reporte de ENISA del primer trimestre de 2026, el 42% de las brechas de seguridad relacionadas con Kubernetes en entornos cloud se originaban en herramientas de acceso mal configuradas o desactualizadas. La nueva función de acceso en un clic desde AWS CloudShell elimina este cuello de botella al preconfigurar el entorno en la nube, sin depender de instalaciones locales.

El cambio responde a una demanda concreta: los equipos necesitan acceso inmediato a clústeres, especialmente en escenarios de troubleshooting o CI/CD, donde cada minuto cuenta. AWS lo implementó integrando CloudShell con EKS, permitiendo que un operador abra una consola en la nube con kubectl listo para usar, sin configuraciones manuales. Esta solución es relevante para equipos que operan clústeres en regiones con conectividad restringida o que priorizan auditorías de acceso centralizadas.

Qué ocurrió

El 15 de abril de 2026, AWS anunció en su blog oficial la disponibilidad de acceso en un clic a clústeres de EKS desde CloudShell. La funcionalidad se lanzó en todas las regiones donde EKS está disponible y no tiene costo adicional. Para usarla, basta con:

1. Navegar al clúster EKS en la consola de AWS.
2. Seleccionar la opción Conectar.
3. Elegir Abrir en CloudShell, que lanza una terminal preconfigurada con:

– aws-cli versión 2.17.10 (para operaciones cruzadas con otros servicios AWS).

– Variables de entorno KUBECONFIG apuntando al clúster seleccionado.

– Herramientas estándar de CloudShell como jq, curl y bash.

La configuración es transitoria: cada sesión de CloudShell dura 24 horas y se autodestruye al cerrarla, lo que reduce la exposición a credenciales. Además, el endpoint del clúster puede ser público o privado; AWS gestiona la conectividad mediante IAM Roles for Service Accounts (IRSA) o el rol de IAM del usuario.

Impacto para DevOps / Infraestructura / Cloud / Seguridad

Para equipos de DevOps y SRE

La principal ventaja es la reducción de tiempo de acceso inicial. Según pruebas internas de AWS, el tiempo para ejecutar el primer kubectl get pods pasó de 5-7 minutos (configuración local) a menos de 30 segundos con este método. Esto es crítico en flujos de CI/CD donde los agentes de pipeline necesitan interactuar con el clúster sin configuraciones manuales. Además, al eliminar dependencias de herramientas locales, se reducen conflictos entre versiones de kubectl o kubeconfig en máquinas compartidas.

Para equipos multi-región, la consistencia es clave. La funcionalidad garantiza que todos los operadores usen la misma versión de kubectl (la soportada por EKS), evitando problemas de compatibilidad con APIs de Kubernetes. En entornos híbridos (EKS + clústeres on-premise), este enfoque simplifica la gestión de múltiples kubeconfig, centralizando el acceso en la consola AWS.

Para Seguridad

Desde el punto de vista de seguridad, el cambio mitiga riesgos asociados a:

• Almacenamiento de credenciales: Las credenciales de kubeconfig ya no persisten en dispositivos locales.
• Rotación de claves: AWS gestiona la autenticación mediante IAM, integrándose con políticas de IAM Roles for Service Accounts (IRSA) o roles de usuario. El endpoint privado del clúster sigue requiriendo autenticación dual (IAM + Kubernetes RBAC).
• Auditoría: Cada sesión en CloudShell queda registrada en AWS CloudTrail, con logs que incluyen el usuario, IP, clúster accedido y comandos ejecutados (si se activa la opción de logging detallado).

Sin embargo, los equipos deben asegurarse de que las políticas de IAM sean granulares. Un error común es asignar el rol AmazonEKSClusterPolicy a usuarios sin restricciones, lo que podría permitir acceso no autorizado a clústeres. La recomendación de AWS es usar políticas personalizadas con condiciones como "aws:RequestedRegion": "us-east-1" para limitar el acceso a regiones específicas.

Para Infraestructura y Cloud

La implementación no requiere actualizaciones en los clústeres existentes. AWS maneja la configuración del endpoint de Kubernetes (público o privado) y la autenticación mediante el rol de IAM del usuario o IRSA. Para clusters con endpoints privados, es necesario que el VPC de CloudShell tenga conectividad al endpoint (mediante VPC Endpoints, peering, o VPN).

El impacto en costos es mínimo: CloudShell ya está incluido en la capa gratuita de AWS, y el acceso a EKS no tiene cargo adicional. Sin embargo, para clústeres con endpoints privados, se deben considerar costos de transferencia de datos si el tráfico sale de la región (ejemplo: $0.02 por GB en transferencia entre regiones en abril 2026).

Detalles técnicos

Requisitos y compatibilidad

• Regiones soportadas: Todas donde EKS esté disponible (ver lista oficial).
• Versiones de Kubernetes: EKS con Kubernetes 1.23 o superior. Clústeres con versiones menores requieren actualización previa.
• Herramientas preinstaladas en CloudShell:

– aws-cli 2.17.10 (para operaciones como aws eks update-kubeconfig si se necesita sincronizar manualmente).

– yq para manipulación de YAML (útil para editar manifests).

• Permisos requeridos: El usuario debe tener al menos los permisos:

  {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": [
          "eks:DescribeCluster",
          "eks:ListClusters"
        ],
        "Resource": "*"
      }
    ]
  }
  

Flujo de autenticación

1. El usuario selecciona un clúster en la consola EKS.
2. AWS CloudShell lanza una sesión con:

– Un contexto de Kubernetes configurado como arn:aws:eks:<region>:<account-id>:cluster/<cluster-name>.

1. El usuario ejecuta comandos como:

   kubectl get pods -A
   kubectl top nodes
   

Sin necesidad de ejecutar aws eks update-kubeconfig manualmente.

Configuración para endpoints privados

Si el clúster usa un endpoint privado, el VPC de CloudShell debe tener:

• Un VPC Endpoint para el servicio com.amazonaws.<region>.eks (costo: ~$0.01 por hora en us-east-1).
• O bien, una conexión VPN o Direct Connect al VPC del clúster.
• Políticas de seguridad de grupo que permitan tráfico desde el VPC de CloudShell al endpoint privado (puerto 443).

Limitaciones conocidas

• Sesiones temporales: Duración máxima de 24 horas (configurable por AWS, no por el usuario).
• Sin persistencia: El kubeconfig se elimina al cerrar la sesión. Para clústeres críticos, se recomienda usar herramientas como kubefed o ArgoCD para gestión declarativa.
• No soporta clústeres no-EKS: Solo funciona con clústeres de Amazon EKS. Para EKS Anywhere o clústeres on-premise, sigue siendo necesario configurar kubeconfig localmente.

Qué deberían hacer los administradores y equipos técnicos

1. Validar compatibilidad del clúster

Ejecutar en la consola de AWS:

aws eks describe-cluster --name <nombre-clúster> --query "cluster.version"

Si la versión es menor a 1.23, actualizar el clúster antes de usar el acceso en un clic. Para actualizar, seguir la guía oficial de AWS.

2. Configurar permisos de IAM

Asegurarse de que los roles/usuarios tengan permisos mínimos. Ejemplo de política para un rol de DevOps:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "eks:DescribeCluster",
      "Resource": "arn:aws:eks:<region>:<account-id>:cluster/dev-cluster-*"
    },
    {
      "Effect": "Allow",
      "Action": "eks:ListClusters",
      "Resource": "*"
    }
  ]
}

Aplicar con:

aws iam put-role-policy --role-name DevOpsEKSAccess --policy-name EKSClusterAccess --policy-document file://policy.json

3. Habilitar logging detallado (opcional pero recomendado)

Para auditar comandos ejecutados en CloudShell:

1. Crear un bucket S3 para logs (ejemplo: eks-cloudshell-logs).
2. Configurar CloudTrail para registrar eventos de CloudShell:

   aws cloudtrail create-trail --name EKSCloudShellTrail --s3-bucket-name eks-cloudshell-logs
   aws cloudtrail put-event-selectors --trail-name EKSCloudShellTrail --event-selectors '[{
     "ReadWriteType": "All",
     "IncludeManagementEvents": true,
     "DataResources": [{
       "Type": "AWS::CloudTrail::DataResource",
       "Values": ["arn:aws:cloudshell:<region>:<account-id>:session/*"]
     }]
   }]'
   

4. Probar el acceso en un clúster de prueba

1. Ir a AWS CloudShell.
2. Seleccionar un clúster EKS de prueba.
3. Ejecutar:

   kubectl get nodes
   kubectl get pods -A
   

Verificar que no se requieran configuraciones adicionales.

5. Integrar con flujos de CI/CD (opcional)

Para pipelines que necesiten interactuar con el clúster, usar el rol de IAM del pipeline y configurar el acceso vía AWS CloudShell. Ejemplo en GitHub Actions:

- name: Acceder a EKS
  run: |
    aws eks update-kubeconfig --name prod-cluster --region us-east-1
    kubectl apply -f k8s/manifest.yaml
  env:
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

6. Monitorear y auditar

Usar CloudWatch para crear dashboards con métricas de:

• Número de sesiones de CloudShell por clúster.
• Comandos kubectl más ejecutados (filtrar logs de CloudTrail).
• Errores de autenticación (ejemplo: Unauthorized en endpoints privados).

Conclusión

La función de acceso en un clic de Amazon EKS a través de CloudShell reduce la fricción operativa en flujos de DevOps, especialmente en entornos multi-usuario o con restricciones de conectividad. Al centralizar el acceso en la consola AWS y eliminar dependencias de herramientas locales, los equipos ganan en velocidad y consistencia, sin comprometer la seguridad si se configuran permisos granulares de IAM.

Para equipos que ya operan con Kubernetes en AWS, la adopción es inmediata: basta con actualizar los clústeres a Kubernetes 1.23+ y ajustar políticas de IAM. En entornos híbridos o de alta seguridad, este método simplifica la gestión de múltiples contextos de Kubernetes, siempre que se implementen controles de auditoría y conectividad adecuados.

Fuentes

• AWS What’s New: Amazon EKS now supports one-click cluster access through CloudShell
• ENISA: Kubernetes Security Challenges (Q1 2026 Report)
• LWN.net: Kubernetes 1.31 Released