Módulo 9 · 9.4

Español

Nederlands English Deutsch Français Español Italiano Polski

Recetas: Uptime Kuma y Vaultwarden

Módulo 9: Docker y docker compose · Tiempo de lectura: 13 minutos

Objetivo de aprendizaje: Después de esta lección, sabrá ejecutar Uptime Kuma y Vaultwarden con docker compose detrás de Caddy, con https, el registro cerrado, copia de seguridad de los volúmenes y un procedimiento fijo de actualización.

Conceptos clave: contenedor de proxy inverso, Caddyfile, https automático, Uptime Kuma, Vaultwarden, DOMAIN, SIGNUPS_ALLOWED, ADMIN_TOKEN, Argon2, .env, websockets, copia de seguridad de volúmenes, docker compose pull, cabecera propia

Qué vamos a montar

Dos servicios prácticos en su propio servidor, cada uno en su propio subdominio:

Uptime Kuma en status.example.com: un programa de monitorización con interfaz web que vigila sus sitios web, puertos y certificados, y le envía un aviso cuando algo falla (lección 8.3). Atención: una monitorización que se ejecuta en el mismo servidor que lo que vigila no detecta que ese servidor entero se cae. Úsela, por tanto, para sus otros sitios y servicios, o instálela en un segundo servidor.
Vaultwarden en kluis.example.com: una versión de servidor ligera e independiente que funciona con las aplicaciones y extensiones de navegador de Bitwarden. Una bóveda de contraseñas es software delicado: hágalo solo si está dispuesto a mantenerla al día y a hacer copias de seguridad. También es perfectamente válido usar un gestor de contraseñas de un proveedor.

Delante colocamos Caddy en un contenedor: atiende los puertos 80 y 443, gestiona por sí mismo los certificados de Let's Encrypt (lecciones 7.3 y 7.4) y reenvía el tráfico al contenedor correcto. Uptime Kuma y Vaultwarden no publican puertos propios (lección 9.3).

internet ──443──> caddy ──> uptime-kuma:3001
                        └─> vaultwarden:80

Requisitos previos

Docker Engine con el plugin de compose (lección 9.2).
Dos registros DNS que apunten a su servidor, A y AAAA (lección 7.1): status.example.com y kluis.example.com.
Los puertos 80 y 443 libres en el servidor. Si ya hay un nginx o un Caddy del sistema usando esos puertos, el contenedor de Caddy no podrá utilizarlos. En ese caso, elija: o detiene el servidor web del sistema, o deja que este haga de proxy y publica los contenedores en 127.0.0.1 (lección 9.3). En esta receta lo hace el contenedor de Caddy.
En ufw, abra 80/tcp, 443/tcp y, para HTTP/3, también 443/udp (lección 5.2). En sentido estricto, Docker se salta ufw, pero así la vista de su firewall coincide con la realidad.

Los archivos

Todo va en una sola carpeta, /srv/diensten/:

/srv/diensten/
├── compose.yaml
├── Caddyfile
└── .env

compose.yaml

services:
  caddy:
    image: caddy:2
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
      - "443:443/udp"
    volumes:
      - ./Caddyfile:/etc/caddy/Caddyfile:ro
      - caddy-data:/data
      - caddy-config:/config

  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    volumes:
      - uptime-kuma:/app/data

  vaultwarden:
    image: vaultwarden/server:1.37.5
    restart: unless-stopped
    environment:
      DOMAIN: "https://kluis.example.com"
      SIGNUPS_ALLOWED: "true"
      ADMIN_TOKEN: ${VW_ADMIN_TOKEN}
    volumes:
      - ./vw-data:/data

volumes:
  caddy-data:
  caddy-config:
  uptime-kuma:

Antes de empezar, compruebe cuál es la versión más reciente de Vaultwarden (las releases en GitHub) e indíquela en la etiqueta. Solo Caddy publica puertos, y estos deben ser públicos. Los volúmenes caddy-data (certificados), uptime-kuma y la carpeta vw-data contienen todo lo que debe conservar.

Caddyfile

{
	email beheer@example.com
}

