Deployment vaultwarden (in cluster main) violates 'Process with UID 0' Policy #1856

New Issue

OVERLORD · 2026-02-05T02:02:09+03:00

OVERLORD commented

2026-02-05 02:02:09 +03:00

Originally created by @gecube on GitHub (Feb 16, 2024).

Good day!

I'd like to ask to build a docker image with a non-privileged user. I don't see any reason why we should to use root (uid 0) user for running Vaultwarden service. It is critical when running Vaultwarden in strict and regulated environments.

The change could be breaking in case if Vaultwarden is running inside of k8s pod and stores data in a local file.

Originally created by @gecube on GitHub (Feb 16, 2024). Good day! I'd like to ask to build a docker image with a non-privileged user. I don't see any reason why we should to use root (uid 0) user for running Vaultwarden service. It is critical when running Vaultwarden in strict and regulated environments. The change could be breaking in case if Vaultwarden is running inside of k8s pod and stores data in a local file. <img width="704" alt="Screenshot 2024-02-16 at 11 56 36" src="https://github.com/dani-garcia/vaultwarden/assets/2912732/52f24795-b2ee-405e-9bd7-45c3db566e3a">

OVERLORD closed this issue

2026-02-05 02:02:14 +03:00

OVERLORD commented

2026-02-05 02:02:17 +03:00

@BlackDex commented on GitHub (Feb 16, 2024):

What happens if you change the user and group id in the securityContext of the pod/deployment? And also set runAsNonRoot to true?

@BlackDex commented on GitHub (Feb 16, 2024): What happens if you change the user and group id in the securityContext of the pod/deployment? And also set `runAsNonRoot` to true?

OVERLORD commented

2026-02-05 02:02:19 +03:00

@BlackDex commented on GitHub (Feb 16, 2024):

Also, if we are to change that, it might break a lot of running instances since those are assuming root right now.

Access to these files will break if we would change it in the container.

@BlackDex commented on GitHub (Feb 16, 2024): Also, if we are to change that, it might break a lot of running instances since those are assuming root right now. Access to these files will break if we would change it in the container.

OVERLORD commented

2026-02-05 02:02:21 +03:00

@gecube commented on GitHub (Feb 16, 2024):

@BlackDex I think that it could be a separate image tag like Vaultwarden:1.20-alpine-unprivileged
The very same approach was used by nginx project.

@gecube commented on GitHub (Feb 16, 2024): @BlackDex I think that it could be a separate image tag like `Vaultwarden:1.20-alpine-unprivileged` The very same approach was used by `nginx` project.

OVERLORD commented

2026-02-05 02:02:25 +03:00

@BlackDex commented on GitHub (Feb 16, 2024):

That could be an option. But I'm still curious what happens of you set the right privileges.

@BlackDex commented on GitHub (Feb 16, 2024): That could be an option. But I'm still curious what happens of you set the right privileges.

OVERLORD commented

2026-02-05 02:02:30 +03:00

@gecube commented on GitHub (Feb 16, 2024):

@BlackDex I will check and return to you with updates. It could be solution, but it takes more effort from the user as there are many options.

@gecube commented on GitHub (Feb 16, 2024): @BlackDex I will check and return to you with updates. It could be solution, but it takes more effort from the user as there are many options.

OVERLORD commented

2026-02-05 02:02:34 +03:00

@RealOrangeOne commented on GitHub (Feb 16, 2024):

I've run vaultwarden with a non-default UID since day 1 - works absolutely fine: https://github.com/RealOrangeOne/infrastructure/blob/master/ansible/roles/vaultwarden/files/docker-compose.yml#L7.

I agree migrating is complex, as the container would loose write access to its mounts. But, for a security-focused application, perhaps phasing out root-by-default is a good idea?

@RealOrangeOne commented on GitHub (Feb 16, 2024): I've run vaultwarden with a non-default UID since day 1 - works absolutely fine: https://github.com/RealOrangeOne/infrastructure/blob/master/ansible/roles/vaultwarden/files/docker-compose.yml#L7. I agree migrating is complex, as the container would loose write access to its mounts. But, for a security-focused application, perhaps phasing out root-by-default is a good idea?

OVERLORD commented

2026-02-05 02:02:37 +03:00

@BlackDex commented on GitHub (Feb 16, 2024):

I'm not really fond of adding more tags actually, it will only cause confusion in the end.
There might be an other way to do this in a more nice transitional way.

I'm going to move this to the meta features request #246 and discussions too not clutter the issues.

@BlackDex commented on GitHub (Feb 16, 2024): I'm not really fond of adding more tags actually, it will only cause confusion in the end. There might be an other way to do this in a more nice transitional way. I'm going to move this to the meta features request #246 and discussions too not clutter the issues.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/vaultwarden#1856