Re: [libvirt] Implementing VNC per VM access control lists
Eric,
Thanks for the reply.
On Thu, 2011-01-06 at 11:33 -0700, Eric Blake wrote:
When we first designed qemu:commandline, we debated about making it
smart enough to allow rewriting of existing arguments (rather than only
allowing addition of new arguments). This definitely sounds like a use
case worth revisiting that situation, and enhancing qemu:commandline to
have more features.
Possibly, although it would complicate it horribly. Are there sufficient
unsupported options on the existing qemu switches to justify the work?
> The option only really makes sense if either vnc_tls_x509_verify
or
> vnc_sasl is set as well, so it may be worth only activating 'acl' in the
> code if either of those two are also on.
Should this be a per-XML setting, rather than a global qemu.conf setting?
That argument could be made for all the vnc options in qemu.conf. I
might want SASL username and password on one VM and specific x509 client
certs on another. Currently the server certificate configuration is per
Host, which means that CNAMES like 'console.myvm.brightbox.es' and
'console.yourvm.brightbox.es' are not possible in the configuration.
There's a lot of the qemu.conf that is arguably VM specific stuff.
Having said that I think that pragmatically it is right to keep it out
of the XML to prevent a nasty backward compatibility problem later on.
Really all this stuff belongs in the RBAC structure because you want to
apply a security profile to groups of VMS - possibly across Hosts.
But RBAC is going to need a strategic sponsor from one of the
distributions - probably as part of a system wide RBAC along Solaris
lines.
Is this something that is forward-looking (ie. once we also have an
access layer designed, will it still make sense to keep and honor the
qemu.conf setting), or is it enough of a hack that we should instead try
to resolve it via the qemu:commandline approach (where we've explicitly
documented that use of the interface is the approved way to do hacks in
the absence of proper libvirt support)?
It's as forward looking as all the other options in qemu.conf and at the
same scope. The libvirt support proposed is Host wide - as it is with
SASL, tls, etc.
The VM specific stuff is done out of band using the hack channel.
So the honouring problem is going to be exactly the same as the other
options. Libvirt is going to need a deprecation policy to trim the warty
stuff at some point.
I think pragmatically it is best to stick with the existing qemu.conf
approach because the code is there to handle it already.
Regards
Neil