Gestión segura de secretos e higiene del entorno

Los secretos —claves de API, contraseñas y tokens— son los datos más sensibles de cualquier sistema. Gestionarlos incorrectamente en scripts de Bash es uno de los errores de seguridad más habituales y dañinos.

• Listados de procesos: los argumentos pasados a los comandos aparecen en ps aux, /proc/<pid>/cmdline y los registros de auditoría del sistema, visibles para todos los usuarios del host.
• Historial del shell: los comandos escritos de forma interactiva (y, en ocasiones, los scripts) se registran en ~/.bash_history.
• Archivos de registro: las trazas de set -x, los registros de la aplicación y la salida de CI/CD pueden capturar valores de variables.
• Fuga a través del entorno: los procesos secundarios heredan todo el entorno de su proceso padre, incluidos los secretos exportados.

Un script reforzado trata los secretos como material radiactivo: minimiza el tiempo de exposición, limita la superficie expuesta y sanitiza todo al salir.

Cuando pasa un secreto como argumento de línea de comandos, cualquier usuario del sistema puede leerlo inmediatamente mediante ps. No es una posibilidad teórica: se explota habitualmente en entornos de hosting compartido y contenedores.

El fragmento siguiente muestra el problema y la solución uno al lado del otro.

El patrón interactivo más seguro consiste en leer un secreto durante la ejecución mediante read -rs. El flag -s suprime el eco para que los caracteres no se muestren nunca, y -r impide interpretar las barras invertidas.

Aspectos clave:

• La variable nunca se exporta, por lo que los procesos secundarios no pueden verla mediante /proc/<pid>/environ.
• Después de usarla, haga unset de la variable inmediatamente para reducir la ventana de exposición.
• Evite echo "$SECRET": use printf '%s' para impedir que un salto de línea final corrompa el valor y para que este permanezca invisible en las trazas.

Cuando un secreto debe persistir en el disco (por ejemplo, una clave de cuenta de servicio), los permisos del archivo son su principal defensa.

• Modo 0600 — solo el propietario puede leerlo y escribirlo. Sin acceso para el grupo ni para otros usuarios.
• Modo 0400 — solo el propietario puede leerlo. Prefiéralo para claves que nunca debería sobrescribir accidentalmente.
• Almacene los archivos secretos en un directorio específico, como ~/.secrets/ o /run/secrets/ (este último es un tmpfs respaldado por RAM en muchos sistemas Linux y solo persiste hasta el reinicio).
• Nunca coloque archivos secretos dentro de un directorio seguido por git sin un .gitignore totalmente confiable.

curl admite un archivo ~/.netrc (o una ruta arbitraria mediante --netrc-file) que asigna nombres de host a credenciales. Esto mantiene los datos de autenticación completamente fuera de la línea de comandos y del cuerpo del script.

El formato del archivo es sencillo:

machine api.example.com
  login admin
  password s3cr3t

Buenas prácticas:

• Establezca siempre chmod 0600 ~/.netrc: en algunos sistemas, curl rechaza el archivo si otros usuarios pueden leerlo.
• Use --netrc-file /run/secrets/netrc para apuntar a un secreto respaldado por tmpfs o inyectado en un contenedor.
• Elimine los archivos netrc temporales con un trap en EXIT.

Las variables de entorno son una forma habitual de inyectar secretos en scripts (aplicaciones de 12 factores y canalizaciones de CI/CD). Sin embargo, se filtran a cada proceso hijo y aparecen en /proc/<pid>/environ durante toda la vida del proceso.

Patrones defensivos:

• Importe el secreto inmediatamente en una variable local y elimine la variable de entorno con unset para impedir que los procesos hijos la hereden.
• Pase los secretos a comandos específicos mediante env -i o una asignación en línea, en lugar de usar todo el entorno heredado.
• Nunca use export con una variable secreta: cuando sea posible, asígnela únicamente (sin export).

