Hello,
I am running libvirt on a fleet of hosts which live-migrate guests
between each other in peer-to-peer mode, over TLS with client
certificates.
With peer-to-peer migration, each host must accept incoming libvirt
connections from all its peers. Today, once a remote client is
authenticated (trusted x509 certificate and/or SASL), it can use the
full API. I would like to restrict what a given remote peer is allowed
to do, ideally to "receive an incoming migration" only.
If I understand correctly, the access control framework cannot be used
for remote clients today:
- the only shipped access drivers are "none" and "polkit";
- the polkit driver identifies the caller by its local process
ID/UID, which is only available for clients connected to the UNIX
domain socket, so checks cannot succeed for remote connections;
- the documentation [1] still says that the SASL / Kerberos username
and/or x509 distinguished name obtained from the authentication
provider should be used "in future versions".
This wording dates back to the original access control work in 2013,
where support for remote identities was listed as future work, and it
does not seem to have changed since.
So I have a few simple questions:
* Is this still on your roadmap, or is somebody working on it?
* Was it discussed after 2013? If there is a reason it was not done,
I would be happy to understand it.
* We can spend time to write and test patches in this area. If you
had to do it, which direction would you take? Is there a design you
would prefer, or something you would not accept upstream? We would
be happy to discuss and agree on a design before starting.
[1] https://libvirt.org/aclpolkit.html - "User identity attributes"
Thanks,
--
Pierre-Samuel Le Stang
