Ovirt devel - Aug 2008 - virt-viewer plugin integration issues

Looking for some design advice from you guys.  Here's the situation.

We want to be able to run virt-viewer to connect to oVirt Node guests from 
hosts that are not part of the kerberos infrastructure.  From my looking 
around it seems we have the following options:

1. enable digest-md5 as an auth mech and do user/pass auth and setup a
    simple service account just for virt-viewer (using qemu+tcp connect
    method)
2. use qemu+ssh to connect to libvirt on the Node

1 doesn't seem to work presently since virt-viewer won't prompt you for 
user/password if digest-md5 is a valid auth method (is that because 
virConnectOpenReadOnly is used instead of virConnectOpenAuth?)  And even 
if it were modified to prompt for a password that would happen on a shell 
which may not exist if you're launching firefox from a desktop icon. 
We'd
need a graphical prompt for the user/pass or the ability to pass the 
password as part of the uri perhaps.

2 is problematic since we'd have to set up ssh keys at build time and 
distribute them as part of the appliance.  Key management that we've been 
trying to avoid with all of this.

Either of you have any suggestions on where we should go with this.  Short 
term we need a solution (even if it is slightly hackish) just to make the 
console work.  Longer term we need something more secure.

Dan you mentioned just falling back and using straight vnc plugin since we 
don't need the vnc port lookup since oVirt Server has that info.  That 
doesn't work for when Node is in standalone mode with no server...  And 
besides in standalone mode libvirt has to do digest-md5 since we have no 
kerberos infrastructure in that mode.

Speaking of that... Alan, for your standalone Node patches we need to 
switch libvirt from gssapi to digest-md5 and create an account for people 
to use...  that account creation should be part of the Node first-boot 
configuration TUI probably (along with setting the root passwd).

Perry

-- 
|=-        Red Hat, Engineering, Emerging Technologies, Boston        -=|
|=-                     Email: pmyers at redhat.com                      -=|
|=-         Office: +1 412 474 3552   Mobile: +1 703 362 9622         -=|
|=- GnuPG: E65E4F3D 88F9 F1C9 C2F3 1303 01FE 817C C5D2 8B91 E65E 4F3D -=|

Perry N. Myers wrote:
> Dan you mentioned just falling back and using straight vnc plugin since we 
> don't need the vnc port lookup since oVirt Server has that info.  That 
> doesn't work for when Node is in standalone mode with no server...  And
> besides in standalone mode libvirt has to do digest-md5 since we have no 
> kerberos infrastructure in that mode.
One thought.  You *can* setup libvirt to do completely unencrypted tcp
communication; you just need to set up libvirtd.conf properly.  So maybe we can
just do that in standalone mode, and bypass the digest-md5 thing altogether?
Since we aren't ever leaving the local node with the traffic, we really
shouldn't have a security concern.  Then (I think) we would be able to use
the
VNC plugin.

Chris Lalancette

On Thu, Aug 21, 2008 at 11:43:45PM -0400, Perry N. Myers
wrote:
> Either of you have any suggestions on where we should go with this.  
> Short term we need a solution (even if it is slightly hackish) just to 
> make the console work.  Longer term we need something more secure.
virt-viewer in this case is still running from the browser plugin, or
are we expecting users to launch virt-viewer themselves?

If we control the launching of virt-viewer (eg. through the browser
plugin) then can we obtain a one-time password or key from the QEMU
server on the managed node?  If we can obtain one, then we can easily
pass it through to virt-viewer via an HTML <embed> parameter which
gets passed to the virt-viewer command line.

I think I'm not sure of the exact constraints that this needs to
operate under.

Rich.

-- 
Richard Jones, Emerging Technologies, Red Hat  http://et.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://et.redhat.com/~rjones/virt-df/

On Thu, Aug 21, 2008 at 11:43:45PM -0400, Perry N. Myers
wrote:
> Looking for some design advice from you guys.  Here's the situation.
> 
> We want to be able to run virt-viewer to connect to oVirt Node guests from 
> hosts that are not part of the kerberos infrastructure.  From my looking 
> around it seems we have the following options:
> 
> 1. enable digest-md5 as an auth mech and do user/pass auth and setup a
>    simple service account just for virt-viewer (using qemu+tcp connect
>    method)
Don't use a special account - the user/pass auth should simply be delegated
to the FreeIPA  LDAP server instead of using a local passwd DB.
> 2. use qemu+ssh to connect to libvirt on the Node
> 
> 1 doesn't seem to work presently since virt-viewer won't prompt you
for
> user/password if digest-md5 is a valid auth method (is that because 
> virConnectOpenReadOnly is used instead of virConnectOpenAuth?)  And even 
> if it were modified to prompt for a password that would happen on a shell 
> which may not exist if you're launching firefox from a desktop icon. 
We'd
> need a graphical prompt for the user/pass or the ability to pass the 
> password as part of the uri perhaps.
virt-viewer already has ability to prompt for username/password. If
it is not doing this, then I expect its not choosing  digest-md5. 

You can force it to choose  digest-md5 with a special libvirt URL

    qemu+tcp://hostname/system?auth=sasl.digest-md5
> 2 is problematic since we'd have to set up ssh keys at build time and 
> distribute them as part of the appliance.  Key management that we've
been
> trying to avoid with all of this.
Yes, don't do this. SSH key management is the devil and it destroys your
audit trail because it lets one user triivally login as another without
trace.
> Speaking of that... Alan, for your standalone Node patches we need to 
> switch libvirt from gssapi to digest-md5 and create an account for people 
> to use...  that account creation should be part of the Node first-boot 
> configuration TUI probably (along with setting the root passwd).
You shouldn't need to switch - you can run both SASL methods at once and
it should choose the 'best' one to authenticate with, or you can force
the choice with the URL shown above.  Setting up both is my recommendation

Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|