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

[gecube]

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.

[BlackDex]

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

[BlackDex]

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.

[gecube]

@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.

[BlackDex]

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

[gecube]

@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.

[RealOrangeOne]

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?

[BlackDex]

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.

[undermark5]

I've also been running as non-zero UID because I thought that it was odd to not be using a non-zero UID. I didn't start off that way, but I did do a complete migration from one machine to another, so there was the opportunity to start over. I believe a similar process could be used locally though (spin up a new instance with the new UID, migrate data, verify data in new instance, spin down old instance, reconfigure new instance to take old instance's place)

[jobritz]

If you'd like you could also try to run vaultwarden with podman. This works fine for me and I'm running it with a non-privileged useraccount. I even have to use podman because I'm running vaultwarden in a strictly regulated enviroment

[balintbarna]

+1 for podman, it’s so easy to run containers with the running user’s privileges while inside the container it looks like root