Lxd: Container sets (superset of per-user containers)

[MoritzMaxeiner]

Hi, while checking if I could replace LXC with LXD, I found that there is one (for me) critical feature, that I could not locate:

Have a set A of containers owned by a set of clients C (in my use case C consists of a single user):

• Only clients c in C will be shown containers a in A when calling lxc list, as well as are allowed to start/stop them (excluding root)

Optional feature would be some protection that breakouts from one container set cannot access containers in another container set (e.g. by putting container sets into separate directories with appropriate permissions).

The only way to achieve that I could find in the documentation is having one LXD daemon running for each container set, which seems excessive to me. If this is not implemented, I would like to request this feature.

[stgraber]

This is something we've discussed a few times but is far trickier to implement than it sounds. We may look into this at some point but it's not on our immediate roadmap.

The difficulties are related to the image store with shared/public images and the fact that we store them by their hash, making it impossible for two tenants to own an image by the same hash.

[MoritzMaxeiner]

Okay, thank you for the clarification. Would it then be possible to at least support multiple separate lxd instances (if it is already supported, my bad, but I could not find a configuration option to set lxd's path /var/lib/lxd to something else)?

[timtadh]

@Calrama Did you figure out a way to get per-user lxd daemon's running? I have also concluded that this is the only way forward on this issue at the present time.

[MoritzMaxeiner]

@timtadh I didn't continue to look too deeply into it as my use case changed, but if I'd had to reach the same goal now, I'd probably use (unprivileged) nested lxd containers, i.e. give every user a single ipv6 enabled container (probably alpine linux, since it's small) to directly ssh into and tell them to install lxd into it. Not ideal, but easier to setup than figuring out how to use multiple lxd daemons, I reckon.

[ottacom]

I need this feature too!
I really would like to have multiple users with different views and different permission:
Could be wonderful if every single user can only see his containers and do whatever with them, but never stop/start/destroy the others containers.
Without this feature I can't go ahead it's a real peaty.

The only idea that I have now to handle this issue is building something by myself, some LXC cloud commands
Cheers

[stgraber]

Closing in favor of #2689 as this one should cover this. Effectively LXD containers and images will be tied to a project (name to be bikesheded still) and listing and other operations will be targeted to a project.

[razermackham]

I see projects #2689 has been released, but it's not clear to me, how to map user/group permissions to projects?

[stgraber]

We don't intend to do user/group management in LXD itself instead we will be integrating with an upcoming external RBAC service which combined with Candid for authentication will let you restrict what a given user or group has access to as far as projects and then what permissions they have on those projects.