Dear all, 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 ! Mike Le jeu., sept. 15 2022 at 16:07:44 +0530, Leon N <leon9923@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 SSL.

Not sure if this is what you're looking for.

On Thu, Sep 15, 2022 at 3:18 PM Daniel Walsh <dwalsh@redhat.com <mailto:dwalsh@redhat.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 they 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, Mike

_______________________________________________ Podman mailing list -- podman@lists.podman.io <mailto:podman@lists.podman.io> To unsubscribe send an email to podman-leave@lists.podman.io <mailto:podman-leave@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 user.

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@lists.podman.io <mailto:podman@lists.podman.io> To unsubscribe send an email to podman-leave@lists.podman.io <mailto:podman-leave@lists.podman.io>

You can do all of the following

# 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 $CERT_PATH/$DOMAIN/"

# copy all keys for current domain for f in $CERT_PATH/$DOMAIN/*; do echo "Copy $f in $CONTAINER" CONTENTS=$(cat $f) sudo -u $USER podman exec $CONTAINER /bin/bash -c "echo -e '$CONTENTS'

...

$f" done

sudo -u $USER podman exec $CONTAINER /bin/bash -c "chmod 700 $CERT_PATH"

echo "restarting $CONTAINER ..." sudo -u $USER podman stop $CONTAINER

By building a script to do something like copy_cert.sh # /bin/sh -e mnt=$(podman mount $CONTAINER) mkdir -p $MNT/$CERT_PATH/$DOMAIN/" chmod 700 $mnt/$CERT_PATH $ podman unshare copy_cert.sh On 9/15/22 12:11, Mikhaël MYARA wrote:

Dear all,   I think I did something better. Like Leon N said, I attached a script to the renewal hooks, in the folder : /etc/letsencrypt/renewal-hooks/post

  Then, I wrote a script, that will be run as root, that transmits to my container the keys : ----- #!/bin/bash

DOMAIN=mydomain.org CERT_PATH=/etc/letsencrypt/live CONTAINER="mycontainer" USER=myhostuser

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 $CERT_PATH/$DOMAIN/"

# copy all keys for current domain for f in $CERT_PATH/$DOMAIN/*; do echo "Copy $f in $CONTAINER" CONTENTS=$(cat $f) sudo -u $USER podman exec $CONTAINER /bin/bash -c "echo -e '$CONTENTS'

...

$f" done

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

echo "Done."

-----

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.

  Thanks again,       Mike

Le jeu., sept. 15 2022 at 15:21:40 +0200, Mikhaël MYARA <mikhael.myara@ies.univ-montp2.fr> a écrit :

...

Dear all,

  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 !      Mike

Le jeu., sept. 15 2022 at 16:07:44 +0530, Leon N <leon9923@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 SSL.

Not sure if this is what you're looking for.

On Thu, Sep 15, 2022 at 3:18 PM Daniel Walsh <dwalsh@redhat.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 they 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,       Mike

_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@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 user.

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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io

You have to stay in podman unshare shell. When you exit the shell any mountpoints you create are removed. $ podman unshare # ENTERCOMMANDS HERE On 9/15/22 15:19, Mikhaël MYARA wrote:

Thanks for your advice. It seems to be a really intersting solution, as I didn't know we can mount a podman container.

Unfortunately with my tests it does not work, and I don't understand what happens. Also I did not understand why your script does not explicitly make the copy of the files. So I tried to understand what how does the mount command of podman work. Here follows what I did :

I have a container I can attach to, it is called wika-mailer. I tried the following, from user called "ubuntu" that created the container : $podman attach wika-mailer #ls / bin    etc    lib    mnt    proc   run    srv    tmp  var dev    home   media  opt    root   sbin   sys    usr

Now I ctrl p ctrl q and do : $ podman ps -a CONTAINER ID  IMAGE                        COMMAND         CREATED         STATUS            PORTS      NAMES 9a647f1a6d1e  localhost/ovh-mailer:latest  /bin/sh -c /bin/b...  14 minutes ago  Up 5 seconds ago  0.0.0.0:10025->25/tcp  wika-mailer

$ podman unshare podman mount wika-mailer /home/ubuntu/.local/share/containers/storage/overlay/52aef72f297c11c18eed9ef511100c4f21f547b0b326ab672a1f91cd48e7c888/merged

then : ls /home/ubuntu/.local/share/containers/storage/overlay/52aef72f297c11c18eed9ef511100c4f21f547b0b326ab672a1f91cd48e7c888/merged

and here nothing. Perhaps I did not understand what I should get with mount.

Thanks a lot for your time,    Mike

Le jeu., sept. 15 2022 at 14:12:46 -0400, Daniel Walsh <dwalsh@redhat.com> a �crit :

...

You can do all of the following

...

# 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 $CERT_PATH/$DOMAIN/"

# copy all keys for current domain for f in $CERT_PATH/$DOMAIN/*; do echo "Copy $f in $CONTAINER" CONTENTS=$(cat $f) sudo -u $USER podman exec $CONTAINER /bin/bash -c "echo -e '$CONTENTS' > $f" done

sudo -u $USER podman exec $CONTAINER /bin/bash -c "chmod 700 $CERT_PATH"

echo "restarting $CONTAINER ..." sudo -u $USER podman stop $CONTAINER

By building a script to do something like copy_cert.sh # /bin/sh -e mnt=$(podman mount $CONTAINER) mkdir -p $MNT/$CERT_PATH/$DOMAIN/" chmod 700 $mnt/$CERT_PATH $ podman unshare copy_cert.sh

On 9/15/22 12:11, Mikha�l MYARA wrote:

...

Dear all,   I think I did something better. Like Leon N said, I attached a script to the renewal hooks, in the folder : /etc/letsencrypt/renewal-hooks/post

  Then, I wrote a script, that will be run as root, that transmits to my container the keys : ----- #!/bin/bash

DOMAIN=mydomain.org CERT_PATH=/etc/letsencrypt/live CONTAINER="mycontainer" USER=myhostuser

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 $CERT_PATH/$DOMAIN/"

# copy all keys for current domain for f in $CERT_PATH/$DOMAIN/*; do echo "Copy $f in $CONTAINER" CONTENTS=$(cat $f) sudo -u $USER podman exec $CONTAINER /bin/bash -c "echo -e '$CONTENTS' > $f" done

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

echo "Done."

-----

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.

  Thanks again,       Mike

Le jeu., sept. 15 2022 at 15:21:40 +0200, Mikha�l MYARA <mikhael.myara@ies.univ-montp2.fr> a �crit :

...

Dear all,

  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 !      Mike

Le jeu., sept. 15 2022 at 16:07:44 +0530, Leon N <leon9923@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 SSL.

Not sure if this is what you're looking for.

On Thu, Sep 15, 2022 at 3:18 PM Daniel Walsh <dwalsh@redhat.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 they 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,       Mike

_______________________________________________ Podman mailing list --podman@lists.podman.io To unsubscribe send an email topodman-leave@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 user.

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@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io