Por qué los secretos no deberían vivir en variables de entorno

Un artículo de opinión cuestiona la práctica habitual de pasar secretos mediante variables de entorno y defiende cargarlos directamente desde una configuración estructurada dentro del propio código de la aplicación.

El primer argumento del autor es la coherencia: mezclar archivos de configuración ini/yaml/json con variables de entorno separadas (algo frecuente en configuraciones Docker, repartidas entre archivos compose y archivos .env) genera una configuración fragmentada y propensa a errores.

En segundo lugar, cargar los secretos desde dentro de la aplicación evita las rarezas de inyección propias de ciertas plataformas. El autor recuerda un trabajo anterior en el que los secretos se obtenían en tiempo de ejecución desde S3 mientras la aplicación corría en AWS ECS, porque definirlos como variables de entorno allí corría el riesgo de filtrarlos a través de la consola de ECS.

En tercer lugar, al autor no le preocupa demasiado guardar secretos en disco, ya que siempre usa cifrado completo del disco, reforzado con encfs/gocryptfs cuando eso no basta. Si un atacante lograra sortear ambas capas, toda la máquina ya estaría comprometida de todos modos, por lo que las variables de entorno tampoco ofrecerían más seguridad.

Por último, para aplicaciones con estructuras de datos profundas y complejas, el autor encuentra que JSON/YAML resulta mucho más manejable que las variables de entorno planas.