Gestión de secretos

Gestión de secretos

1) Por qué y qué es exactamente lo que consideramos un «secreto»

El secreto es cualquier material cuya divulgación lleva a comprometer el sistema o los datos: contraseñas, API-tokens, OAuth/JWT claves privadas, claves SSH, certificados, claves de cifrado (KEK/DEK), claves de firma de webhooks, DK Bases SN/caché, llaves de proveedores (pagos, proveedores de correo/SMS), cookies de sal/pepper, tokens de bots/chat, licencias.
Los secretos viven en el código, la confección, el entorno, las imágenes del contenedor, CI/CD, Terraform/Ansible, logs/dumps - la tarea de gestión de secretos: contabilidad → almacenamiento → entrega → uso → rotación → revocación → auditoría → eliminación.

2) Principios de arquitectura

Centralización. Una capa de confianza (Vault/Cloud Secret Manager/KMS) para almacenamiento, emisión y auditoría.
Los privilegios más pequeños (PoLP). Acceso sólo a los servicios/roles deseados, por un período mínimo.
Una vida corta. Se prefieren los secretos dinámicos/temporales con TTL/lease.
Crypto-agility. Posibilidad de cambiar algoritmos/longitudes de clave sin tiempo de inactividad.
Separación de secretos de código/imágenes. No hay contraseñas en los repositorios, ni en las imágenes Docker.
Observabilidad y auditoría. Cada operación de emisión/lectura de secretos es lógica y alertada.
Rotación automática. La rotación es un proceso en pipelina, no una acción manual.

3) Soluciones y roles de componentes estándar

KMS/HSM. Confianza raíz, operaciones de cifrado/envoltura de claves (envelope).
Secret Manager/Vault. Almacenamiento de versiones de secretos, ACL, auditoría, secretos dinámicos (DB, cloud-IAM, PKI), patrones de rotación.
PKI/CA. Emisión de certificados de corta duración mTLS/SSH/JWT.
Agente/sidecar. Entrega de secretos al rantime (archivos tmpfs, in-memory k/v, hot-reload).
Controladores/operadores CSI. Integración con Kubernetes (Controlador de CSI de tienda secreta, cert-manager).
Capa de cifrado en Git. SOPS/age, git-crypt (para código de infraestructura).

4) Clasificación y política

• TTL/lease y frecuencia de rotación;
• método de emisión (altavoz vs estático), formato, medio;
• la política de acceso (quién/dónde/cuándo/por qué), los requisitos de mTLS y la autenticación mutua;
• la auditoría (que es lógica, cuánto almacenamos, quién ruge);
• procedimientos de break-glass y revocación.

5) Ciclo de vida del secreto

1. Creación: a través de la API de Secret Manager con metadatos (owner, tags, scope).
2. Almacenamiento: encriptado (envelope: DEK envuelto KEK desde KMS/HSM).
3. Entrega: a petición de una entidad autorizada (OIDC/JWT, SPIFFE/SVID, mTLS).
4. Uso: exclusivamente en memoria/en tmpfs; prohibición de lógica/volcado.
5. Rotación: por TTL o evento (compromiso); soporte para versiones paralelas (N-1).
6. Revocación/bloqueo: caducidad inmediata de lease, disable de cuenta/clave en el sistema de destino.
7. Eliminación: destrucción de versiones/material, cadena de auditoría clara.

6) Secretos dinámicos (recomendado por defecto)

• Credenciales de BD (Postgres/MySQL) con TTL 15-60 min.
• Claves temporales de nube (AWS/GCP/Azure) por función de servicio.
• Certificados SSH (plazo 5-30 min), certificados X.509 (hora/día).
• JWT temporales para la firma de solicitudes, brókets de sesión.
• Pros: mínimo blast radius, revocación simplificada (nada «permanecerá» en el mundo).

7) Entrega de secretos al rantime

• Secret Store CSI Driver → montar secretos desde el gestor externo en el pod como archivos (tmpfs).
• Evitar Kubernetes Secret como única fuente (base64 ≠ cifrado); si es necesario, active el proveedor de KMS para etcd.
• Agente Sidecar (Vault Agent/Secrets Store) con lease auto-reneval y hot-reload.
• VM/Bare-metal: agente de sistema + mTLS a Vault/Secret Manager, caché en memoria, TCB mínimo.
• Serverless: integre la nube con la sustitución transparente de secretos como variables de entorno/archivos, pero evite envolventes de larga vida - preferiblemente archivos/en memoria.

