[LiTe1991]

What Changed
The container was migrated from the standard nginx:stable image to nginxinc/nginx-unprivileged:stable, which runs the Nginx worker processes as a non-root user (UID 101 / nginx) instead of as root. The following adjustments were made to support this:

Base image: nginx:stable → nginxinc/nginx-unprivileged:stable
Port: EXPOSE 80 → EXPOSE 8080 (the unprivileged image binds to high ports by default)
Nginx config: listen 80 → listen 8080, plus pid /tmp/nginx.pid and error_log /dev/stderr so Nginx writes only to locations writable by the non-root user
User context: The container explicitly runs as the nginx user (USER nginx) rather than root
File permissions: Runtime directories (e.g. /app/data) are owned by the nginx user so the application can read and write its data

Why This Matters

1. Reduced Attack Surface (Principle of Least Privilege) Running as a non-root user means that even if an attacker exploits a vulnerability in Nginx or the backend, they do not automatically gain root access to the container. This significantly limits the blast radius of a compromise.

2. Defense in Depth The container no longer relies on root privileges for its core operation. Combined with the fact that the container can be launched with an explicit non-root user (--user apps:apps), this provides multiple layers of protection.

3. Better Container Security Posture Many security scanners and compliance frameworks (e.g. CIS Docker Benchmarks, Kubernetes Pod Security Standards) flag containers running as root. Running as a non-root user helps pass these checks and aligns with industry best practices.

4. Improved Portability The unprivileged image is designed to work in restricted environments where binding to privileged ports (<1024) is not allowed, such as Kubernetes with certain security contexts or OpenShift (which enforces random UIDs).

5. No Functional Impact The application behavior is unchanged — the frontend, backend, and proxy configuration work exactly as before, just without root privileges.

[7ritn]

Issue I am seeing with this is that this requires a change for current installations which I would like to avoid (change port from 80 to 8080)

[luca910]

How about an additional image like vaultls:latest-unprivileged vaultls-unprivileged:latest? Same way nginx is handling it. Furthermore breaking changes is always a risk when using latest

[7ritn]

Yeah I can see that

[7ritn]

Could you rework your PR to support this?

[LiTe1991]

Could you rework your PR to support this?

Sure, I will do it

[LiTe1991]

Could you rework your PR to support this?

I changed it and e2e test also running fine for both versions @7ritn