status.example.com {
	reverse_proxy uptime-kuma:3001
	header {
		X-Weboke-Cursus "jouw-code-uit-de-opdracht"
		defer
	}
}

kluis.example.com {
	reverse_proxy vaultwarden:80
}

Caddy obtiene automáticamente un certificado para ambos nombres y redirige http a https. uptime-kuma y vaultwarden son los nombres de servicio del archivo compose: Caddy los encuentra en la red interna. El bloque header añade una cabecera adicional a cada respuesta de status.example.com; la usará en el ejercicio como prueba de que su contenedor de proxy está en marcha. Con defer, la cabecera se añade después de que el servicio de detrás haya dado su respuesta. Si también quiere HSTS y las demás cabeceras de seguridad de la lección 7.4, póngalas en el mismo bloque.

Configurar Vaultwarden de forma segura

Cuatro cosas marcan la diferencia entre una bóveda segura y una peligrosa.

Uno: solo a través de https. La bóveda web de Bitwarden utiliza la criptografía del navegador, y los navegadores solo la ponen a disposición en páginas https. Sin https, por tanto, no funciona bien, y es mejor así. La documentación de Vaultwarden recomienda un proxy inverso para https, como Caddy aquí. Ponga DOMAIN con la dirección https completa.

Dos: registro cerrado. Con SIGNUPS_ALLOWED: "true", cualquiera que encuentre la página puede crear una cuenta en su servidor. Por eso: arranque, cree enseguida su(s) propia(s) cuenta(s), cambie el valor a "false" y vuelva a ejecutar docker compose up -d. Si más adelante quiere añadir a alguien, utilice la función de invitación de la página de administración.

Tres: un token de administración con hash. La página de administración (/admin) está protegida con ADMIN_TOKEN. No ponga ahí una contraseña legible, sino un hash Argon2. Lo genera con el propio Vaultwarden:

anna@web1:/srv/diensten$ sudo docker compose exec vaultwarden /vaultwarden hash
Password:
Confirm Password:

ADMIN_TOKEN='$argon2id$v=19$m=65540,t=3,p=4$...'

Ponga esa línea en .env (es decir, VW_ADMIN_TOKEN='$argon2id$...', con comillas simples) y haga que el archivo solo sea legible por root: sudo chmod 600 .env. En un archivo .env no hace falta duplicar los caracteres $; si pone el hash directamente bajo environment: en el archivo compose, sí (cada $ se convierte en $$), porque de lo contrario Compose intenta sustituirlos como variables. Para iniciar sesión en /admin se usa la contraseña que escribió, no el hash. Atención: los ajustes que guarde en la página de administración se almacenan en vw-data/config.json y entonces tienen prioridad sobre las variables de entorno.

Cuatro: copia de seguridad y restauración. Todo está en vw-data: la base de datos, los adjuntos y las claves. Incluya esa carpeta en su copia de seguridad con restic (lección 8.2) y, para la base de datos, siga las indicaciones de copia de seguridad de la wiki de Vaultwarden, para no copiar un archivo escrito a medias. Pruebe la restauración (ejercicio O8.2): una bóveda sin una copia de seguridad que funcione es un riesgo para todas sus contraseñas.

Las notificaciones entre dispositivos (websockets) funcionan en las versiones recientes de Vaultwarden por el mismo puerto; Caddy las transmite sin ninguna configuración adicional.

Configurar Uptime Kuma

Después de docker compose up -d, abra https://status.example.com. En la primera visita, Uptime Kuma le pide crear una cuenta de administrador. Hágalo de inmediato: mientras esa cuenta no exista, cualquiera que encuentre la página puede crearla. Si no quiere correr ese riesgo en absoluto, quite primero el bloque status del Caddyfile, cree la cuenta a través de un túnel SSH (lección 2.3) y vuelva a poner el bloque después.

A continuación, añada monitores: un monitor HTTP para su sitio web, un monitor TCP para un puerto, un aviso de certificado y un canal de notificación (correo, un programa de chat o un servicio push). Active también la verificación en dos pasos en los ajustes de Uptime Kuma.

