Desde que comenzó su carrera en la industria tecnológica en 2018, Yash Patel ha pasado por diferentes etapas. Inicialmente, trabajó como Ingeniero de Software durante más de tres años. Posteriormente, se enfocó en inspirar a sus lectores a través de contenido técnico y entretenido en su blog DiGiTAL BiRYANi. También ha publicado artículos técnicos en MakeTechEasier. Su pasión por las nuevas tecnologías y los gadgets es evidente, y es conocido como El Chef Digital entre sus seguidores debido a su amor por la tecnología y la comida.
El auto-hospedaje con Docker: Un camino hacia la simplicidad y la seguridad
Yash siempre ha valorado la facilidad con la que Docker simplifica el auto-hospedaje. Puede levantar un contenedor, conectarlo a una base de datos, agregar algunos ajustes y tener todo en marcha con pocos comandos. Sin embargo, esta simplicidad también lo llevó a ser negligente con la gestión de información sensible.
El problema con el hard-coding
Al principio, Yash encontró que hard-codear valores en sus archivos docker-compose.yml era la forma más fácil de hacer que todo funcionara. Podía abrir el archivo, ver exactamente lo que cada servicio necesitaba, hacer un cambio rápido y reiniciar el contenedor. No había necesidad de pensar en configuraciones adicionales. Para un auto-hospedaje pequeño, esta comodidad era difícil de ignorar. Si una aplicación necesitaba una contraseña de base de datos, un token de API o otro valor de configuración, podía simplemente agregarlo junto con el resto de los ajustes del servicio y continuar.
La solución: Separar las credenciales
Una vez que decidió dejar de poner secretos directamente en sus archivos docker-compose.yml, se dio cuenta de que tenía varias formas de administrarlos. No necesitaba saltarse un sistema de gestión de secretos complicado. Podía elegir una aproximación basada en cuánta seguridad y complejidad necesitaba su configuración. El paso más simple era mover valores sensibles a un archivo .env separado. En lugar de escribir una contraseña directamente en docker-compose.yml, podía usar algo como ${DB_PASSWORD} y mantener el valor real en .env. También agregó .env a .gitignore para que no se comitiera accidentalmente a un repositorio.
Esto hizo que mis archivos docker-compose.yml fueran más seguros para compartir y mantener, pero había una limitación importante: .env aún es un archivo de texto plano en la máquina. Para credenciales que necesitaban una protección mejor, Docker Secrets ofrecían una opción más fuerte. Compose permite definir un secreto de manera separada y darle a un contenedor acceso a él como un archivo, generalmente bajo /run/secrets/. Esto significa que el secreto no necesita ser pasado como una variable de entorno normal. El desventaja es el soporte de aplicaciones. Algunas aplicaciones solo buscan credenciales en variables de entorno. Si la aplicación soporta la convención _FILE, puedo apuntarla al archivo de secretos montado en su lugar.
Herramientas externas para secretos
Para configuraciones que han crecido más allá de un puñado de contenedores, también existen herramientas externas de gestión de secretos. Herramientas como HashiCorp Vault, SOPS con age, Infisical y Doppler pueden mantener secretos centralizados y proporcionar más control sobre cómo se almacenan y se acceden. Para mi configuración, encontré que era importante no complicarme la vida. Un archivo .env era suficiente para algunos servicios, mientras que Docker Secrets hacían más sentido para credenciales que quería proteger con más cuidado.
Conclusión: Un cambio pequeño, un gran impacto
Al separar las credenciales de mis archivos docker-compose.yml, solucioné un problema, pero también me hizo más consciente de algunos errores fáciles de cometer con Docker. Ahora evito poner credenciales directamente en un Dockerfile. Cualquier cosa incorporada en una imagen puede quedar atrapada en sus capas, lo que dificulta eliminarla completamente más tarde. Lo mismo se aplica a valores de entorno o archivos de configuración copiados en una imagen durante la construcción. También deje de reutilizar la misma contraseña en múltiples servicios. Si una aplicación es comprometida, no quiero que esa única credencial proporcione acceso a todo lo demás que esté ejecutando en mi servidor. Usar credenciales únicas limita el daño cuando algo sale mal.
Finalmente, siempre cambio los nombres de usuario y las contraseñas por defecto cuando despliego una nueva aplicación. Dejar las credenciales proporcionadas por el desarrollador es un riesgo innecesario, especialmente para servicios que podrían volverse accesibles desde fuera de mi red.
En resumen, la seguridad de mi auto-hospedaje no significa lidiar con herramientas complicadas y configuraciones interminables. Este cambio mostró que la mejor seguridad puede comenzar con algo mucho más pequeño. Una vez que comencé a tratar la información sensible de manera diferente a la configuración regular, el manejo de mis contenedores se volvió más intencional. También cambió cómo pienso en los otros servicios que ejecuto en mi servidor. No necesito hacer todo complicado solo por la seguridad. Solo necesito evitar las short-cuts que pueden crear problemas más tarde. Para mí, separar las credenciales fue una de esas pequeñas modificaciones que hicieron que todo el setup se sintiera más maduro.
💡 La Opinión de ExploxTV
La seguridad en un auto-hospedaje no tiene por qué ser un proceso complicado. El cambio que hizo Yash demuestra que incluso pequeños ajustes pueden tener un gran impacto. Al separar las credenciales de los archivos de configuración, se aseguró de que su setup sea más seguro y manejable. Este enfoque no solo mejora la seguridad, sino que también promueve mejores prácticas de desarrollo y gestión de secretos.