On Mon, Apr 15, 2013 at 11:11:10AM +0100, Daniel P. Berrange wrote:
On Wed, Apr 10, 2013 at 03:09:18PM +0100, Richard W.M. Jones wrote:
> - Not sure how best to deal with the ssh-agent authentication socket
> problem. Use libvirt secrets? If so, how?
The way that works, is that the application creating the guest
has to pre-populate secrets with keys/passwords/whatever. The
guest XML refers to which secrets it needs, and at guest startup
Libvirt would push the secrets into QEMU.
IIUC, the SSH agent protocol is fundamentally designed around the
idea of "application pull", where as we want an approach which I
describe as "manager push".
Using secrets for passing authentication information in for disks
is the right thing todo - we already do this for RBD for example.
What is missing is a way to securely pass this into QEMU - for RBD
we currently pass this on the command line. The guys who added RBD
support to libvirt were supposed to be adding ability to pass the
passwords via the monitor but that never seems to have happened.
I wish we'd never allowed the patches for RBD for passing stuff on
the command line, still it removed the motivation for them todo a
better job.
Anyway for SSH, I think we need to have this bit of QEMU finished,
so we can pass in authentication credentials via the monitor. There
is an existing 'block_password' command, but that was used for the
decryption keys and I don't think it is wise to overload that for
authentication keys too, since it is in theory possible to access
an encrypted QCow2 image over the SSH protocol, in which case we
would need both decryption keys and authetnication keys at the same
time.
The only other alternative would be to actally make libvirtd implement
an SSH agent service, exposing per-VM UNIX to the QEMU process(es) which
needed SSH keys. I don't much like this though, since it would only
be useful to the SSH disk protocol, and not help address the problems
we already face for RBD and other network block devices.
Would this be any easier if we implemented password authentication (in
qemu's ssh block driver). Then the secret stored by libvirt would be
the password, which it could pass to qemu.
There is still the question of overloading the block_password monitor
command, but that problem presumably applies to other drivers as well.
In fact, you seem to have summarised the solution (I assume this was
never implemented) back in 2011:
http://lists.gnu.org/archive/html/qemu-devel/2011-10/msg02495.html
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top