DOCKER - VAULTWARDEN

🔐🐳 Gestor de contraseñas: Vaultwarden, HTTPS y Docker

En esta práctica se levanta un gestor de contraseñas propio con Vaultwarden, la reimplementación en Rust del servidor de Bitwarden, desplegado en un único contenedor Docker con HTTPS servido por el propio Vaultwarden mediante un certificado autofirmado, todo con Docker Compose.

El escenario parte de una necesidad habitual en cualquier equipo u organización: disponer de una bóveda de contraseñas propia, cifrada y auditable, sin depender de un gestor en la nube de terceros ni de contraseñas repartidas entre navegadores, notas sueltas y hojas de cálculo. A diferencia de otras soluciones que exigen delegar la custodia de las credenciales en un proveedor externo, Vaultwarden resuelve todo con sus propias cuentas locales, gestionadas directamente por quien administra el servidor. El reto técnico principal no está en levantar el servidor en sí, sino en dejarlo accesible con HTTPS —requisito indispensable para que el navegador permita el cifrado del vault— sin depender de un dominio público.

🧰 Tecnologías empleadas

Docker y Docker Compose Motor de contenedores que aloja Vaultwarden como servicio único, con la configuración sensible separada en un archivo .env y los datos persistidos en un volumen fuera del propio contenedor.

Vaultwarden Reimplementación en Rust, ligera y compatible, de la API de servidor de Bitwarden. Permite usar los clientes oficiales de Bitwarden (navegador, móvil, escritorio) contra un servidor propio, sin depender de la nube de Bitwarden.

Argon2 (vaultwarden hash) Utilidad incluida en la propia imagen para generar el ADMIN_TOKEN como hash, en vez de guardar la contraseña del panel /admin en texto plano dentro del .env.

HTTPS integrado (ROCKET_TLS) El vault web exige un contexto seguro del navegador, igual que le ocurre a otros clientes web modernos; Vaultwarden puede servir ese HTTPS él mismo, sin necesitar un proxy inverso independiente.

Certificado autofirmado (OpenSSL) Certificado HTTPS generado localmente para la IP del propio servidor, sin depender de una autoridad de certificación pública ni de un dominio, adecuado para un despliegue interno.

🎯 Objetivos de la práctica

El objetivo principal es demostrar que se puede levantar un gestor de contraseñas propio y funcional en poco tiempo, sin depender de ningún proveedor externo ni de un dominio público, cumpliendo aun así los requisitos de seguridad que exige cualquier navegador moderno para manejar credenciales cifradas.

De forma más concreta, se busca desplegar Vaultwarden con Docker Compose, generar un certificado autofirmado válido para la IP del servidor y activarlo directamente en el propio contenedor, generar el token de administración con Argon2, crear la cuenta de usuario necesaria sin dejar el registro público abierto, y validar el acceso completo desde el navegador.

🧩 Desarrollo de la práctica

Levantar el contenedor con Docker Se define el despliegue de Vaultwarden en Docker Compose, con la configuración sensible aislada en un archivo .env independiente.

Generar el certificado autofirmado Se genera con OpenSSL un certificado HTTPS válido para la IP del servidor, y se monta como volumen para que Vaultwarden lo sirva directamente, sin proxy inverso de por medio.

Generar el token de administración Se usa la utilidad vaultwarden hash para convertir la contraseña elegida en un hash Argon2, y se guarda ese hash —nunca la contraseña en claro— como ADMIN_TOKEN.

Arrancar el stack y verificar Se levanta el contenedor con docker compose up -d y se revisan los logs hasta confirmar que sirve correctamente por HTTPS.

Crear la cuenta de usuario Se registra la cuenta necesaria desde el propio cliente web, se confirma que la bóveda carga y guarda una entrada de prueba, y se cierra el registro público en cuanto existe esa cuenta.

Verificación de extremo a extremo Se inicia sesión desde el navegador, aceptando el aviso de certificado autofirmado, y se confirma que la bóveda guarda y recupera entradas correctamente, con el SSO permaneciendo explícitamente desactivado en esta fase.

🔍 ¿Por qué es importante esta práctica?

