Tema 7

7. Gestión de secretos, credenciales, certificados y rotación segura

Los secretos permiten que aplicaciones, pipelines y personas accedan a sistemas críticos. Si se filtran, se reutilizan o no se rotan, pueden convertirse en una vía directa hacia datos, infraestructura y producción.

Objetivo Gestionar secretos sin exposición innecesaria
Enfoque Credenciales, certificados, vaults y rotación
Resultado Reducir impacto de secretos filtrados o vencidos

7.1 Introducción

Un secreto es cualquier dato que permite autenticarse, descifrar información o acceder a un recurso protegido. Puede ser una contraseña, token, clave API, clave privada, cadena de conexión, certificado, credencial cloud o llave de firma.

En cloud, contenedores y DevSecOps, los secretos aparecen en muchos lugares: repositorios, pipelines, variables de entorno, manifiestos, gestores de configuración, imágenes, clusters, funciones serverless y herramientas de terceros. Esa dispersión aumenta el riesgo de filtración.

La gestión segura de secretos busca que las credenciales estén centralizadas, cifradas, auditadas, rotadas y entregadas a cada identidad solo cuando las necesita.

7.2 Qué se considera secreto

No todos los datos sensibles son secretos, pero todo secreto debe tratarse como información crítica. Un secreto expuesto puede permitir acceso directo sin explotar vulnerabilidades.

Tipo Ejemplos Riesgo si se filtra
Credenciales de usuario Contraseñas, tokens MFA de recuperación Acceso no autorizado a cuentas humanas
Credenciales de aplicación API keys, cadenas de conexión, tokens OAuth Acceso a APIs, datos o servicios internos
Credenciales cloud Access keys, service principals, service accounts Creación, lectura o modificación de recursos cloud
Claves criptográficas Claves privadas, llaves de firma, claves SSH Suplantación, descifrado o firma maliciosa
Certificados TLS, mTLS, certificados internos Interrupciones, MITM o suplantación de servicios

7.3 Dónde no deben almacenarse secretos

Muchos incidentes ocurren porque los secretos se guardan en lugares cómodos pero inseguros. La regla práctica es simple: un secreto no debe vivir donde no pueda controlarse, auditarse y rotarse.

  • Repositorios de código, incluso si son privados.
  • Imágenes de contenedores o capas intermedias de build.
  • Archivos de configuración versionados.
  • Variables de entorno sin control ni cifrado.
  • Mensajes de logs, trazas, errores o dumps.
  • Wikis, tickets, chats o documentación operativa.
  • Scripts locales compartidos entre operadores.
  • Manifiestos Kubernetes aplicados sin cifrado ni control de acceso.
Si un secreto aparece en Git, en una imagen o en un log, debe asumirse comprometido aunque el repositorio o sistema sea privado.

7.4 Gestores de secretos

Un gestor de secretos permite almacenar, cifrar, controlar acceso, auditar y rotar secretos desde un lugar centralizado. Puede ser un servicio cloud administrado, una herramienta dedicada como Vault o una solución integrada en la plataforma.

Funciones esperadas:

  • Cifrado de secretos en reposo mediante claves protegidas.
  • Control de acceso basado en identidad y políticas.
  • Entrega segura a aplicaciones, pipelines y operadores.
  • Auditoría de lectura, escritura, actualización y eliminación.
  • Versionado y recuperación controlada.
  • Rotación manual o automática.
  • Integración con KMS, IAM, Kubernetes y CI/CD.

7.5 Acceso a secretos por identidad

El acceso a secretos debe depender de la identidad del actor que los necesita. Una aplicación no debería usar un secreto compartido si puede autenticarse con una identidad de workload y obtener solo el secreto correspondiente.

