Enhancement suggestion: lxd host user permissions

LXD
#1

I’m surely not the first person to suggest that lxc exec and launch and delete etc. should be more than ‘all or nothing’ and I’m surely not going to be the last.

Here is my suggestion for debate

As Implementing a comprehensive security system within LXD is going to be a staggering amount of work I’m suggesting that instead that a embedded scripture a REST API call be added optionally to LXD and if its enabled then all operations (add,del,launch,exec etc/) requests are sent to the auth hook for validation before they are executed. This will include UID/GID of Cli callers. Direct Api access can use a name associated with the certificate.

The AUTH Api could then flat fail, pass or modify the request…

Best yet the development effort for this is mostly delegated to the administrators of the LXD and not on the LXD developers.

Thanks for reading
Simon

#2

Yeah, we have no plan to do something that extensive in LXD itself.

Currently for corporate users, an option is to use the external Canonical RBAc service which LXD can interact with to restrict user/group permissions on a per-project basis.

For the local case, the only thing we’ve currently planned is to allow restricting a particular TLS key to a set of projects, it would effectively get an operator role in those projects, allowing to do anything they want with the resources in the project but preventing them from modifying the project itself, therefore allowing the administrator to use the restriction and limits that are offered on projects.

#3

I guess you can currently restrict individual users access to only their containers by using nesting.

As long as they log into their personal/company root container they will not have visibility of others.

So I guess a modified version of the lxc executable at that layer which talks to a proxy lxd socket would do the job.

I’ll see if I can find some time to prototype that.

#4

We should have that ability to tie individual user certificates to projects soon enough, then creating one project per user will be the way to go. You can then restrict that project and place resource limits on it too.