Administrar configuraciones y secretos

Administrar configuraciones y secretos

1) Por qué es necesario

• Predecible (esquemas, validación, versiones).
• Seguro (cifrado, derechos mínimos, rotación).
• Administrado (GitOps, auditoría, revisiones).
• Dinámico donde esté justificado (flags de función, parametrización de límites).

2) Clasificación de artefactos

Confecciones públicas: fichas, umbrales, timautas, flags feature (sin secretos).
Configuraciones sensibles: parámetros que cambian el comportamiento de las rutas críticas (por ejemplo, límites de pago).
Secretos: contraseñas/claves/tokens/certificados/materiales de cifrado.
Artefactos de confianza: certificados raíz/intermedio, políticas PKI, claves KMS.

Principio de custodia separada y derechos: secretos ≠ públicos ≠ sensibles.

3) Jerarquía de configuraciones

1. Global defaults (org-wide).

2. Environment (`prod/stage/dev`).

3. Region (`eu-central-1`, `us-east-1`).

4. Tenant/Brand (para multi-tenant).

5. Servicio (microservicio específico).

6. Override (runtime): conmutadores temporales.

Reglas de fusión: «abajo gana», el conflicto es sólo a través de MR/approval.

Ejemplo (YAML)

yaml defaults:
http:
timeout_ms: 800 retry: 2 prod:
http:
timeout_ms: 1200 service: payments-api overrides:
eu-central-1:
http:
timeout_ms: 1500

4) Esquemas y validación

Cada configuración es un contrato de esquema (JSON Schema/OPA/validadores en CI).

Tipos, rangos, campos obligatorios, valores predeterminados.
«Reglas de guardia» (no se puede poner 'retry> 5', 'p95 _ target <50ms').
Comprobación automática en CI y cuando se aplica (admission-webhook/KRM).

Fragmento de JSON Schema

json
{
"type":"object",
"properties":{
"http":{"type":"object","properties":{"timeout_ms":{"type":"integer","minimum":100,"maximum":10000},"retry":{"type":"integer","minimum":0,"maximum":5}},"required":["timeout_ms"]},
"feature_flags":{"type":"object","additionalProperties":{"type":"boolean"}}
},
"required":["http"]
}

5) Modelos de entrega de confecciones

Static (imagen-baked): confiable, pero requiere restart.
Push/Watch: los agentes/sidecar reciben actualizaciones (stream/poll) y señalan a la aplicación.
Pull on startup: obtenemos un snapshot al arrancar (simplificar el hot-path).
Edge cache/proxy para cargas geo-distribuidas.

Lo principal: atomicidad y versionamiento de snapshots, control de compatibilidad y retroceso rápido.

6) Herramientas y roles

Almacenes de configuración: Git (fuente de la verdad) + GitOps (Argo/Flux), Parameter Store/Config Service.
Almacenes de secretos: Vault, AWS Secrets Manager/SSM, GCP Secrets, Azure KV.
Cifrado: KMS/HSM, SOPS (age/GPG/KMS), Secrets sellados, Cifrado de tránsito (Vault).
Entrega: CSI Secrets Store, Vault Agent Injector/Sidecar, contenedores init.
Banderas/altavoces: plataforma de banderas de fichas (incluido kill-switch de emergencia).

7) Cifrado: modelos y prácticas

At nat: KMS claves de proyecto/entorno, encriptación envelope.
En tránsito: TLS/mTLS con autenticación mutua.
At use: descifrar lo más tarde posible, preferiblemente en la memoria de proceso/sidecar (sin escritura en disco).
Jerarquía clave: raíz (HSM) → KMS CMK → llaves de datos (DEK).
Rotación: calendario (90/180 días) + por evento (compromiso/salida del empleado).

8) Gestión de secretos: patrones

8. 1 GitOps + SOPS (snapshot estático)

Git sólo almacena texto cifrado.
Descifrar en CI/CD o en clúster (KMS/age).
Aplicación a través del controlador (Flux/Argo) → Kubernetes Secret.

yaml apiVersion: v1 kind: Secret metadata: { name: psp-keys, namespace: payments }
type: Opaque data:
apiKey: ENC[AES256_GCM,data:...,sops]

8. 2 Vault Agent Injector (emisión dinámica)

La cuenta de servicio (JWT/SA) se autentica en Vault.
Sidecar pone los créditos en tmpfs y actualiza por TTL.
Soporte de créditos dinámicos (DB, cloud - aislamiento y corto plazo).

yaml annotations:
vault. hashicorp. com/agent-inject: "true"
vault. hashicorp. com/role: "payments-api"
vault. hashicorp. com/agent-inject-secret-db: "database/creds/payments"

8. 3 CSI Secrets Store

Fijar el secreto como volumen, la rotación es transparente.
Para PKI, actualización automática de certificados/claves.

9) Kubernetes: aspectos prácticos

ConfigMap - sólo datos públicos/insensibles.
Secret - sensible (con base64 - no cifrado; habilite Encryption at Nat para etcd).
Anotaciones de checksum: restart Deployment cuando se modifica la configuración.
Control Admision: prohibición de montar secretos no de la «lista blanca», prohibición de contraseñas «plain» en los manifiestos.
NetworkPolicy: Restringir el acceso a proveedores de secretos (Vault/CSI).

yaml annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}

10) Políticas de acceso (RBAC/ABAC)

