I think I did something better. Like Leon N said, I attached a script
to the renewal hooks, in the folder :
Then, I wrote a script, that will be run as root, that transmits to
my container the keys :
echo "updating container $CONTAINER with letsencrypt keys"
# if container down start it
sudo -u $USER podman start $CONTAINER
# create folders if they don't exist
sudo -u $USER podman exec $CONTAINER /bin/bash -c "mkdir -p
# copy all keys for current domain
for f in $CERT_PATH/$DOMAIN/*; do
echo "Copy $f in $CONTAINER"
sudo -u $USER podman exec $CONTAINER /bin/bash -c "echo -e '$CONTENTS'
sudo -u $USER podman exec $CONTAINER /bin/bash -c "chmod 700 $CERT_PATH"
echo "restarting $CONTAINER ..."
sudo -u $USER podman stop $CONTAINER
sudo -u $USER podman start $CONTAINER
I did it because I need to be root to access the letsencrypt keys on
the host, and I need (I think) to run podman as the user that created
the container to access my rootless container. I did not find how to
copy as root to a user's container using the cp command of podman.
Le jeu., sept. 15 2022 at 15:21:40 +0200, Mikhaël MYARA
<mikhael.myara(a)ies.univ-montp2.fr> a écrit :
thanks a lot for your answers ! If I sum-up, my question was how
to have access, inside a rootless container, to a file only
accessible by root on the host, in the cleanest/secyred way. Indeed,
the private key should be shared between various microservices.
I searched again over the internet and I found that people follow
Leon N's solution, I think it's the good one : copying the keys
inside the container when triggerd by the letsencrypt refresh process.
Thanks a lot for your kind help !
Le jeu., sept. 15 2022 at 16:07:44 +0530, Leon N <leon9923(a)gmail.com>
a écrit :
> One can use letsencypt post-renewal hooks as such and probably copy
> the certs to a folder with permissions for the users.
> This is the hook file
> cat /etc/letsencrypt/renewal-hooks/post/renew-ssl.sh
> Hook file content
> cat "/etc/letsencrypt/live/domainfullchain.pem"
> "/etc/letsencrypt/live/domain/privkey.pem" | sudo -u leon tee
> /home/leon/containers/portfolio/haproxy/sslcerts/domain > /dev/null
> I also add a systemctl reload so that the container can reread the
> Not sure if this is what you're looking for.
> On Thu, Sep 15, 2022 at 3:18 PM Daniel Walsh <dwalsh(a)redhat.com
> <mailto:email@example.com>> wrote:
>> On 9/14/22 17:24, Mikhaël MYARA wrote:
>>> dear all,
>>> I work on a podman container for postfix + dovecot. On my
>>> host, the encrypt keys (including the private key) are stored in
>>> /etc/letsencrypt/live/xxxxx.xxx/, and these keys have to be used
>>> by both postfix and dovecot.
>>> However the "/etc/letsencrypt/live" folder is only accessible
>>> by root, so that when I share the /etc/letsencrypt folder using
>>> the -v option, the container has no access to the live folder. Of
>>> course, if I do awful things like chmod 777 on the
>>> /etc/letsencrypt/live folder everything is ok. But of course it is
>>> not a good way for that.
>>> I wanted to know what I should do to avoid this chmod 777 while
>>> working with a rootless container. Can I map the volume using root
>>> ? (and if so is it a good idea ?) Should I play with groups on the
>>> host (= a group called like "encrypters", that may contain only
>>> root and the user that runs the container ?) Or a root process
>>> that performs copies of the keys ?
>>> I also have seen the "--secret" option for podman I did not
>>> understad If it would solve my problem. Please also notice that
>>> the "let's encrypt" keys are re-generated sometimes because
>>> have a 1 month lifetime.
>>> If there is some guideline somewhere about this topic please
>>> show me.
>>> My host is ubuntu 22.04, and the podman version is 3.4.4. I
>>> don't use SE linux for now.
>>> Thanks a lot,
>>> Podman mailing list -- podman(a)lists.podman.io
>>> To unsubscribe send an email to podman-leave(a)lists.podman.io
>> I guess if the goal is to change the /etc/letsencrypt/live on the
>> host via a container, then you will have to make the directory
>> writable by the non root user running the container.
>> This can be done using group access or ACLs. Inside of the
>> container the files will look like they are owned by the nobody
>> If you want the files read from the host but only writeable from
>> within the container, IE they don't effect the host at all, you
>> could try to mount the volume as an Overlay volume.
>> -v /etc/letsencrypt/live:/etc/letsencrypt/live:O
>> Note the values here will be private to the container and will be
>> removed when the container is destroyed.
>> If you don't want values read from the host at all, but just the
>> container to use secrets, then you could use secrets
>> Podman mailing list -- podman(a)lists.podman.io
>> To unsubscribe send an email to podman-leave(a)lists.podman.io