Introducción
El 81% de los clústeres de Amazon EKS aún utilizan el método legacy de autenticación basado en el ConfigMap aws-auth para mapear identidades IAM a roles de Kubernetes, según el Kubernetes Security Report 2025. Este método, manual y difícil de auditar, fue deprecado por AWS en favor de una alternativa-driven por API, más segura y escalable. La persistencia en su uso no es un caso aislado: refleja un problema más amplio en la seguridad de Kubernetes, donde la complejidad del modelo cloud-native y la falsos supuestos sobre su seguridad inherente dejan brechas expuestas en el 66% de las organizaciones, que han retrasado despliegues por preocupaciones de seguridad relacionadas con el platform.
Qué ocurrió
En 2023, AWS anunció la deprecación del ConfigMap aws-auth en EKS, un método que permite mapear usuarios, grupos y roles de IAM a roles de RBAC en Kubernetes mediante una configuración estática en un objeto de Kubernetes. El cambio forma parte de un esfuerzo por simplificar y securizar la gestión de acceso en EKS, promoviendo el uso de EKS Access Entries, una API nativa que permite administrar estas mapeos de forma programática, con granularidad por clúster y sin necesidad de editar manualmente un ConfigMap.
La deprecación no es inmediata: AWS mantuvo compatibilidad con el método legacy para dar tiempo a los usuarios a migrar, pero no ha definido una fecha límite concreta para su remoción. Sin embargo, el mensaje es claro: el ConfigMap aws-auth no cumple con las mejores prácticas de seguridad para entornos cloud-native, y su uso continuo aumenta el riesgo de configuraciones inconsistentes, errores humanos y dificultad para auditar permisos.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
El uso prolongado del ConfigMap aws-auth introduce riesgos concretos en tres áreas críticas:
El impacto no se limita a la autenticación. El Kubernetes Security Report 2025 señala que el 66% de las organizaciones han retrasado o ralentizado despliegues debido a problemas de seguridad en Kubernetes, con las capas Container y Cluster como los principales puntos de fricción. Esto refleja que el problema subyacente —la subestimación de la complejidad de securizar Kubernetes— trasciende el caso específico de aws-auth.
Detalles técnicos
El método legacy: aws-auth ConfigMap
El ConfigMap aws-auth reside en el namespace kube-system y tiene un formato como el siguiente:
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
– rolearn: arn:aws:iam::123456789012:role/EKSNodeRole
username: system:node:{{EC2PrivateDNSName}}
groups:
– system:bootstrappers
– system:nodes
mapUsers: |
– userarn: arn:aws:iam::123456789012:user/alice
username: alice
groups:
– system:masters
- mapRoles: Mapea roles de IAM (generalmente los asumidos por nodos EC2) a roles de Kubernetes. El placeholder {{EC2PrivateDNSName}} se resuelve automáticamente por el kubelet al joinear el nodo.
- mapUsers: Mapea usuarios de IAM a roles de Kubernetes.
- Grupos: Los grupos system:masters, system:bootstrappers y system:nodes tienen permisos predefinidos en Kubernetes (el primero otorgando acceso admin).
Problemas técnicos:
- No atomicidad: Los cambios en IAM y en el ConfigMap no son atómicos. Si se modifica un rol en IAM pero no se actualiza el ConfigMap, el usuario/rol mantendrá los permisos antiguos en Kubernetes.
- No escalable: No existe un mecanismo nativo para replicar la configuración across múltiples clústeres.
- Difícil de auditar: No hay integración con herramientas de IAM como AWS IAM Access Analyzer o AWS CloudTrail para monitorear los permisos efectivos en el clúster.
La alternativa: EKS Access Entries
Introducida en 2023, la API de EKS Access Entries (parte del service EKS Access) permite gestionar los mapeos IAM-Kubernetes de forma declarativa y programática. Cada entrada ( access entry ) asocia un principal de IAM (usuario, rol o cuenta) con una lista de grupos de Kubernetes:
aws eks create-access-entry –cluster-name my-cluster \
–principal arn:aws:iam::123456789012:user/alice \
–kubernets-groups system:masters
Ventajas:
- Gestión centralizada: Las entradas se definen a nivel de clúster y pueden administrarse via AWS CLI, API, Terraform o CloudFormation.
- Integración con IAM: Los cambios en IAM se reflejan automáticamente en el clúster (con un delay de hasta 10 minutos).
- Auditoría: Las operaciones sobre access entries se registran en AWS CloudTrail.
- Granularidad: Permite asociar un principal a múltiples grupos de Kubernetes sin duplicar configuración.
El marco de seguridad de Kubernetes: las 4 C
El caso de aws-auth es un ejemplo de riesgo en la capa Cluster (uno de los «4 C» de seguridad en Kubernetes: Code, Container, Cluster, Cloud). Cada capa tiene sus propios vectores de ataque y requerimientos:
- Code: Vulnerabilidades en el código de la aplicación (ej: inyecciones SQL, XSS).
- Container: Imágenes vulnerables, configuraciones inseguras (ej:运行 como root), secretos hardcodeados.
- Cluster: Configuración del clúster (ej: RBAC mal configurado, network policies ausentes, exposure del API server).
- Cloud: Configuración de la infraestructura subyacente (ej: IAM roles sobreprivilegiados, Security Groups abiertos).
En entornos Kubernetes, los gaps más frecuentes están en las capas Container y Cluster, donde las prácticas tradicionales de seguridad (ej: escaneado de vulnerabilidades en hosts, firewalls perimetrales) son insuficientes.
Qué deberían hacer los administradores y equipos técnicos
1. Migrar de aws-auth ConfigMap a EKS Access Entries
Pasos concretos:
kubectl get cm aws-auth -n kube-system -o yaml
Documentar todos los mapeos de roles y usuarios.
aws eks create-access-entry –cluster-name
–principal
–kubernetes-groups
Para roles de nodos, usar el ARN del role de IAM asociado al Node Group.
– Asumir el rol/usuario y verificar el acceso al clúster:
aws eks update-kubeconfig –region
kubectl get nodes
– Usar kubectl auth can-i para testing de permisos granulares.
kubectl delete cm aws-auth -n kube-system
Nota: AWS no permite eliminar el ConfigMap si no hay access entries configuradas. Asegurarse de crear todas las entradas antes de borrarlo.
– Usar Terraform con el resource aws_eks_access_entry.
– Implementar políticas de IAM que restrinjan quién puede crear/modificar access entries (ej: permisos sobre eks:CreateAccessEntry y eks:UpdateAccessEntry).
2. Revisar la seguridad del clúster
Aprovechar la migración para auditar otros aspectos críticos:
- RBAC: Eliminar roles y bindings no utilizados (kubectl get clusterrolebinding,rolebinding -A). Evitar el uso del grupo system:masters.
- Network Policies: Implementar políticas para restringir el tráfico entre pods. Ejemplo para denegar todo el tráfico por defecto:
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny
namespace: default
spec:
podSelector: {}
policyTypes:
– Ingress
– Egress
- Secrets: No almacenar secrets en Kubernetes sin encriptación. Usar:
– Secrets con encriptación en reposo (requiere configurar un KMS Key en EKS).
– External secrets managers como AWS Secrets Manager o HashiCorp Vault, integrados via CSI Driver o external provider.
3. Implementar seguridad a nivel de fleet
- Políticas centralizadas: Usar herramientas como Kyverno, Open Policy Agent (OPA) o AWS GuardDuty for EKS para enforcear políticas de seguridad across todos los clústeres (ej: prohibir pods como root, requerir PodSecurity Standards).
- Image supply chain: Escanear imágenes para vulnerabilidades (con herramientas como Trivy o Amazon ECR scanning) y enforcear que solo se deployen imágenes desde registries de confianza.
- Monitoring: Habilitar logs de auditoría de Kubernetes (API server logs) y centralizarlos en un SIEM. Monitorear eventos sospechosos como create pod con hostPath o create secret.
Conclusión
La deprecación del ConfigMap aws-auth en EKS es un recordatorio de que la seguridad en Kubernetes no es un estado, sino un proceso continuo. El método legacy, aunque funcional, no escala y introduce riesgos operativos y de seguridad que se agravan en fleets de clústeres. La migración a EKS Access Entries no solo resuelve estos problemas, sino que habilita una gestión de acceso más escalable y auditable.
Pero este cambio no debe ser aislado. Para cerrar la brecha entre las asumptions y la realidad en la seguridad de Kubernetes, los equipos deben adoptar un enfoque holístico que abarque las 4 C, implementar controles por defecto y automatizar la cumplimentación de políticas. Solo así podrán aprovechar la agilidad de Kubernetes sin comprometer la seguridad.
Fuentes
- https://thenewstack.io/kubernetes-fleet-security-management/
- https://www.jeffgeerling.com/blog