Description
I've been testing symfony-docker on our infrastructure with custom wildcard TLS certificates mounted from the host, as described in docs/tls.md. I was in the middle of testing when I saw #909 land yesterday, so I pulled it right away to try it out.
Since #909 (feat: use rootless Debian slim images for prod), the prod container runs as www-data. This seems to break bind-mounted TLS certificates when the private key on the host has standard restrictive permissions (600 root:root), which is typically the case, especially when certificates are managed/renewed automatically.
The container fails to start with:
Error: loading initial config: loading new config: loading frankenphp app module: provision frankenphp:
failed to provision caddy http: loading http app module: provision http: getting tls app: loading tls
app module: provision tls: loading certificates: open /etc/caddy/certs/tls.key: permission denied
Context
On the host, the certificate files have standard permissions:
-rw-r--r-- 1 root root 7972 Oct 15 11:14 tls.pem
-rw------- 1 root root 3267 Oct 15 11:14 tls.key
This worked fine before #909, when the container ran as root. I wanted to raise this quickly, apologies if I'm missing an obvious solution. I could work around it by copying the certs into the container or similar, but that feels hacky and would need to be redone on every certificate renewal.
Description
I've been testing symfony-docker on our infrastructure with custom wildcard TLS certificates mounted from the host, as described in
docs/tls.md. I was in the middle of testing when I saw #909 land yesterday, so I pulled it right away to try it out.Since #909 (
feat: use rootless Debian slim images for prod), the prod container runs aswww-data. This seems to break bind-mounted TLS certificates when the private key on the host has standard restrictive permissions (600 root:root), which is typically the case, especially when certificates are managed/renewed automatically.The container fails to start with:
Context
On the host, the certificate files have standard permissions:
This worked fine before #909, when the container ran as root. I wanted to raise this quickly, apologies if I'm missing an obvious solution. I could work around it by copying the certs into the container or similar, but that feels hacky and would need to be redone on every certificate renewal.