LXD security practice

Hi guys

I’m trying to isolate the /var/snap/lxd/common/lxd folder to an encrypted disk image file (eg. lxd.img). By doing this, I can secure my lxd and let others use LXD on my computer if I don’t mount the folder. I tried it and got the same message as this topic https://discuss.linuxcontainers.org/t/lxd-error-get-http-unix-socket-1-0-dial-unix-var-snap-lxd-common-lxd-unix-socket-connect-connection-refused/12305/30

Can anyone help me with this case?

These days with LXD supporting offline storage pools, I think a better approach may be to use an encrypted disk image (LUKS) and then feed that block device (/dev/mapper/some-name) to LXD to put a ZFS or other storage pool on top of it.

This means that the LXD database and images will be on the root partition in /var/snap/lxd/common/lxd but all actual instance data will be on the encrypted storage.

On boot, LXD will be able to startup normally, will detect it’s lacking its storage pool and will hold instance startup. Then when you want to access your instances, you tell LUKS to setup the /dev/mapper device, LXD will detect it and will bring your instances up.

Putting all of /var/snap/lxd/common/lxd on encrypted storage that’s not available on startup is certainly possible but will need more interactions with systemd and the host OS than the approach I just described.

1 Like

That’s exactly what I’m doing. I’m just trying to create an extra guard gate scene for my application so that my instances cannot be read the information (info, programs, etc). If the implementation is not as simple as you say then I will continue with the current solution.

Thank you so much, @stgraber