Vaultwarden behind Traefik

[blackneil]

I'm implementing Traefik and integrating Vaultwarden (latest) behind to test.

Everything works correctly (adding, modifying, and attaching files), but I can't download them. Same problem with the web interface and the Windows client. No issue without Traefik.

I've checked the logs (always respond 200) and tried different configurations, without success.

Has anyone else encountered this problem and have found a solution?

Thanks in advance for your help!

[schymans]

I am also trying to set up vaultwarden behind traefik. Would you be able to share your setup so that I could reproduce it on my server? Perhaps I will encounter the same problem, then.

[schymans]

The contents of the compose.yaml files for the static and dynamic traefik config and for vaultwarden would be great. I found snippets that need to be implemented here and there, but an example of a functioning configuration would be great.

[blackneil]

Please note, I started with my own compositions a few weeks ago. I'm trying to follow "best practices", so it's probably not super compliant but it works. Be nice or not to hard.

I changed the domain names and IP ranges. Currently Vaultwarden is hosted on a NAS and I wrote a similar composition (it didn't exist before). I implemented Bitwarden RS a long time ago and have been following the updates.

The project is a bit bigger than just putting Vaultwarden behind Traefik but it's the first step.

I share the complete project as is.
config_dyn.txt
proxy-compose.txt
traefik.txt
vault-compose.txt

[blackneil]

I come to update Traefik to 3.7.12 and it's working (bug fix or my mistake ?). Also behind authentik but for the client we need to set the unauthenticated paths:

^/api(/.*)?$
^/wl(/.*)?$ --> Not seen in logs (?)
^/identity(/.*)?$
^/images(/.*)?$
^/attachments(/.*)?$ --> probably a bad idea
^/icons(/.*)?$ --> Very bad idea (path can be tested, this can return the favicon from internal fqdn)

[schymans]

@blackneil Thanks for sharing your setup! I am wondering about the following lines in your proxy-compose.txt:

      - traefik.http.routers.exemple-com.tls.domains[0].main=*.exemple.com
      - traefik.http.routers.exemple-com.tls.domains[0].sans=exemple.com
      - traefik.http.routers.exemple-net.tls.certresolver=plskcloud
      - traefik.http.routers.exemple-net.tls.domains[0].main=*.exemple.net
      - traefik.http.routers.exemple-net.tls.domains[0].sans=exemple.net

Normally, I have seen it in the opposite way, sans being the wildcard domain and main being the base domain. Is there a reason you did it this way, or do both work?

[blackneil]

When I buy a wildcard the request (CN) is for *.exemple.com and the root is also covered and for the display.

Also if you by a certificate for vault.exemple.com, you catch a cover for www.vault.exemple.com. I come to realise, it wasn't the case for the last buyed certificate. Thanks !

The both work.

[schewara]

Here's my config which is running stable for quite a while now (including attachments), so I hope it helps.

traefik config is pretty much standard with the docker provider and the docker socket mounted in (no proxy), no extra authentication hooked into it and using the ingress network to talk to vaultwarden.

vaultwarden compose file is also no thrills and the config through ENV Vars.

The only Vars worth mentioning here are:

• ROCKET_PORT=8080
• WEBSOCKET_ENABLED=true
• DOMAIN=https://vaultwarden.example.com (traefik entrypoint is listen directly on port 443)

services:
  vaultwarden:
    container_name: vaultwarden
    hostname: vaultwarden
    networks:
      - ingress
      - vaultwarden-network  # database
    image: vaultwarden/server:1.37.2  # no latest, no surprises
    volumes:
      - type: bind
        source: /path/to/vaultwarden/data
        target: /data
      - type: bind
        source: /path/to/vaultwarden/conf/vaultwarden.env
        target: /.env
        read_only: true
    user: 1080:1080  # don't remember why I actually set this
    expose:
      - 8080
    labels:
      - traefik.enable=true
      - traefik.docker.network=ingress
      - traefik.http.services.vaultwarden.loadbalancer.server.port=8080
      - traefik.http.routers.vaultwarden.entrypoints=https
      - traefik.http.routers.vaultwarden.rule=Host(`vaultwarden.example.com`)
      - traefik.http.routers.vaultwarden.service=vaultwarden

If I would add OIDC/SSO Auth to Vaultwarden, I would activate the builtin feature instead of trying to work around specific paths on the traefik side, which seems very brittle and error prone.
From a security point of view, there should be no real difference besides the reduced complexity.

[blackneil]

Thanks for your share! It's help full for my next migration and learning.

After more test, I have found the env. var. "DOMAIN" have an impact only on the attachement download. During the deployement of the proxy's, I updated my host file to redirect the traffic without breaking the service. When the "DOMAIN" is configured correctly, no issue behind Traefik.

My goal is to protect the access with MFA to different system and centralise the access.

WEBSOCKET_ENABLED=true    # normally it's no more needed except maybe with db other than SQLite (your case)

image: vaultwarden/server:1.37.2  # no latest, no surprises (you right)

But authentik didn't support rollback (db upgrade), so it's quicker to update after a backup.

user: 1080:1080  # don't remember why I actually set this (probably to do a backup without root access)

I thing, I have read somewhere here, the OIDC for Vaultwarden aren't marked as stable. I have try and I had errors (it's not a priority). In the meen time it's probaly not supported by the client apps.

[breeegz]

I tried to get OIDC/SSO working on Vaultwarden via Traefik & Authentik, but I was getting some errors. I am watching #7127 since this seems that it describes my issue very closely. I plan on retesting after this issue is merged (or changelog addresses something similar). Maybe it's related to your errors too.

[blackneil]

I tried to yesterday with this configuration:
proxy-compose.txt
config_dyn.txt
traefik.txt

At the end I'm stopped by: /identity/connect/token POST 400 Bad request

I have also 4 rows inside the table "sso_auth" with the field "code_response_error" at "null" for the 4. The table "sso_users" are empty.

After that it's out of my expertise.

During your test have you implemented:

cap_drop:
  - ALL
cap_add:
  - ?

For Traefik, PostgreSQL & Authentik Server ?