Actor Necesidad Enfoque seguro
Aplicación backend Conectarse a una base de datos Cuenta de servicio con acceso solo a esa credencial
Pipeline CI/CD Publicar imagen o desplegar infraestructura Rol temporal y secreto limitado al entorno
Operador Acceso excepcional para soporte Just-in-time, aprobación, sesión auditada y vencimiento
Workload Kubernetes Consumir una API interna Identidad de workload, secreto montado temporalmente o sidecar

7.6 Rotación de secretos

Rotar un secreto significa reemplazarlo por uno nuevo y retirar el anterior sin interrumpir el servicio. La rotación reduce el tiempo útil de una credencial comprometida y limita el impacto de exposiciones antiguas.

Una rotación segura debe contemplar:

  • Generar el nuevo secreto en el gestor central.
  • Actualizar aplicaciones o servicios consumidores.
  • Validar que el nuevo secreto funciona correctamente.
  • Revocar el secreto anterior.
  • Registrar la operación y su responsable.
  • Alertar errores de autenticación después del cambio.
Un secreto que no puede rotarse sin caída operativa es una deuda técnica de seguridad. Debe corregirse antes de que una filtración obligue a rotarlo bajo presión.

7.7 Secretos dinámicos y credenciales temporales

Siempre que sea posible, conviene reemplazar secretos estáticos por credenciales temporales. Un secreto dinámico se genera bajo demanda, tiene vencimiento y se revoca automáticamente.

Ejemplos:

  • Roles cloud asumidos por minutos u horas en lugar de access keys permanentes.
  • Credenciales de base de datos generadas por un vault con TTL definido.
  • Tokens de despliegue válidos solo para una ejecución de pipeline.
  • Certificados internos de corta duración emitidos automáticamente.
  • Accesos just-in-time para operadores.

Este enfoque reduce el valor de una credencial robada y mejora la trazabilidad.

7.8 Certificados y PKI

Los certificados permiten proteger comunicaciones, autenticar servicios y habilitar mTLS. Su gestión deficiente puede provocar caídas por vencimiento, suplantación de servicios o configuraciones criptográficas débiles.

Controles recomendados:

  • Inventariar certificados públicos e internos.
  • Automatizar emisión y renovación cuando sea posible.
  • Monitorear vencimientos con alertas anticipadas.
  • Proteger claves privadas y evitar copiarlas entre equipos.
  • Usar autoridades certificadoras confiables o internas bien gobernadas.
  • Revocar certificados cuando una clave se compromete o un servicio se retira.

7.9 Secretos en contenedores

Los contenedores complican la gestión de secretos porque las imágenes son portables y pueden distribuirse entre registros, ambientes y equipos. Nunca se deben incluir secretos dentro de una imagen.

Buenas prácticas:

  • No usar ARG o ENV en Dockerfile para secretos.
  • No copiar archivos con credenciales dentro de la imagen.
  • Montar secretos en runtime desde un gestor confiable.
  • Evitar que secretos aparezcan en comandos, procesos o logs.
  • Limitar qué contenedores pueden leer cada secreto.
  • Eliminar secretos temporales después de usarlos durante builds.

7.10 Secretos en Kubernetes

Kubernetes tiene objetos Secret, pero usarlos sin configuración adecuada puede generar falsa sensación de seguridad. Por defecto, un Secret es una forma de distribuir datos sensibles dentro del cluster; su protección real depende de cifrado, RBAC, auditoría e integración con gestores externos.

Medidas importantes:

  • Habilitar cifrado de secretos en etcd.
  • Restringir RBAC para lectura de secretos.
  • Evitar montar secretos en pods que no los necesitan.
  • Usar External Secrets, CSI drivers o integración con vaults cuando corresponda.
  • Auditar accesos a secretos y cambios en service accounts.
  • Separar secretos por namespace, aplicación y ambiente.

7.11 Secretos en CI/CD

Los pipelines suelen manejar credenciales de registros, proveedores cloud, herramientas de análisis, firma de artefactos y despliegue. Si el pipeline se compromete, esos secretos pueden usarse para alterar producción o robar artefactos.

