Kubernetes: sube el robo de tokens y el pivoteo hacia cloud
Un nuevo análisis de Unit 42 advierte que las intrusiones en entornos Kubernetes están evolucionando desde fallas de aplicación hacia abuso de identidades internas. El patrón más repetido combina ejecución remota en pods, robo de service account tokens y escalada lateral hacia APIs de nube y sistemas críticos.
Introducción
Kubernetes sigue siendo el estándar de facto para operar cargas distribuidas, pero también se consolidó como un punto de alto interés para atacantes con objetivos de impacto económico y acceso persistente. En las últimas semanas, distintos equipos de seguridad vienen documentando campañas que no dependen de técnicas exóticas: aprovechan errores de configuración, exceso de privilegios y exposición innecesaria de superficies de ataque ya conocidas por operaciones.
El informe más reciente de Unit 42 aporta un dato relevante para equipos de plataforma: la actividad asociada a robo de identidades en Kubernetes creció de forma fuerte durante el último año y, según su telemetría, una parte significativa de ambientes cloud mostró señales de intentos de extracción de credenciales de cuentas de servicio. El punto clave no es solo el vector inicial, sino la velocidad con la que un incidente en un pod puede transformarse en compromiso de servicios cloud aguas arriba.
Qué ocurrió
Unit 42 publicó una investigación centrada en amenazas actuales sobre Kubernetes donde describe una tendencia operacional clara: los actores combinan vulnerabilidades explotables en aplicaciones expuestas con abuso de identidades internas del clúster. En su resumen ejecutivo reportan un aumento interanual del 282% en operaciones vinculadas a Kubernetes y detallan casos donde, tras obtener ejecución dentro de contenedores, los atacantes extraen tokens de cuentas de servicio, prueban permisos contra la API y se mueven lateralmente hacia recursos de mayor valor.
El informe también remarca que una fracción relevante de entornos observados presentó actividad compatible con robo de service account tokens durante 2025. Ese comportamiento encaja con incidentes recientes en los que una intrusión inicial en workloads terminó impactando componentes de backend y credenciales cloud con alcance más amplio que el previsto por los equipos dueños del namespace afectado.
Impacto para DevOps / Infraestructura / Cloud / Seguridad
Para DevOps, SRE y equipos de plataforma, el impacto no se limita a “seguridad de contenedores”. El riesgo operativo real aparece cuando el diseño de permisos convierte un compromiso local en una ruptura de límites entre aplicaciones, namespaces o cuentas cloud.
En términos prácticos, tres problemas se repiten:
1) cuentas de servicio con permisos sobredimensionados para simplificar despliegues;
2) automount de tokens habilitado en workloads que no necesitan acceso a la API;
3) falta de separación efectiva entre cargas públicas y pods con privilegios altos.
Cuando estos factores coexisten, el tiempo entre intrusión inicial y escalada suele reducirse drásticamente. Esto afecta disponibilidad (por sabotaje o cifrado), integridad (manipulación de pipelines o secretos) y cumplimiento (exposición de datos o credenciales con impacto regulatorio).
Detalles técnicos
La mecánica técnica descrita en las fuentes es consistente con buenas prácticas conocidas pero no siempre aplicadas:
– **Token exposure en runtime**: si un pod monta automáticamente credenciales de su ServiceAccount, un atacante con ejecución en el contenedor puede intentar extraer ese JWT y reutilizarlo contra el API server.
– **Enumeración de privilegios**: con permisos de lectura/listado sobre secretos, workloads o RBAC bindings, el actor descubre rutas de escalada sin necesidad de explotar el control plane.
– **Escalada por creación de workloads**: la propia documentación de Kubernetes recuerda que permitir creación de pods puede implicar acceso indirecto a secretos, volúmenes y service accounts del namespace.
– **Pivot cloud**: una vez dentro, el acceso a secretos de aplicaciones o credenciales federadas puede abrir puertas fuera del clúster (APIs cloud, stores de secretos, sistemas financieros o de identidad).
Kubernetes, por diseño, ofrece mecanismos para mitigar esto (tokens acotados, RBAC granular, segmentación por namespace, políticas de admisión), pero la efectividad depende de disciplina operativa continua y revisión periódica de permisos efectivos, no solo de políticas declarativas en Git.
Qué deberían hacer los administradores o equipos técnicos
1. **Reducir privilegios de ServiceAccounts de forma agresiva**: revisar roles y bindings por namespace, eliminar comodines y evitar ClusterRoleBindings cuando no sean indispensables.
2. **Deshabilitar automount de tokens por defecto** (`automountServiceAccountToken: false`) y habilitarlo únicamente en pods que realmente lo requieren.
3. **Separar cargas por nivel de confianza**: no co-ubicar servicios públicos con componentes privilegiados; usar afinidad/anti-afinidad, taints y límites claros entre namespaces.
4. **Auditar permisos de creación de pods y secretos**: quien puede crear workloads, en la práctica, puede ampliar superficie de acceso.
5. **Instrumentar detección en runtime**: alertar ante accesos atípicos al API server, lecturas masivas de secretos, creación inesperada de pods y uso anómalo de tokens.
6. **Practicar respuesta a incidente orientada a identidad**: revocación de tokens, rotación de secretos, validación de cuentas cloud vinculadas y reconstrucción de workloads comprometidos.
La recomendación estratégica es tratar identidades de Kubernetes como activos críticos equivalentes a credenciales cloud de alto valor.
Conclusión
El mensaje de fondo es simple: en 2026, la frontera de seguridad en Kubernetes ya no pasa solo por evitar escapes de contenedor, sino por controlar cómo circulan identidades y permisos dentro del clúster. El aumento de campañas centradas en robo de tokens confirma que los atacantes priorizan rutas de menor fricción operativa.
Para equipos técnicos, la mejor inversión inmediata es combinar hardening de RBAC, reducción de exposición de tokens y observabilidad de acciones sobre la API. No son medidas nuevas, pero sí las que más reducen el costo real de un incidente cuando el atacante ya consiguió entrar a un pod.
Fuentes
– https://unit42.paloaltonetworks.com/modern-kubernetes-threats/
– https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/
– https://kubernetes.io/docs/concepts/security/rbac-good-practices/