Consider having a rootless Docker image #24
Description
Current Dockerfile runs as root user (even though haproxy runs under its own user).
Ideally, entrypoint of Dockerfile should already run as that user and we should be able to switch to haproxy user in Dockerfile.
The important detail is that the actual HAProxy process already drops to haproxy at runtime in entrypoint.sh:109. What stays root today is PID 1 and the helper logic around it.
A final USER haproxy in Dockerfile:9 would break or at least change several things:
- The container defaults to privileged ports 80 and 443 in Dockerfile:25 and Dockerfile:28. A non-root process generally needs either higher ports or explicit bind capability.
- Auto-renew currently starts crond in entrypoint.sh:89 and relies on the root periodic job created in Dockerfile:77. That setup is root-oriented.
- Certbot config is copied to a root-specific path in Dockerfile:94.
- Route53 setup writes to ~/.aws in entrypoint.sh:93, so the target user needs a real writable home.
- Once the container itself runs as haproxy, the current exec su haproxy ... in entrypoint.sh:109 becomes unnecessary and should be removed.
haproxy is the right non-root user, but not with just a one-line Dockerfile change. The image is already partly prepared for it because many paths are chowned to haproxy in Dockerfile:71, but the runtime still assumes root.
Potentially, changes made after #15 and follow-up issues such as using the native ACME renew mechanism can make this easier.