Privilegio Least: el servicio sólo ve sus secretos; acceso por namespace/label/prefix.
Split duties: crear un secreto ≠ leer el contenido; auditar cualquier lectura.
Créditos temporales: Logines dinámicos (DB, cloud) con TTL y rotación automática.
Segmentación: prod/stage en diferentes proyectos/cuentas/claves KMS.

11) Auditoría, registro, observabilidad

Registros de lectura/emisión de secretos: quién/cuándo/qué/dónde; correlación con lanzamientos e incidentes.
Métricas: frecuencia de llamadas, secretos caducados, certificados vencidos, proporción de créditos dinámicos.
Eventos de seguridad: exceso de cuotas, anomalías IP/tiempo, múltiples autenticaciones fallidas.

12) Rotación de secretos y certificados

Estandarice los plazos: las claves API son 90 días, las contraseñas DB son 30 días, los servidores TLS son 60-90 días.
Esquema de rotación: generación → prueba → doble publicación (grace) → cambio → revocación de la antigua verificación →.
Sin problemas: doble registro de confecciones/secretos, compatibilidad con clientes (accept new + old).
PKI: su propia CA o integración con la externa; actualización automática de materiales mTLS a través de CSI/Vault.

13) Confecciones dinámicas y flags de características

Tome los parámetros «calientes» (límites, temporizadores) del servicio de configuración/plataforma de bandera.
Caché local y stickiness (cálculo de variante por hash), TTL cortos.
Los protectores SLO cambian los parámetros sensibles (auto-retroceso y kill-switch).

14) Integración con CI/CD y GitOps

Pre-commit/CI: linternas de circuitos, comprobaciones SOPS, prohibición de secretos «desnudos» (escáneres: gitleaks/trufflehog).
Policy Gate: OPA/Conftest: prohíbe las confecciones sin esquema/sin anotaciones de propietario/sin etiquetas de entorno.
Entrega progresiva: promoción de confecciones como artefactos (semver), canario para cambiar parámetros.
Anotaciones de lanzamientos: quién/qué confiscación/secreto cambió; correlación rápida con p95/5xx.

15) Ejemplos

15. 1 Política de OPA: prohibición de abrir SG en la configuración

rego package policy. config

deny[msg] {
input. kind == "SecurityGroupRule"
input. cidr == "0. 0. 0. 0/0"
input. port = = 5432 msg: = "Postgres open internet banned"
}

15. 2 Ejemplo «snapshot» confit (versionable)

yaml version: 1. 12. 0 owner: payments-team appliesTo: [ "payments-api@prod" ]
http:
timeout_ms: 1200 retry: 2 withdraw:
limits:
per_txn_eur: 5000 per_day_eur: 20000 flags:
new_withdrawal_flow: false

15. 3 Vault - créditos dinámicos DB

hcl path "database/creds/payments" {
capabilities = ["read"]
}
role issues user/password with TTL = 1h and auto-rollover

16) Anti-patrones

Secretos en Git en abierto/en las variables Helm/Ansible sin cifrado.
Un único «mega secreto» para todos los servicios/entornos.
Tokens de larga vida sin TTL/rotación; certificados «inmortales».
Confecciones dinámicas sin esquemas/validación y sin auditoría de cambios.
No Encryption at Nat para etcd/KMS y una red sin mTLS.
Revisiones manuales de las confecciones en venta (eludir GitOps).
Acceso de los desarrolladores a los secretos prod «por si acaso».

17) Lista de verificación de implementación (0-60 días)

0-15 días

Habilitar esquemas/validadores para las configuraciones; crear repos "configurs' y GitOps-stream.
Elevar KMS y cifrado: SOPS/Secrets sellados/Encryption at Nat en etcd.
Prohibir los secretos de reproducción en CI (escáneres), escriba owners/approvals.

16-30 días

Separar repositorios: las confecciones públicas vs sensibles vs secretos.
Implementar Vault/Secrets Manager, seleccionar la ruta de entrega (Agent/CSI/SOPS).
Configurar la rotación de créditos TLS/DB/PSP; dashboards «vida/expiración».

31-60 días

Confecciones dinámicas y banderas con juego de SLO y auto-descarga.
Políticas OPA/Conftest; zero-trust (acceso namespace/label-scoped).
Día de juego: simulación de fuga de secreto y rotación de fuerza.

18) Métricas de madurez

% de los secretos bajo cifrado y sin acceso directo desde Git = 100%.
Cobertura de las confecciones por circuitos/validación ≥ 95%.
Tiempo medio de rotación de secretos críticos (objetivo: horas, no días).
La proporción de créditos dinámicos (DB/cloud) ≥ del 80%.
0 incidentes debidos a "plain secrets'/certificados caducados.
MTTR si se produce un error de configuración con un rebote <5 minutos.

19) Funciones y procesos de equipo

Config Owner: propietario de dominios/esquemas/políticas.
Seguridad: políticas, jerarquía clave, auditoría de acceso.
Plataforma/SRE: GitOps, suministro/inyección, telemetría.
App Teams: consumo de confecciones/secretos, pruebas de compatibilidad.

20) Conclusión

Un circuito fiable de configuraciones y secretos son los circuitos + GitOps + cifrado + rotación + política. Comparta lo público y lo secreto, encripte todo, aplique las confecciones de forma atómica y versionable, minimice los derechos y la vida útil de los créditos, automatice las rotaciones y auditorías. Entonces, los cambios se volverán rápidos y seguros, y el riesgo de fugas y caídas es mínimo.