3 ms·
I use docker for the same reasons as the author's reservations - I combine a docker exec with some of my own loose automation around moving & chmod-ing files &
by lucideer 1y ago
I use docker for the same reasons as the author's reservations - I combine a docker exec with some of my own loose automation around moving & chmod-ing files & directories to obviate the need for the acme client to have unfettered root access to my system.
Whether it's a local binary or a dockerised one, that access still needs to be marshalled either way & it can get complex facilitating that with a docker container. I haven't found it too bad but I'd really rather not need docker for on-demand automations.
I give plenty* of services root access to my system, most of which I haven't written myself & I certainly haven't audited their code line-by-line, but I agree with the author that you do get a sense from experience of the overall hygiene of a project & an ACME client has yet to give me good vibes.
* within reason
- paul_h 1y agoCopilot suggests: docker run --rm \ -v /srv/mywebsite/certs:/acme.sh/certs \ -v /srv/mywebsite/public/.well-known/acme- challenge:/acme-challenge \ neilpang/acme.sh --issue \ --webroot /acme-challenge \ -d yourdomain.com \ --cert-file /acme.sh/certs/cert.pem \ --key-file /acme.sh/certs/key.pem \ --fullchain-file /acme.sh/certs/fullchain.pem I don't know why it's suggesting `neilpang` though, as he no longer has a fork.
- lucideer 1y agoYeah I'm not running anything llms spit at me in a security-sensitive context. That example is not so bad - you've already pointed out the main obvious supply-chain attack vector in referencing a random ephemeral fork, but otherwise it's certonly (presumably neil's default) so it's the simplest case. Many clients have more... intrusive defaults that prioritise first-run cert onboarding which is opening more surface area for write error.