Disponer de un gestor de contraseñas propio, en vez de depender de un proveedor en la nube de terceros o de contraseñas sueltas sin cifrar, da control total sobre dónde vive la información y quién tiene acceso a ella. Un despliegue sólido desde el primer día —panel de administración protegido con un token que no viaja en texto plano, registro de usuarios cerrado en cuanto deja de ser necesario— es lo que separa un servicio realmente seguro de una fachada bonita por encima de fundamentos frágiles.

Además, el reto de servir HTTPS sin un dominio público es una situación extremadamente habitual en cualquier despliegue interno real: la solución de un certificado autofirmado servido por el propio Vaultwarden no es una chapuza temporal, sino el mismo patrón que se usa en la mayoría de las organizaciones para sus servicios internos antes de contar con un certificado emitido por una entidad pública.

✅ Resultados esperados

Al finalizar la práctica, Vaultwarden desplegado en Docker gestiona una bóveda de contraseñas cifrada y accesible de forma directa por la IP del servidor, con el registro público cerrado y el panel de administración protegido con un token Argon2, sin depender de ningún proveedor externo ni de un dominio público. El SSO queda deliberadamente fuera del alcance de esta práctica, con la base ya preparada para añadirlo después.

🏢 Propuesta empresarial

Clockwork Computer necesita dejar de depender de contraseñas repartidas entre navegadores, notas sueltas y hojas de cálculo sin cifrar, sin recurrir a ningún gestor en la nube de terceros. El departamento de IT ha decidido desplegar Vaultwarden como gestor de contraseñas propio, aprovechando Docker para todo el despliegue, de forma que la bóveda y el control de acceso queden bajo control directo de la organización.

📌 Escenario propuesto

Clockwork Computer dispone de un servidor con Docker donde levantar su gestor de contraseñas interno. El objetivo es que el servicio sea accesible desde cualquier equipo de la red interna, sin depender de un dominio público ni de un proveedor externo, y con la posibilidad de ampliar en el futuro hacia un dominio propio y SSO corporativo si el servicio necesita salir fuera de la red local.

🎯 Requisitos técnicos solicitados por la empresa

La empresa solicita implementar las siguientes tareas: desplegar Vaultwarden en Docker, con los datos persistidos en un volumen y la configuración sensible separada en un .env; servir el acceso con HTTPS, aunque sea con un certificado autofirmado, para que el cliente web funcione correctamente en cualquier navegador moderno; generar el token de administración con Argon2 en vez de una contraseña en texto plano; crear la cuenta de usuario necesaria y cerrar el registro público en cuanto exista; y dejar el despliegue preparado para ampliarse en el futuro con un dominio propio, un certificado válido y SSO corporativo, sin tener que rediseñar el montaje actual.

🔐 Justificación técnica y de seguridad

Clockwork Computer necesita evitar que sus contraseñas dependan de un proveedor externo o queden expuestas en texto plano en notas y hojas de cálculo. Servir el vault bajo HTTPS, aunque sea con un certificado autofirmado mientras no exista un dominio público, es indispensable para que el navegador permita el cifrado completo de la bóveda, y sienta además la base para migrar sin fricciones a un certificado válido el día que el servicio deba ser accesible desde fuera de la red interna.

Generar el ADMIN_TOKEN con vaultwarden hash evita que la contraseña del panel de administración quede guardada en texto plano en el .env: lo que se almacena es un hash Argon2, no reversible, de forma que aunque ese archivo se filtrase, la contraseña real seguiría a salvo. Cerrar el registro público en cuanto exista la cuenta necesaria evita que cualquiera con acceso a la red interna pueda darse de alta por su cuenta en el servidor.

🧪 Validación esperada

Al finalizar la práctica, Clockwork Computer deberá comprobar que la cuenta creada por el administrador puede iniciar sesión y guardar entradas en la bóveda de forma cifrada, que el panel /admin solo es accesible con la contraseña usada para generar el token, y que el registro público queda cerrado una vez completadas las pruebas, sin que en ningún momento haya sido necesario un proveedor externo ni un dominio público.

✅ Resultado empresarial esperado

Como resultado final, Clockwork Computer dispondrá de un gestor de contraseñas propio, completamente autocontenido, con la bóveda y el control de acceso bajo su propio control, accesible de forma directa desde cualquier equipo de la red. El servicio quedará preparado para escalar en el futuro hacia un dominio propio, un certificado público y SSO corporativo, sin depender en ningún momento de un proveedor externo de identidad ni de almacenamiento.

🔗 Enlaces de interés

DOCUMENTACIÓN