Tema: secrets
-
Se hizo commit de un secreto: por qué no basta con borrar el archivo y cuál es el orden de respuesta
Una credencial subida a un repositorio Git persiste en el historial, en los forks, en los clones, en las cachés y en los registros de CI. Reescribir el historial reduce la exposición futura, pero no puede recuperar las copias ya hechas, así que el primer paso es revocar y rotar la credencial, luego limpiar el historial y después comprobar si se usó.
-
Registro desde scripts de administración: logger y systemd-cat en Linux, Write-EventLog/New-WinEvent y Start-Transcript en Windows
Cada plataforma ofrece una forma de dejar la salida de un script de administración donde una persona u otra herramienta pueda encontrarla después, distinta de escribir en stdout: logger(1) o systemd-cat hacia el registro del sistema en Linux, el Registro de eventos de Windows mediante Write-EventLog (solo Windows PowerShell 5.1) o New-WinEvent, y Start-Transcript para una captura en bruto de la sesión. Ninguno de ellos debe recibir nunca un secreto.
-
Dónde residen las credenciales en una máquina de desarrollo que un proceso agente puede leer
Un agente que se ejecuta como el usuario puede leer lo que el usuario puede leer: variables de entorno, archivos de credenciales de herramientas de línea de comandos, inicios de sesión de registros de contenedores, claves SSH, historial de shell y almacenes cercanos al navegador. Conocer estas ubicaciones permite a quien opera el sistema decidir qué mantener fuera del alcance del agente y qué rotar tras un incidente.
-
ConfigMaps y Secrets en Kubernetes: límites de tamaño, propagación de actualizaciones y lo que un Secret no protege
Tanto los ConfigMaps como los Secrets son objetos clave-valor con un límite de 1 MiB; las claves montadas como volumen se actualizan tras un retraso de sincronización del kubelet, mientras que las variables de entorno nunca lo hacen, los montajes subPath nunca se actualizan, y un Secret solo está codificado en base64 y se almacena sin cifrar en etcd salvo que se configuren el cifrado en reposo y el RBAC.
-
Almacenar secretos para scripts desatendidos: credenciales de systemd, DPAPI, llavero de macOS y qué no hacer
Cada sistema operativo ofrece un mecanismo para entregar un secreto a un script sin usar variables de entorno ni argumentos de línea de comandos, que cualquier proceso coexistente o registro puede leer: LoadCredential= de systemd, DPAPI de Windows mediante Export-Clixml o SecretManagement, y el llavero de macOS con security find-generic-password.
-
Ocultar secretos antes de escribir en los logs
Escriba en el log un registro de diagnóstico basado en una lista de campos permitidos en lugar de las solicitudes de herramientas sin procesar, y verifique que los secretos se ocultan en cada destino de salida.
-
Gestionar secretos fuera del repositorio
Las credenciales deben vivir en una configuración protegida que se inyecta en tiempo de ejecución, nunca en el control de versiones, en las imágenes ni en los logs. Cada servicio recibe credenciales propias y de alcance mínimo, y la rotación es un procedimiento practicado, no una emergencia. Los pasos siguen la hoja de referencia de OWASP sobre gestión de secretos y la separación de configuración y código de Twelve-Factor.
-
La rotación programada de secretos saca a la luz consumidores de credenciales no documentados antes de que lo haga un incidente
Hipótesis: los equipos que rotan según un calendario fijo sus secretos compartidos de larga duración descubren, durante las rotaciones planificadas, los scripts, tareas e integraciones que dependen de ellos de forma silenciosa, de modo que una rotación de emergencia tras una fuga se completa antes y rompe menos que en equipos que solo rotan por sospecha; la hoja de referencia de OWASP recomienda la rotación periódica, pero este beneficio operativo no se ha medido.
Legible por máquina: JSON