Más de 2,000 cuentas de servicio sin dueño: el problema de IAM multinube
Los entornos grandes en la nube generan su propio tipo de pánico. No aparece el primer día, ni siquiera el primer año. Aparece hacia el tercer año, después de la tercera adquisición y el quinto clúster de Kubernetes, cuando alguien pregunta: "Un momento… ¿cuántas cuentas de servicio tenemos en realidad?".
En este caso la respuesta fue más de 2,000 identidades de máquina repartidas entre AWS, Azure y GCP. No había inventario centralizado ni una política de rotación coherente, solo una mezcla de roles de IAM, service principals, identidades de carga de trabajo e identidades de pods de Kubernetes. Eso es una bomba de relojería de gobierno, bastante más que "un poco desordenado".
Y las restricciones son brutales:
- Descubrimiento automático de las identidades de máquina
- Rotación sin tiempo de inactividad en las aplicaciones
- Recomendaciones de mínimo privilegio basadas en el uso real
- Integración con CI/CD (Jenkins, GitHub Actions)
- Arquitectura API-first
- Sin agentes
- Sin cambios de código
- Sin proyectos experimentales de seis meses
Además, el problema se limita expresamente al ciclo de vida de las identidades de máquina a gran escala, y el PAM para personas queda fuera. La mayoría de las empresas se atascan en este punto sin decirlo, así que vale la pena repasar qué es realista de verdad.
No hay un botón mágico que lo unifique todo
Ya lo has visto en tus evaluaciones. CyberArk es potente y caro, y da la sensación de llevar un tanque a una pelea con navajas.
HashiCorp Vault es sólido, pero alguien tiene que operarlo: clústeres de HA, backends de almacenamiento, motores de secretos y la deriva de políticas suman trabajo para un equipo entero.
Los gestores de secretos nativos de la nube, como AWS Secrets Manager y Azure Key Vault, cumplen pero están fragmentados, y acabas gestionando tres planos de control distintos. La fragmentación es justo lo que te trajo hasta aquí.
El sector todavía no ha producido un "gobernador de identidades de máquina multinube" limpio, neutral respecto al proveedor y que no exija ningún esfuerzo operativo. Entonces, ¿qué hacen de verdad las empresas? Lo resuelven con arquitectura, y ningún producto por sí solo hace el trabajo.
El patrón que se impone: acabar con las credenciales estáticas
Fíjate en la señal más fuerte del debate:
Identidad de carga de trabajo + federación para las llamadas entre nubes. Evita guardar claves o credenciales estáticas.
Eso es más una estrategia que una recomendación de producto. En lugar de rotar claves de acceso de larga duración, perseguir la dispersión de secretos y gestionar el ciclo de vida de las contraseñas, los equipos eliminan el problema por completo.
En Kubernetes, esto suele significar usar federación OIDC, dejar que las cargas de trabajo asuman roles de forma dinámica e intercambiar tokens de corta duración entre nubes. AWS lo admite con los roles de IAM para cuentas de servicio, GCP con la federación de identidades de carga de trabajo y Azure con las credenciales federadas para service principals.
Cuando los conectas bien, los pods no guardan credenciales. Las piden, las credenciales caducan y se renuevan solas. No hay tiempo de inactividad por rotación, ni agente, ni cambios de código si ya usas los proveedores de credenciales por defecto de los SDK. Por eso este enfoque escala.
¿Y el descubrimiento?
Aquí es donde la cosa se pone seria. No tienes un inventario centralizado, y antes de optimizar la rotación necesitas visibilidad. Las empresas lo abordan de tres formas principales.
1. Inventario nativo de la nube + agregación
Extrae los datos de identidades de AWS IAM, Azure Entra ID, GCP IAM y la API de Kubernetes, y llévalos a una plataforma de datos central (aunque sea algo tan simple como exportaciones programadas a un data warehouse).
No es glamuroso, pero te da una lista de identidades de máquina, vínculos de roles, marcas de tiempo del último uso y políticas asociadas, y encima puedes construir recomendaciones de mínimo privilegio. No viene listo para usar, pero es más rápido que desplegar una plataforma PAM enorme.
2. Políticas como código + monitoreo de deriva
Las empresas que apuestan por modelos API-first tratan IAM como infraestructura. Estado de Terraform + registros de la nube + métricas de uso = mapa de permisos efectivos.
A partir de ahí puedes identificar acciones sin usar, detectar roles con privilegios de más y abrir automáticamente pull requests con políticas reducidas. No es del todo autónomo, pero escala mejor que la revisión manual y encaja con tu requisito "API-first".
3. Herramientas de grafos de identidad (categoría emergente)
Hay una clase más reciente de herramientas que construyen grafos de identidad entre nubes. Ingieren asignaciones de roles, políticas de confianza, relaciones de federación y telemetría de uso, y después sacan a la luz privilegios excesivos, configuraciones erróneas de confianza entre nubes y cuentas de servicio dormidas.
Son más ligeras que las suites PAM completas y a menudo no usan agentes. La contrapartida es que primero son herramientas de visibilidad para el gobierno, y la automatización del ciclo de vida a veces queda en segundo lugar.
Por qué Vault resulta pesado (y por qué a veces sigue ganando)
A Vault se le descarta por su "carga operativa", y la tiene. Aun así, algunas empresas lo eligen, y lo que las atrae son las credenciales dinámicas más que el almacenamiento de secretos.
Vault puede generar credenciales de base de datos de corta duración, emitir tokens temporales de acceso a la nube y aplicar políticas de TTL y renovación. Si estás dispuesto a operarlo como es debido, se convierte en un intermediario de identidades de máquina.
Eso sí, es un compromiso, y si no tienes personal para ello, te va a doler. La línea divisoria son tus ganas de dedicarle personal, mucho más que cualquier lista de funciones.
La realidad de la integración con CI/CD
Necesitas integración con Jenkins y GitHub Actions. La mayoría de las empresas lo resuelven usando federación OIDC desde GitHub Actions hacia roles de la nube, dejando que Jenkins asuma roles de la nube de forma dinámica y eliminando por completo las credenciales estáticas de CI.
Eso reduce el riesgo de filtración de credenciales, los ciclos de rotación manual y la dispersión de secretos en los pipelines. También encaja con tu restricción de "sin cambios de código", porque los SDK modernos ya admiten la inyección de tokens a través del entorno.
Lo que las empresas despliegan de verdad en 2026
La respuesta honesta es una combinación:
- Federación de identidades de carga de trabajo en todos los sitios posibles
- Credenciales de corta duración en lugar de rotación
- Informes centralizados del inventario de identidades
- Herramientas de análisis de políticas
- Gestores de secretos mínimos solo donde la federación no es posible
No unifican todo bajo una megaplataforma; estandarizan patrones. La pregunta que responden es "¿cómo eliminamos las credenciales de máquina estáticas?", y elegir proveedor viene después.
Lo que probablemente no deberías hacer
No:
- Intentes centralizar todos los secretos en un único vault en seis meses
- Obligues a las aplicaciones a cambiar sus patrones de autenticación
- Despliegues agentes en 2,000 cargas de trabajo
- Intentes ajustar a mano cada política de IAM
Así es como se disparan los plazos. Tus restricciones están claras, así que el diseño tiene que respetarlas.
Si este fuera mi entorno
Con más de 2,000 cuentas de servicio en tres nubes, mis prioridades serían estas:
Fase 1 (90 días):
- Inventariar las identidades de máquina en todas las nubes
- Activar la federación de identidades de carga de trabajo para las cargas nuevas
- Quitar de CI/CD las credenciales estáticas nuevas
Fase 2 (los 90 días siguientes):
- Sustituir las claves de larga duración por tokens federados donde sea posible
- Introducir el recorte de políticas basado en el uso
- Crear paneles de propiedad de las identidades
Fase 3:
- Evaluar si una plataforma ligera de gobierno de identidades aporta algo
Fíjate en que ahí no hay ningún despliegue de una plataforma gigante. Tu verdadero enemigo es la dispersión, más que cualquier falta de herramientas.
La conclusión incómoda
El gobierno de las identidades de máquina multinube es un problema de arquitectura, y comprar un producto no lo va a resolver. Las empresas a las que les sale bien:
- Dejan de rotar secretos y empiezan a eliminarlos
- Dejan de centralizar a mano y empiezan a federar automáticamente
- Dejan de pensar en "meterlo todo en un vault" y empiezan a pensar en "intercambio de confianza"
Rotar mejor las contraseñas importa menos que tener menos contraseñas desde el principio. Los equipos que lo asumen pronto son los que dejan de despertarse a las 3 de la madrugada preguntándose qué cuenta de servicio olvidada sigue teniendo acceso de administrador a producción.