Hi,
Just read the last changelog of new release 4.22 and I am very interested with the new daemon named lxd-user. On my laptop, I have this very last release installed and wanted to give it a try.
So, here is what I did :
$ getent passwd test
test:x:1001:100::/home/test:/bin/bash
$ groups test
test : users
$ getent group users
users:x:100:
$ snap set lxd daemon.user.group=users
$ su - test
test $ lxc list
Error: not authorized
test $ lxc --version
4.22
From the above, I think I did all that was necessary to have it working, but it doesn’t. What did I do wrong ?
Subsidiary question : is that possible to give a list of groups instead of just only one ?
You may have used lxc prior to having your user fully setup.
If that’s the case, you can either do lxc project list followed by lxc project switch NAME to the project that was created for you, or you can blow away the ~/snap/lxd directory which will cause lxc to start fresh and detect the user project.
What about lxd-user on the machine that is already in lxd cluster? And are perhaps defaults configurable (eg. name of project, project’s restrictions/quotas/etc)?
Currently all defaults are hardcoded. We may in time add some more flexibility there though. I did consider trying to make this templatable but it was going to be too much work at the time.
If the machine is clustered, everything should still work the same way except that the user will effectively have access to the cluster rather than just a standalone machine, but same project logic and restrictions will apply. It’d be a good idea of the user to have the same uid/gid and home path throughout the cluster though or you could get into some issues.
Once again, thanks for your kind and quick answer. From what I’ve been testing, it works and offers new perspectives.
I’ve tried to understand the underlying logic used and I guess that this daemon uses a socket for the purpose. What would be great to me would be that this lxd-user daemon could listen also on a network port (8444 for the fun ?) and proxies request to the main lxd daemon as it does right now.
I don’t know how much work it would be to have it, but it could help as this would allow to expose some of the rest api to users and make it easy to write webapps.
We can’t really do it over HTTPS as we can’t know who the user is and what group they may be a part of.
If you already have projects created you can perfectly restrict a given user (TLS certificate) to one or more projects in the regular HTTPS API though.
That’s in fact exactly what lxd-user uses behind the scenes. It creates the project, creates a certificate for the user and then adds it with a project restrictions to the LXD trust store. It then connects as that user using their certificate to LXD.
Oh… Once again, thank you so much. I’ll see how to restrict a given user to project(s) with the regular https api, it will give so much improvements to what I developed around lxd for my work.
lxc config trust list to list all trusted certificates and lxc cofnig trust edit to change them. You’ll want to set restricted to true and then list one or more project names in the projects field.
Once you do that, the user will be restricted to an operator level of access so won’t be able to reconfigure LXD itself but will have the ability to do whatever they want within their project(s) except for altering the project configuration itself.