Ejemplo (Kubernetes + CSI, conceptualmente)

yaml apiVersion: v1 kind: Pod metadata: { name: app }
spec:
serviceAccountName: app-sa # is associated with a role in Secret Manager volumes:
- name: secrets csi:
driver: secrets-store. csi. k8s. io readOnly: true volumeAttributes:
secretProviderClass: app-spc containers:
- name: app volumeMounts:
- mountPath: /run/secrets name: secrets readOnly: true

8) Integración de CI/CD e IaC

CI: Los trabajadores reciben tokens de vida corta por OIDC (Identidad de taller). Prohibición de los secretos «enmascarados» que caen en los registros; paso «escanear fugas» (trufflehog/gitleaks).
CD: deploy toma secretos en el momento de poner, no los graba en artefactos.
IaC: Terraform almacena variables en Secret Manager; el estado (state) está cifrado y restringido por acceso.
SOPS/age: para repos - almacenar manifiestos cifrados, claves - bajo KMS.

Ejemplo (fragmento SOPS)

yaml apiVersion: v1 kind: Secret metadata: { name: app }
data:
PASSWORD: ENC[AES256_GCM,data:...,sops:...]
sops:
kms:
- arn: arn:aws:kms:...
encrypted_regex: '^(data    stringData)$'
version: '3. 8. 0'

9) Políticas de acceso y autenticación de cargas de trabajo

Workload identity: SPIFFE/SPIRE, Kubernetes SA→OIDC→IAM-роль, mTLS.
Tokens temporales: TTL corto, scope estrecho.
ABAC/RBAC en Secret Manager: «quién puede leer el secreto de X en el entorno Y» está separado de «quién puede crear/rotar».
Multi-alquiler: namespaces/key-rings separados por inquilino; políticas separadas y presentación de informes.

10) Rotación, versiones y compatibilidad

Comparte el identificador del secreto y sus versiones ('secret/app/db # v17').
Mantenga dos versiones activas (N y N-1) para la rotación sin parar.
La rotación es evolutiva: al despedir, comprometer, cambiar de proveedor, migrar algoritmos.
Automatice: las rotaciones cron/backend en Vault/Secret Manager + disparadores webhook de reinicio de aplicaciones/reneval.

Mini receta «doble llave» rotación webhook

text
T0: we publish two secrets in the provider: current, next
T1: the application starts accepting signatures by both current and next
T2: external system switches signature to next
T3: we do next -> current, re-release new next

11) Almacenamiento fuera del rantime: copias de seguridad y artefactos

Nunca caer en artefactos (imágenes, archivos de registros, volcado).
Backups de Secret Manager: encriptar, claves de almacenamiento fuera del mismo bucle (separation of duties).
Etiquetas y escáneres DLP: detección de secretos en S3/Blob/GCS, Git, artefactos CI.

12) Observabilidad, auditoría y SLO

Métricas: número de entregas/secreto/servicio, proporción de lease caducado, TTL promedio, tiempo de rotación, tiempo de convergencia (segundos/minutos antes de la «aceptación» de la nueva versión).
Registros de auditoría: quién/qué/cuándo/dónde/por qué; almacenamiento por separado, también encriptado.
SLO: 99% de las entregas <200 ms; 0 fugas en los logs; 100% de los secretos tienen owner/TTL/etiquetas; Los secretos 100% críticos son dinámicos o rotativos ≤ 30 días.
Alertas: el secreto expira <7 días (para los estáticos), un estallido de fallos de autenticación a la bóveda, sin lecturas de secreto> N días (muerto), fuentes geo/ASN inesperadas.

13) Errores frecuentes y cómo evitarlos

Secretos en Git/imágenes. Utilice SOPS/age y escáneres; la política de prohibir las líneas «desnudas».
Envvars como un medio a largo plazo. Dé preferencia a los archivos tmpfs/in-memory; limpie el entorno en los forkes/volquetes.
Los mismos secretos para dev/stage/prod. Divida por los alrededores.
Contraseñas estáticas de larga vida. Cambie a dinámico/de vida corta.
Una clave maestra única «para todo». Divida por inquilinos/proyectos/servicios.
No hay hot-reload. La aplicación requiere reestablecer → ventana de vulnerabilidad al rotar.

14) Ejemplos de integraciones (esquemáticamente)

Acceso dinámico Vault a Postgres

hcl
Vault: role -> issues the user to the database with TTL 30m and privileges only to the app path "database/creds/app-role" {
capabilities = ["read"]
}
Application requests/database/creds/app-role -> receives (user, pass, ttl)

