Cuando incrustas una credencial en una AMI, esa credencial se propaga con cada copia de la imagen, se queda grabada en los snapshots y puede acabar en cuentas o regiones que nunca imaginaste. Basta que alguien con acceso de lectura a la imagen la extraiga. Y como las imágenes se conservan por versiones, el secreto puede sobrevivir mucho después de que creyeras haberlo rotado.
La regla de oro: la imagen define la máquina; los secretos se entregan en tiempo de ejecución.
Dónde deben vivir los secretos
| Servicio | Nube o entorno | Ideal para |
|---|---|---|
| AWS Secrets Manager | AWS | Credenciales rotables, integración nativa |
| AWS SSM Parameter Store | AWS | Parámetros y secretos sencillos, bajo coste |
| HashiCorp Vault | Multinube | Secretos dinámicos y control fino |
| Azure Key Vault / Google Secret Manager | Azure / GCP | Equivalentes nativos en cada nube |
Guarda los secretos en un gestor dedicado, nunca en la imagen ni en user-data en claro.
El patrón correcto: identidad, no contraseñas
La forma más segura de que una instancia acceda a recursos no es darle una contraseña, sino darle una identidad. En AWS, un rol IAM asociado a la instancia le permite obtener credenciales temporales y rotadas automáticamente, sin que ninguna clave viaje en la imagen.
- Roles IAM de instancia: la instancia asume un rol y obtiene credenciales temporales.
- IRSA en Kubernetes: identidad por pod, sin claves compartidas en el nodo.
- Secretos dinámicos con Vault: credenciales de vida corta generadas bajo demanda.
- Inyección en runtime: la aplicación lee el secreto del gestor al arrancar, no de un fichero horneado.
Protege los metadatos: IMDSv2
Las credenciales temporales del rol se obtienen a través del servicio de metadatos de la instancia. Un atacante que explote un fallo de SSRF podría intentar robarlas. IMDSv2 exige un token de sesión y mitiga esa clase de ataques: actívalo como obligatorio en tus lanzamientos.
Higiene: no dejes rastros en la imagen
- Antes de sellar la AMI, borra historiales de shell, logs con credenciales, claves SSH temporales y ficheros de configuración con secretos.
- Escanea la imagen en busca de secretos con herramientas como gitleaks o trufflehog adaptadas a sistemas de ficheros.
- No dejes claves autorizadas de más en
~/.ssh/authorized_keys. - Evita AMIs públicas con secretos: si publicas, revisa que no filtras nada.
Checklist rápida
- Cero secretos horneados en la imagen.
- Gestor de secretos con roles o identidad federada.
- IMDSv2 obligatorio.
- Escaneo de secretos en el pipeline.
- Limpieza de rastros antes de sellar.
Preguntas frecuentes
¿Y si mi aplicación necesita el secreto en el arranque?
Que lo lea del gestor de secretos en tiempo de ejecución usando la identidad de la instancia. Así el secreto nunca viaja dentro de la imagen y se puede rotar sin reconstruir.
¿Es seguro usar user-data para pasar secretos?
No en texto plano: user-data es legible desde los metadatos. Úsalo, como mucho, para indicar de qué secreto tirar del gestor, protegiendo los metadatos con IMDSv2.
¿Cómo detecto si una imagen ya tiene secretos horneados?
Escaneándola con herramientas de detección de secretos sobre su sistema de ficheros y revisando ficheros de configuración, historiales y claves autorizadas antes de usarla.
En imaxe.cloud construimos imágenes limpias de credenciales y pensadas para integrarse con gestores de secretos e identidad federada.
