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.
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.
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.