Arrancar y comprobar

anna@web1:/srv/diensten$ sudo docker compose up -d
anna@web1:/srv/diensten$ sudo docker compose ps
NAME                     SERVICE       STATUS          PORTS
diensten-caddy-1         caddy         Up 2 minutes    0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, ...
diensten-uptime-kuma-1   uptime-kuma   Up 2 minutes (healthy)
diensten-vaultwarden-1   vaultwarden   Up 2 minutes (healthy)
anna@web1:/srv/diensten$ sudo docker compose logs caddy | grep -i "certificate obtained"
anna@web1:~$ curl -sI https://status.example.com | grep -i x-weboke
x-weboke-cursus: jouw-code-uit-de-opdracht

Solo Caddy tiene puertos. Si el certificado no se obtiene, los registros de Caddy indican por qué: normalmente el DNS todavía no apunta al servidor, o el puerto 80 no es accesible (lección 7.3).

Actualizar

unattended-upgrades no actualiza los contenedores (lección 4.2). Fije un momento para hacerlo, por ejemplo cada dos semanas:

anna@web1:/srv/diensten$ sudo docker compose pull
anna@web1:/srv/diensten$ sudo docker compose up -d
anna@web1:/srv/diensten$ sudo docker image prune

pull descarga las imágenes más recientes dentro de la etiqueta que haya elegido (así, caddy:2 se mantiene en la versión 2). Para Vaultwarden con un número de versión, primero cambie la etiqueta tras leer las notas de la versión. Ante una nueva versión principal, lea siempre las notas de la versión: a veces hay que cambiar algo en su configuración. Antes de una actualización importante, haga una copia de seguridad de los volúmenes.

Siga también los avisos de seguridad de los desarrolladores. Una vulnerabilidad en Vaultwarden o en Caddy solo se corrige si usted descarga la nueva versión.

En la práctica

Esta receta funciona en cualquier VPS con Docker, en WebOké o en otro proveedor. Es autoservicio: el proveedor de su VPS no gestiona nada dentro de sus contenedores. Haga una instantánea antes de montarlo por primera vez; así podrá experimentar con tranquilidad.

Resumen

Un solo archivo compose con Caddy como contenedor de proxy inverso; solo Caddy publica los puertos 80 y 443, los servicios ninguno.
Caddy gestiona los certificados y https automáticamente y puede añadir cabeceras propias con header.
Vaultwarden: https obligatorio, DOMAIN con la dirección https, registro cerrado tras crear su propia cuenta, ADMIN_TOKEN como hash Argon2 en un .env con permisos 600.
Uptime Kuma: crear de inmediato la cuenta de administrador y activar la verificación en dos pasos; úselo sobre todo para vigilar otros servidores y sitios.
Haga copia de seguridad de los volúmenes y de la carpeta vw-data, y actualice con docker compose pull y up -d en un momento fijo.

Cuestionario

Ejercicio

Ejercicio Z9.4: Demuestre que su contenedor está en marcha. Obtenga su código personal en el ejercicio y póngalo en el Caddyfile de su contenedor de Caddy como cabecera X-Weboke-Cursus para un subdominio suyo (como status.<jouwdomein>). Recargue Caddy e introduzca el nombre de host. El programa descarga https://<hostnaam>/ y comprueba que el certificado es válido y que la cabecera contiene exactamente su código. Además, pegue la salida de docker compose ps e indique qué servicio es el único que publica puertos.

Para saber más

Gestor de contraseñas y claves de acceso (passkeys): así organiza sus inicios de sesión de forma segura
Uptime Kuma (instalación con Docker): https://github.com/louislam/uptime-kuma
Wiki de Vaultwarden, Using Docker Compose: https://github.com/dani-garcia/vaultwarden/wiki/Using-Docker-Compose
Wiki de Vaultwarden, Enabling admin page: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page
Wiki de Vaultwarden, Enabling HTTPS: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-HTTPS
Documentación de Caddy, header: https://caddyserver.com/docs/caddyfile/directives/header

Cookies en WebOké

Ajustes de cookies

Necesarias

Marketing