Parte: 10 — Seguridad en la nube y contenedores · Fuente: Documentación de HashiCorp Vault, AWS Secrets Manager y OWASP Secrets Management Cheat Sheet ⏱️ Duración estimada: 120 min · Nivel: Intermedio
Diseñar una gestión de secretos robusta en la nube: almacenamiento cifrado, acceso por identidad y no por credencial compartida, rotación automática, secretos dinámicos y detección de filtraciones. El alumno usará un gestor de secretos (Vault o el nativo del proveedor) e integrará el patrón de inyección segura en aplicaciones y contenedores.
Al finalizar, el alumno podrá:
| # | Tema | Por qué importa |
|---|---|---|
| 1 | El problema de los secretos | Filtraciones en repos, imágenes y logs |
| 2 | Gestores de secretos | Almacén cifrado con control de acceso |
| 3 | Rotación automática | Reduce la ventana de un secreto comprometido |
| 4 | Secretos dinámicos | Credenciales efímeras generadas al vuelo |
| 5 | Inyección segura en runtime | Sin secretos en la imagen ni en el código |
| 6 | Cifrado y KMS/envelope | Protección de la clave que protege los secretos |
| 7 | Detección de filtraciones | git-secrets, gitleaks, trufflehog |
# Guardar y leer un secreto en Vault (modo laboratorio)
vault kv put secret/miapp db_password=Sup3r
vault kv get secret/miapp
# Escanear un repositorio en busca de secretos filtrados
gitleaks detect --source . --report-format json --report-path leaks.json
vault kv get.secret/miapp y verifica que no puede leer otros paths.database para que Vault cree credenciales temporales con TTL corto; genera unas y observa su expiración.Elimina todos los secretos en claro de una app de laboratorio y su repo: muévelos a un gestor, configura rotación (o secretos dinámicos), inyéctalos en runtime por identidad y añade detección en CI.
Criterio de aceptación: gitleaks detect no reporta secretos en el repo ni en el historial, la
app obtiene sus credenciales del gestor en runtime (no hay secretos en la imagen ni en variables en
claro), y al menos un secreto rota automáticamente o se emite de forma dinámica con TTL.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
| Secreto sigue en el historial de git tras borrarlo del último commit | Persiste en commits anteriores; reescribe el historial y rota el secreto igualmente. |
| App no puede leer el secreto | Política del gestor demasiado restrictiva o identidad mal configurada; ajusta el binding. |
| Secreto en la imagen de contenedor | Se copió en build; muévelo a inyección en runtime y reconstruye. |
| Rotación rompe la app | La app cachea el secreto viejo; implementa recarga o usa el sidecar que renueva. |
| Token de Vault de larga vida | Riesgo si se filtra; usa tokens de corta vida y auth por identidad. |
❓ Si borro el secreto del código, ¿ya estoy seguro? No basta. Si el secreto estuvo alguna vez en el repositorio, sigue en el historial de git y probablemente ya se copió. Rótalo/revócalo siempre, además de eliminarlo, y reescribe el historial si hace falta.
❓ ¿Secretos estáticos con rotación o secretos dinámicos? Los dinámicos son superiores cuando el sistema los soporta: se crean bajo demanda con TTL corto y no hay nada persistente que robar. Para sistemas que no lo permiten, usa secretos estáticos con rotación automática frecuente.
❓ ¿Vault o el gestor nativo del proveedor? Ambos válidos. El nativo (Secrets Manager, Key Vault, Secret Manager) se integra sin desplegar nada y con IAM del proveedor. Vault brilla en multi-cloud, secretos dinámicos avanzados y control fino, a cambio de operarlo tú.
Clase 232 — Seguridad serverless