I created a disk device pointing a directory on the host to automatically managed SSL certificates. Intention is to offer additional services secured via those same certificates.
The certificates are mounted inside the container under
/mnt/ssl. It looks like so:
# ls -l /mnt/ssl
-rw-r--r-- 1 nobody nogroup 2212 Feb 7 18:22 cert1.pem
-rw-r--r-- 1 nobody nogroup 3750 Feb 7 18:22 chain1.pem
-rw-r--r-- 1 nobody nogroup 5962 Feb 7 18:22 fullchain1.pem
-rw-r----- 1 nobody nogroup 3268 Feb 7 18:22 privkey1.pem
I have my service inside the container run as a service user (“kibana”). That user obviously can’t read any of these files. Not knowing how else to proceed, I added kibana to ‘nogroup’:
# adduser kibana nogroup
Whether that’s the recommended solution or not, permission-wise, this should work, should it not? However, it doesn’t:
kibana:/mnt/ssl$ cat privkey1.pem
cat: privkey1.pem: Permission denied
I realize that this is likely a crude solution to the problem, and if one solves for this differently, please point me in the right direction. However, why doesn’t this work?
lxc config show <instance> --expanded and
ls -lt <dir> of the source dir on the host.
This touches a couple of areas I’ve been exploring lately. One is indeed how to centrally manage all the individual certs for the various containers on each host (and other devices). I’m very sad to see Certera seems to be dead, for example. I haven’t yet found a solution I like, so this is a WIP for me.
The most helpful document on attaching disks and managing permissions in LXD/LXC I could find (and it is not very easy to find in Google, for some reason) is here.
Thomas, here we go:
$ lxc config show kibana
image.description: ubuntu 22.04 LTS amd64 (release) (20230107)
$ sudo ls -lt /var/certs/certbot/
-rw-r--r-- 1 root root 2212 Feb 7 18:22 cert1.pem
-rw-r--r-- 1 root root 3750 Feb 7 18:22 chain1.pem
-rw-r--r-- 1 root root 5962 Feb 7 18:22 fullchain1.pem
-rw-r----- 1 root root 3268 Feb 7 18:22 privkey1.pem
Thanks for any pointers.
OK, so the files are owned by root on the host (real root), but root in the container is a different UID/GID because you are using unprivileged container (this is good).
All the files except from privkey1.pem are globally readable so they should already be readable in the container, but you’re going to need the private key for the daemon so we need to fix that.
What you can do is set the
shift: true property on the
ssl-certs disk device.
Sets up a shifting overlay to translate the source UID/GID to match the instance (only for containers)
Then you should see the files owned by root in the container.
Thomas, thank you for the reply. Indeed, the files are now owned by root in the container.
(as an aside, my brain doesn’t intuit the order of parameters when changing a configuration parameter; I keep wanting to enter
lxc config kibana set device ssl-certs shift=true, but of course that’s wrong and you need to enter
lxc config device set kibana ssl-certs shift=true, which seems…odd to me).
In any case, I now have a different problem that’s not LXC related (the daemon in the container is running as user ‘kibana’, and files are owned by ‘root’ now).
Any way I can make those files not be owned by root but by ‘kibana’ inside the container? That’s probably a bad idea, but I thought I’d ask anyway.
privkey1.pem group readable so maybe you could change the group of the file in the host? If so, you should note what’s the GID in the instance (
GID=$(lxc exec kibana -- getent group kibana | cut -d: -f 3)) and
chrgp $GID privkey1.pem in the host.