NexTool Solutions

Vaultwarden es una reimplementación ligera y de código abierto del servidor Bitwarden, escrita en Rust. Habla el mismo protocolo que los clientes oficiales de Bitwarden (extensión de navegador, apps móviles, de escritorio y CLI), pero se ejecuta por completo en tu propia infraestructura - sin depender de la nube de terceros. En NexTool es la pieza que usamos para guardar los secretos de la operación de service desk: contraseñas de servidores, tokens de API, credenciales de acceso a entornos de clientes y bóvedas compartidas por equipo, siempre junto al GLPI que ya mantenemos.

Por qué self-hosted para gestionar secretos de operación

Los equipos de soporte e infraestructura acumulan un problema silencioso: decenas de credenciales críticas dispersas en hojas de cálculo, en el Bitwarden personal de cada técnico, en notas de tickets o - peor - en texto plano dentro del propio ticket. Vaultwarden lo resuelve con una bóveda central, con organizaciones, colecciones y compartición por grupo, manteniendo los datos dentro de tu perímetro. Para un cliente B2B que exige soberanía de datos (RGPD, contratos con cláusula de residencia), el self-hosting no es una preferencia estética: es un requisito.

El consumo es modesto. Al ser Rust y SQLite por defecto, el contenedor suele funcionar con ~128-256 MB de RAM para equipos pequeños y medianos, lo que permite ubicarlo en el mismo host que ya ejecuta GLPI, detrás del mismo proxy inverso, sin aprovisionar una máquina nueva.

Artefacto: docker-compose mínimo con hardening

Este es el esqueleto que usamos como punto de partida. Fíjate en que los registros están desactivados (solo por invitación vía SMTP), el puerto se publica solo en 127.0.0.1 (el proxy inverso expone con TLS) y ADMIN_TOKEN es un hash argon2, nunca la contraseña en claro:

version: "3.8"
services:
  vaultwarden:              # reimplementación en Rust de Bitwarden
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: unless-stopped
    environment:            # variables de hardening
      DOMAIN: "https://vault.suaempresa.com"
      SIGNUPS_ALLOWED: "false"
      INVITATIONS_ALLOWED: "true"
      ADMIN_TOKEN: "$argon2id$v=19$m=65540,t=3,p=4$...hash..."
      SMTP_HOST: "smtp.suaempresa.com"
      SMTP_FROM: "vault@suaempresa.com"
      SMTP_PORT: "587"
      SMTP_SECURITY: "starttls"
      SMTP_USERNAME: "vault@suaempresa.com"
      SMTP_PASSWORD: "${SMTP_PASSWORD}"
    volumes:
      - ./vw-data:/data     # volumen persistente (SQLite + adjuntos)
    ports:
      - "127.0.0.1:8080:80" 

El hash del panel de administración se genera con el propio binario, y el valor en texto plano nunca toca el archivo:

# genera el hash argon2 de ADMIN_TOKEN
docker run --rm -it vaultwarden/server /vaultwarden hash
# Cole o hash resultante em ADMIN_TOKEN (nunca a senha em texto plano)

Vaultwarden self-hosted frente a Bitwarden Cloud

La elección no es ideológica. Depende de quién asume el esfuerzo operativo y de lo sensible que sea el dato:

Para quien no quiere cargar con parcheo, backup y TLS, Bitwarden Cloud es honestamente la respuesta correcta. Para quien ya tiene un equipo de mantenimiento (NexTool, por ejemplo, cuando asumimos el entorno del cliente), el self-hosting compensa.

Paso a paso de despliegue seguro

La rutina que ejecutamos al levantar un Vaultwarden de producción:

1. Proxy inverso con HTTPS. Publicamos el servicio solo en 127.0.0.1 y ponemos delante un proxy inverso (el mismo que sirve GLPI) con certificado válido. Vaultwarden exige HTTPS para que los clientes funcionen.
2. Desactivar registros. SIGNUPS_ALLOWED=false cierra el registro abierto; nadie crea una cuenta por su cuenta. El acceso es siempre por invitación.
3. ADMIN_TOKEN como hash argon2. Generamos el hash con el binario y guardamos solo eso. El panel /admin pasa a exigir ese token, y la contraseña en texto plano nunca queda en el archivo.
4. SMTP para invitaciones y alertas. Configuramos SMTP_* para que las invitaciones de organización y los restablecimientos salgan por correo autenticado del dominio.
5. Backup probado. No basta con copiar el SQLite en caliente. Usamos sqlite3 .backup (consistente con la base en uso) más los adjuntos y la clave RSA, y restauramos en un entorno separado periódicamente.
6. Actualización. La imagen latest cambia rápido; fijamos la versión en producción y actualizamos con ventana y backup fresco antes.

# backup consistente de la base (nunca cp del archivo en caliente)
sqlite3 /srv/vaultwarden/vw-data/db.sqlite3 \
  ".backup '/backup/vaultwarden-$(date +%F).sqlite3'"

# adjuntos + clave RSA (sin ellos la bóveda no abre)
tar czf /backup/vw-attachments-$(date +%F).tgz \
  -C /srv/vaultwarden/vw-data attachments rsa_key config.json

Cómo lo operamos manteniendo clientes GLPI

Al mantener entornos GLPI de clientes, usamos Vaultwarden como bóveda de operación: cada cliente se convierte en una organización, con colecciones separadas por naturaleza (accesos de servidor, credenciales de API, cuentas de portal), y el equipo recibe acceso por grupo, no por contraseña suelta. El error común que hemos visto - incluso antes de estandarizar esto - fue dejar ADMIN_TOKEN en texto plano en el compose y subirlo por accidente; por eso hoy siempre es un hash argon2 y el .env queda fuera del control de versiones. La otra decisión que tomamos fue poner Vaultwarden detrás del mismo proxy inverso que GLPI, en el mismo host, reutilizando TLS, monitorización y la rutina de backup. Y el backup aprendimos a hacerlo bien: un cp del db.sqlite3 en caliente puede capturar la base a mitad de una escritura y generar una restauración corrupta - sqlite3 .backup lo resuelve, y sin la clave rsa_key la bóveda simplemente no abre después. Son detalles que solo aparecen cuando operas, no cuando lees el README.

Preguntas frecuentes

Si mantienes un entorno GLPI y quieres centralizar los secretos de la operación con la ayuda de quien ya lo hace, mira nuestros servicios de infraestructura y cloud o habla con el equipo.

Este contenido se produjo con ayuda de inteligencia artificial y fue revisado por el equipo de Nextool Solutions.