El hueco
LogHelper::SENSITIVE_KEYS no incluye private_key:
# lib/docker_swarm/log_helper.rb:9
SENSITIVE_KEYS = /password|pass|passwd|secret|token|api_key|auth|\bdata\b/i.freeze
Consecuencia: una clave privada pasada como PRIVATE_KEY=-----BEGIN… en el Env de un
ContainerSpec se loguea en claro — mismo camino que arreglaba #23: request_success, nivel
INFO, camino feliz, en cada create/update de service.
El fix de #23 (PR #28) cerró el caso general de los strings "CLAVE=VALOR" — antes ni siquiera se
parseaban — pero la redacción sigue decidiéndose por SENSITIVE_KEYS, y private_key no matchea
ninguno de sus términos.
No es un descubrimiento nuevo: está declarado
El propio CHANGELOG.md de 0.9.0 lo deja escrito, y hay un spec que lo fija como comportamiento
conocido:
Hueco declarado, no cubierto por este fix: private_key no está en SENSITIVE_KEYS, así
que un PEM con ese nombre sigue saliendo en claro (hay un spec que lo fija como comportamiento
conocido). Ampliar la lista va aparte: cambia la redacción para todos los consumidores.
Este issue es ese "va aparte". Se abre porque el hueco quedó documentado pero sin ticket —
declarado y sin dueño es la peor combinación para algo que filtra secretos.
Qué hay que hacer
- Agregar
private_key (y evaluar \bkey\b, certificate, cert, credential) a
SENSITIVE_KEYS.
- Invertir el spec que hoy fija el comportamiento conocido: pasa a verificar que el PEM se
redacta.
- Decidir el alcance del término:
\bkey\b pelado es tentador pero redactaría claves benignas
(ROUTING_KEY, IDEMPOTENCY_KEY) y ensucia el diagnóstico. Preferible enumerar.
Por qué va aparte y no colado en otro PR
Cambia la redacción para todos los consumidores de la gema. Un valor que hoy sale en los logs
—y que alguien puede estar grepeando— pasa a salir [FILTERED]. Merece su propia entrada de
CHANGELOG y su propio bump, no viajar escondido en un PR de otra cosa.
Contexto
El hueco
LogHelper::SENSITIVE_KEYSno incluyeprivate_key:Consecuencia: una clave privada pasada como
PRIVATE_KEY=-----BEGIN…en elEnvde unContainerSpecse loguea en claro — mismo camino que arreglaba #23:request_success, nivelINFO, camino feliz, en cada create/update de service.El fix de #23 (PR #28) cerró el caso general de los strings
"CLAVE=VALOR"— antes ni siquiera separseaban — pero la redacción sigue decidiéndose por
SENSITIVE_KEYS, yprivate_keyno matcheaninguno de sus términos.
No es un descubrimiento nuevo: está declarado
El propio
CHANGELOG.mdde0.9.0lo deja escrito, y hay un spec que lo fija como comportamientoconocido:
Este issue es ese "va aparte". Se abre porque el hueco quedó documentado pero sin ticket —
declarado y sin dueño es la peor combinación para algo que filtra secretos.
Qué hay que hacer
private_key(y evaluar\bkey\b,certificate,cert,credential) aSENSITIVE_KEYS.redacta.
\bkey\bpelado es tentador pero redactaría claves benignas(
ROUTING_KEY,IDEMPOTENCY_KEY) y ensucia el diagnóstico. Preferible enumerar.Por qué va aparte y no colado en otro PR
Cambia la redacción para todos los consumidores de la gema. Un valor que hoy sale en los logs
—y que alguien puede estar grepeando— pasa a salir
[FILTERED]. Merece su propia entrada deCHANGELOG y su propio bump, no viajar escondido en un PR de otra cosa.
Contexto
CHANGELOG.md§[0.9.0]→### Seguridad.E-ACS-MIGRATION-001(migración del ACS legacy al stack Swarm).