Secrets - bóvedas y rotación
Las claves de API, los tokens de base de datos y los secretos salen del repositorio y van a bóvedas con rotación automática, identidad de corta duración y audit log centralizado.
Qué es
Un secreto en la nube es cualquier cosa que da acceso: clave de API, contraseña de base de datos, token de servicio, certificado privado. El punto crítico no es guardar el valor, es controlar quién puede leerlo, en qué momento y con qué rastro.
Tres prácticas se repiten en cualquier arquitectura madura: el secreto vive en una bóveda (Vault, Secrets Manager, Parameter Store), la aplicación lo lee en tiempo de ejecución (no en el build), y el tiempo de vida es corto. Una credencial que dura un año se puede revocar hasta 365 días después de la filtración, y ahí es donde está el riesgo real.
El patrón clásico de incidente
Cada semana aparece el mismo argumento: alguien hace commit de una Access Key de AWS en un repositorio público o en un chat. Los bots de mineros barren GitHub en minutos, encuentran la clave, validan si todavía funciona y empiezan a minar cripto en las instancias reservadas de la víctima. La factura llega antes que la alerta.
El detalle que mata: la clave estaba en una variable de entorno, así que el equipo creía que no había hecho 'commit de un secreto'. Pero el .env.example con placeholder, la captura del panel de la nube, el log del CI con el valor impreso... cada uno de ellos filtra. Escanear 'AWS_ACCESS_KEY_ID' en el repositorio antes del merge es higiene básica que casi nadie hace.
Secreto estático versus identidad de workload
El camino viejo es estático: creas un usuario para la aplicación, generas Access Key + Secret, lo pegas en el .env y lo ejecutas. El secreto sigue válido hasta que alguien lo revoque, y cada deploy nuevo multiplica quién tiene una copia.
El camino moderno es la identidad de workload. En AWS se llama IRSA (IAM Roles for Service Accounts), en GCP es Workload Identity, en Azure es Workload Identity Federation. La idea es la misma: el clúster (EKS, GKE, AKS) entrega un token corto al pod, y la nube cambia ese token por credenciales temporales vía STS/OIDC. No existe un secreto estático que filtrar.
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-frontend
namespace: prod
annotations:
eks.amazonaws.com/role-arn: arn:aws:iam::111122223333:role/app-frontend-prodAWS_ACCESS_KEY_ID=AKIA... # NUNCA hagas esto
AWS_SECRET_ACCESS_KEY=wJalr... # saca del código el espacio del buildLeyendo de la bóveda en runtime
Cuando el workload no puede asumir una identidad federada (caso común en servicios antiguos o en SaaS de terceros), la alternativa es buscar el secreto en la bóveda al iniciar la aplicación, montarlo en memoria y nunca persistirlo en disco.
La diferencia entre buscar en runtime y copiar en el build es la diferencia entre que el secreto exista en una imagen Docker (que alguien puede abrir) y que exista solo en el heap del proceso en ejecución. El segundo escenario aún puede filtrarse por log o dump, pero es órdenes de magnitud más difícil.
Rotación: por qué la clave de 5 años es un riesgo
La rotación es el ejercicio de reemplazar un secreto antes de que expire solo o de que alguien lo haya comprometido. Las bóvedas modernas lo tratan como ciudadano de primera: Secrets Manager tiene rotación automática vía Lambda, Vault tiene dynamic secrets que expiran en minutos, Parameter Store soporta rotación por evento.
La regla práctica: si no puedes rotar la clave sin downtime, no puedes revocarla bajo presión. Y bajo presión es cuando la revocación tiene que ocurrir.
Dónde aparece en el día a día
- inicio de la aplicación: el SDK de la bóveda lee los secretos en el boot, los expone in-memory y falla cerrado si la bóveda está caída
- CI/CD: los secrets del pipeline vienen de la bóveda del proveedor, nunca de variables globales del runner
- deploy de base de datos: rotación automática de la contraseña de RDS vía Lambda + Secrets Manager, sin ventana de mantenimiento
- respuesta a incidentes: la revocación central derriba todas las copias en segundos, y el próximo inicio toma el valor nuevo
Puntos fuertes
- centralización: un único panel muestra quién tiene qué secreto y cuándo lo usó por última vez
- revocación inmediata: quitas el acceso en la bóveda, y todas las aplicaciones pierden el secreto en el próximo request
- rotación sin downtime: bases de datos, API keys y tokens pueden cambiarse con la aplicación en línea
Limitaciones
- la identidad de workload exige una configuración fina (OIDC, trust policy, audience) que es fácil de equivocar en clústeres nuevos
- los secretos aún se filtran por log, dump o error de código: nada reemplaza el escaneo de logs por una bóveda
- costo y latencia: leer por request puede añadir cientos de milisegundos y unos centavos por millón de llamadas
conexiones en el mapa
- KMS & crypto - claves y envelopescifra los secretosSecrets - bóvedas y rotación
actualizado el 14/10/2026 · fuentes para profundizar · reportar un error
en otros dominios
- Secrets Scanningappseces el mismo problema: secretos fuera del código
- Hardening de CI/CDsecengOIDC en lugar de secretos estáticos en el pipeline
Estudia antes
pon a prueba lo que entendiste
Cargando preguntas…