Controles recomendados:

  • Usar variables protegidas y visibles solo para ramas o entornos autorizados.
  • Evitar imprimir secretos en logs del pipeline.
  • Reemplazar claves estáticas por identidad federada u OIDC cuando sea posible.
  • Separar secretos por ambiente y por etapa.
  • Limitar secretos disponibles en pull requests de forks o código no confiable.
  • Registrar acceso a secretos y rotarlos ante cambios de equipo o incidente.

7.12 Detección de secretos filtrados

La detección temprana reduce impacto. Los secretos pueden filtrarse en commits, issues, artefactos, imágenes, logs, paquetes publicados o capturas de pantalla.

Controles útiles:

  • Secret scanning en repositorios antes y después del commit.
  • Hooks locales o controles pre-receive en servidores Git.
  • Escaneo de imágenes y capas de contenedores.
  • Revisión de logs de CI/CD para evitar impresión accidental.
  • Alertas de proveedores cuando una clave aparece en repositorios públicos.
  • Políticas para bloquear merges si aparecen patrones de credenciales.

7.13 Respuesta ante filtración

Cuando un secreto se filtra, no alcanza con borrarlo del lugar visible. Debe revocarse o rotarse porque pudo haber sido copiado.

  1. Identificar el secreto, su alcance y los sistemas afectados.
  2. Revocar o rotar la credencial de inmediato.
  3. Revisar logs para detectar uso no autorizado.
  4. Eliminar el secreto de repositorios, imágenes, artefactos o logs cuando sea posible.
  5. Invalidar sesiones, tokens derivados o certificados relacionados.
  6. Corregir la causa que permitió la filtración.
  7. Registrar el incidente y ajustar controles preventivos.

7.14 Errores frecuentes

  • Guardar secretos en repositorios privados por considerarlos "seguros".
  • Usar la misma credencial en desarrollo, staging y producción.
  • No tener procedimiento probado de rotación.
  • Incluir secretos en imágenes de contenedores.
  • Dar acceso a todos los secretos a cualquier pipeline.
  • No monitorear vencimiento de certificados.
  • Permitir lectura de secretos Kubernetes a roles demasiado amplios.
  • Creer que borrar un commit elimina el riesgo de una credencial filtrada.
El objetivo no es esconder secretos en más lugares, sino reducir su cantidad, controlar su entrega, auditar su uso y poder rotarlos sin improvisación.

7.15 Lista de verificación

  • ¿Existe un gestor central de secretos para aplicaciones, pipelines y operadores?
  • ¿Los secretos están cifrados y protegidos por IAM mínimo?
  • ¿Las credenciales estáticas se reemplazan por roles temporales cuando es posible?
  • ¿Los secretos se separan por ambiente, aplicación y propósito?
  • ¿Hay rotación documentada y probada?
  • ¿Los certificados tienen inventario, renovación y alertas de vencimiento?
  • ¿Los repositorios, imágenes y pipelines tienen secret scanning?
  • ¿Existe un procedimiento claro para revocar secretos filtrados?

7.16 Qué debes recordar de este tema

  • Un secreto filtrado debe considerarse comprometido aunque el entorno sea privado.
  • Los secretos no deben estar en código, imágenes, logs ni documentación operativa.
  • Los gestores de secretos centralizan cifrado, acceso, auditoría y rotación.
  • Las credenciales temporales reducen impacto frente a robo o exposición.
  • La rotación debe estar automatizada o al menos probada antes de un incidente real.

7.17 Conclusión

La gestión de secretos es una disciplina central en cloud native. Aplicaciones, contenedores, pipelines y operadores necesitan credenciales, pero esas credenciales deben entregarse de forma controlada, auditable y temporal siempre que sea posible.

En el próximo tema estudiaremos el monitoreo de postura cloud: CSPM, inventario, configuración segura y detección de drift.

Volver al índice