set -x (xtrace) es muy útil para depurar, pero imprime en stderr el valor de cada variable que expande, incluidos los secretos. Estos rastreos suelen terminar en registros de CI o en syslog.

Estrategias para proteger los secretos y mantener la utilidad del rastreo:

• Desactive temporalmente el rastreo alrededor de las operaciones sensibles con { set +x; } 2>/dev/null.
• Vuelva a activarlo después con set -x.
• Redirija la salida de xtrace a un descriptor de archivo independiente que apunte a un archivo de registro protegido, no al flujo de registros público.

Incluso si tiene cuidado, a veces los secretos terminan en la salida de registro, especialmente en scripts detallados o heredados. Una función envoltorio de registro que redacte patrones conocidos añade una capa de seguridad.

Este patrón usa un reemplazo basado en expresiones regulares sobre toda la salida de registro. Es una capa de último recurso, no un sustituto de las demás prácticas de higiene ya explicadas.

env -i inicia un comando con un entorno completamente vacío, lo que impide que las variables heredadas, incluidos los secretos accidentales, lleguen al proceso hijo. Después, pasa explícitamente solo lo necesario.

Resulta especialmente útil al ejecutar scripts que no son de confianza, herramientas de compilación o utilidades de terceros que podrían extraer datos del entorno.

tmpfs es un sistema de archivos respaldado por RAM. Los archivos escritos allí nunca se vacían al disco, lo que elimina el riesgo de que los secretos permanezcan en la swap, la caché de disco o las instantáneas.

• En Linux, /dev/shm y /run/user/<uid> suelen ser montajes tmpfs.
• Combine siempre el uso de tmpfs con un trap EXIT para eliminar los archivos cuando termine el script.
• En contenedores (Docker, Kubernetes), los secretos pueden montarse como volúmenes tmpfs directamente en /run/secrets.

El siguiente script combina todas las técnicas de esta lección en un asistente de implementación realista. Observe cómo cada capa de defensa refuerza a las demás:

• Lectura desde stdin con -s: sin mostrar la entrada en el terminal
• Archivo secreto en tmpfs con limpieza mediante trap
• Limpieza del entorno: el secreto se elimina antes de cualquier subproceso
• Protección de xtrace: el rastreo se pausa alrededor del código sensible
• Redacción de registros: una expresión regular de seguridad antes de escribir en el registro

Compruebe su comprensión de cómo se filtran los secretos a través de las listas de procesos y cómo evitarlo.

Ha completado Gestión segura de secretos e higiene del entorno. Este es un resumen conciso de todo lo tratado:

• Listas de procesos: nunca pase secretos como argumentos de la línea de comandos: aparecen en ps aux y /proc/<pid>/cmdline. Use una canalización por stdin o --netrc-file.
• Lecturas desde stdin: use read -rs para recopilar secretos de forma interactiva sin mostrar la entrada en el terminal ni exponerla al historial del shell.
• Permisos de archivos: los archivos secretos deben tener chmod 0600 (o 0400). Use install -m 0600 para una creación atómica.
• Archivos netrc: delegue las credenciales en un archivo temporal indicado mediante --netrc-file; elimínelo con trap EXIT.
• Higiene del entorno: ejecute inmediatamente unset sobre las variables de entorno secretas después de capturarlas localmente; nunca las use con export de forma innecesaria; use env -i para aislar los procesos hijos.
• Protección de xtrace: envuelva el código sensible en { set +x; } 2>/dev/null ... set -x para impedir que los rastreos de depuración filtren valores.
• Redacción de registros: use un registrador basado en sed como red de seguridad de último recurso.
• tmpfs: almacene los secretos de ejecución en /run/user/$UID o /dev/shm para que nunca lleguen al disco; elimínelos de forma segura al salir.

La defensa en profundidad es la mentalidad clave: ninguna medida aislada es suficiente, pero combinarlas dificulta enormemente la filtración de secretos.