Firma JWT de solicitudes (breve plazo)

La clave privada se almacena en Secret Manager; el servicio solicita una señal-token de corta duración y el agente local firma el payload (la clave no se pasa a la aplicación como una cadena).

Certificados SSH para administradores

Emisión de SSH-cert durante 10 minutos por SSO (OIDC), sin distribución de claves permanentes.

15) Seguridad en los bordes

Logs/tracks/métricas: saneadores, filtros para claves/patrones conocidos; campos «secretos» - enmascaramiento en APM.
Informes de volcado/choque: cortar por defecto; si es necesario, encriptar y limpiar.
Aplicaciones del cliente/mobile: minimizar los secretos fuera de línea, usar almacenamiento de plataforma (Keychain/Keystore), enlace al dispositivo, pinning TLS con rodillo de emergencia.

16) Cumplimiento

PCI DSS: prohibición de almacenar PAN/secretos sin cifrado; estricto control de acceso y rotación.
ISO 27001/SOC 2: requisitos de administración de activos, registro, control de acceso, cambio de configuración.
GDPR/reguladores locales: minimización, acceso por necesidad, auditoría.

17) Procesos y runbook

Puesta en marcha

1. Inventario de secretos (repositorios, CI, imágenes, runtime, backups).
2. Clasificación y etiquetas (owner, environment, tenant, rotation-policy).
3. Selección de almacenamiento (Vault/Cloud SM) + integración con KMS/HSM.
4. Configuración de la emisión por identidad de flujo de trabajo (OIDC/SPIRE).
5. Incluir secretos dinámicos para el DAB/nubes/PKI.
6. Auto-rotación y hot-reload; alertas en las expiraciones.
7. Configuración de escáneres de fugas y Data Catalog/DS.

Escenarios de emergencia

Sospecha de filtración: lista de espera de acceso, rotación inmediata, revocación de certificados/claves, reinicio de tokens, activación de auditorías elevadas, RCA.
Secret Manager no está disponible: caché local en memoria con TTL pequeño, degradación de funciones, restricción de nuevas conexiones, pasos de break-glass manual.
Compromiso de clave raíz: regeneración de clave-hierarquía, rewrap de todos los DEK, verificación de todas las entregas por ventana de riesgo.

18) Hojas de cheques

Antes de la venta

• Los secretos se eliminan del código/imágenes; escáneres de fugas incluidos.
• Para secretos críticos, se incluyen mecanismos dinámicos.
• Entrega a través de sidecar/CSI/tmpfs con hot-reload, sin envvars duraderos.
• Políticas IAM/ABAC configuradas, enlace a identidad de trabajo.
• Rotación automática y versiones dobles (N, N-1) para compatibilidad.
• Métricas/alertas/auditorías incluidas; pruebas de degradación superadas.

Operación

• Informe mensual: propietarios, TTL, secretos caducados, no utilizados.
• Rotaciones periódicas y pentestas de vías de fuga (registros, volcado, artefactos).
• Plan de agilidad crypto y reemplazo de emergencia de CA/raíces.

19) FAQ

P: ¿Es suficiente el Administrador Secreto sin KMS?
R: Para el nivel básico, sí, pero es mejor usar encriptación envelope: KEK en KMS/HSM, los secretos están envueltos. Esto simplifica la revisión y el cumplimiento.

P: ¿Qué elegir - estático o altavoz?
R: Por defecto, altavoz. Deje el estático sólo donde no hay proveedores compatibles y queme el TTL hasta días/horas + rotación automática.

P: ¿Cómo hacer que los secretos lleguen a los microservicios de forma segura?
О: Workload identity → mTLS к Secret Manager → sidecar/CSI → файлы в tmpfs + hot-reload. Sin registros, sin envvars «para siempre».

P: ¿Es posible guardar secretos en Kubernetes Secret?
R: Sólo con cifrado etcd activado con proveedor KMS y políticas estrictas. Prefiera almacenamiento externo y CSI.

P: ¿Cómo «enjugar» el acceso del inquilino?
R: Revocar/bloquear sus políticas en Secret Manager, invalidar todas las leases, rotación/regeneración de claves; cuando se utiliza KMS - desactivar unwrap de los KEK correspondientes.

• «Encriptación de At Nat»
• «Encriptación In Transit»
• «Administración de claves y rotación»
• «Autenticación S2S»
• «Firma y verificación de solicitudes»