RE: Xen API/libvirt & Remote

RE: Xen API/libvirt & Remote

[John Anderson]

I suppose I can.

Basically I wanted a fencing mechanism for RedHat Cluster's fenced. Most
of what I read uses a script to ssh with key exchange authentication to
the Xen Dom0 and destroy the DomU.  I didn't want to do that because you
need root permissions in order to destroy a DomU and my company has a
strict policy that sshd doesn't allow root logins.

To that end I wrote a small server daemon (xenfenced) using gSOAP
[http://gsoap2.sourceforge.net/] that listens for soap connections and
runs on the Xen Dom0.  Then I wrote a small gSOAP client that sits at
/sbin/fence_xen.   When invoked the client parses the options from
stdin, and makes a soap call to xenfenced on the appropriate Xen Dom0(s)
as listed in the tags in /etc/cluster/cluster.conf.  Xenfenced then uses
libvirt to see if the requested domain exists within that hypervisor and
if it does the domain is destroyed.

Xenfenced uses SSL certificates to authenticate clients and fence_xen
uses SSL certficates to authenticate the server, so any connections
originating from/to clients/servers whose certificate is not my signed
by my root CA will fail the SSL handshake.

Here is a link to the (pretty cheesy) proof of concept code.  It works
though.  http://chesty.homedns.org:4572/fence_xen/

It should compile with gSOAP > 2.7 & libvirt > 0.0.6.

I'm guessing that in the future, libvirt will handle the network
transport & authentication tasks I'm using gSOAP for currently.  When
that happens it would be nice to have an SSL certificate authentication
mechanism.

John A.


-----Original Message-----
From: Daniel P. Berrange [mailto:berrange@redhat.com] 
Sent: Friday, August 04, 2006 6:47 AM
To: John Anderson
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen API/libvirt & Remote

On Thu, Aug 03, 2006 at 10:14:05AM -0700, John Anderson wrote:
> Authentication would have been my next question had I discovered that
> remote access was possible and widely used, but since there is no
> authentication mechanism, I agree that opening the http port is a bad
> thing.
> 
> I think I've found a solution.  I've wrapped the libvirt calls I need
> with gSOAP using SSL certificate authentication.   It seems to be
> working for me and secure.

Could you elaborate a little on how you implemented this ? Did it 
involve changes to libvirt or xend code to support it ? If its a 
solution which other people would benefit from I'd like to see if
we could incorporate any neccessary changes in libvirt, or at least
document it as one of the deployment scenarios.

Regards,
Dan. 
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392
2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/
-=|
|=-               Projects: http://freshmeat.net/~danielpb/
-=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505
-=| 

Re: Xen API/libvirt & Remote

[Daniel Veillard]

On Fri, Aug 04, 2006 at 11:09:44AM -0700, John Anderson wrote:
> I'm guessing that in the future, libvirt will handle the network
> transport & authentication tasks I'm using gSOAP for currently.  When
> that happens it would be nice to have an SSL certificate authentication
> mechanism.

  I'm still wondering honnestly. There is so many way to do remote access
(custom protocol, XML-RPC, SOAP,CORBA, ...) and I would expect each 
'customer' to have his own type of deployed framework already, so I'm not
sure adding one kind of remote access capability would hit the 80/20 sweet
spot. It would also make things more complex (need for a daemon etc. though
there is already one for the proxy mode). I would also expect each deployment
to have it's own preferred authentication method which may vary greatly
depending on how and why they use virtualization (LDAP, SSH, etc...). Basically
the matrix of capabilities explodes and unless going though a very versatile
(plugin again) interface, hardcoding one may not be usable to most users.
  Maybe when we have more deployment and more use case feedback then it
should be considered more seriously, in the meantime explaining how things
could be done is probably the best approach.

    Feedback welcome :-)

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

RE: Xen API/libvirt & Remote

[John Anderson]

Authentication would have been my next question had I discovered that
remote access was possible and widely used, but since there is no
authentication mechanism, I agree that opening the http port is a bad
thing.

I think I've found a solution.  I've wrapped the libvirt calls I need
with gSOAP using SSL certificate authentication.   It seems to be
working for me and secure.

Thanks!

John A.

-----Original Message-----
From: Daniel Veillard [mailto:veillard@redhat.com] 
Sent: Thursday, August 03, 2006 1:46 AM
To: John Anderson
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] Xen API/libvirt & Remote

On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:
> I've been reading through the Xen API wiki page and it's associated
PDF,
> as well as checking out libvirt for a solution to remotely manage xend
> daemons.  Unless I missed something, it seems both the Xen API and
> libvirt only make xml-rpc calls to a local xend daemon.  Is this true
or
> am I way off base? 

  It's a bit more complex, first libvirt does not (yet) make xml-rpc
calls
it currently does more ad-hoc HTTP based calls when talking to xend.
Second
libvirt interract with Xen in more ways than just with xend. 

> If the Xen API & libvirt can only connect to a local xend daemon, are
> there any alternatives short of providing your own transport (i.e.
> ssh/telnet to invoke the command locally) ?

  I think libvirt 0.1.3 should be able to connect to remote xend daemons
using the HTTP protocol. It will be limited to xend based accesses and
there is unfortunately no authentication.
  Security wise opening the HTTP port is a big no-no in my opinion,
anybody
getting access to the network one way or another would instantly get
control
over every domain running. Using SSH or other secure authenticated
transport
to then connect to the local service sounds way saner, that's why I
didn't
really pushed or tested the remote access. But passing an URL pointing
to
the remote service when opening the libvirt connection may work, though
as
said I don't really recommend this.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: Xen API/libvirt & Remote

[Daniel P. Berrange]

On Thu, Aug 03, 2006 at 10:14:05AM -0700, John Anderson wrote:
> Authentication would have been my next question had I discovered that
> remote access was possible and widely used, but since there is no
> authentication mechanism, I agree that opening the http port is a bad
> thing.
> 
> I think I've found a solution.  I've wrapped the libvirt calls I need
> with gSOAP using SSL certificate authentication.   It seems to be
> working for me and secure.

Could you elaborate a little on how you implemented this ? Did it 
involve changes to libvirt or xend code to support it ? If its a 
solution which other people would benefit from I'd like to see if
we could incorporate any neccessary changes in libvirt, or at least
document it as one of the deployment scenarios.

Regards,
Dan. 
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

Xen API/libvirt & Remote

[John Anderson]

[-- Attachment #1.1: Type: text/plain, Size: 604 bytes --]

Greetings,

 

I've been reading through the Xen API wiki page and it's associated PDF,
as well as checking out libvirt for a solution to remotely manage xend
daemons.  Unless I missed something, it seems both the Xen API and
libvirt only make xml-rpc calls to a local xend daemon.  Is this true or
am I way off base? 

 

If the Xen API & libvirt can only connect to a local xend daemon, are
there any alternatives short of providing your own transport (i.e.
ssh/telnet to invoke the command locally) ?

 

 

Any suggestions would be appreciated.

 

Thanks,

 

John A.


[-- Attachment #1.2: Type: text/html, Size: 3099 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: Xen API/libvirt & Remote

[Daniel Veillard]

On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:
> I've been reading through the Xen API wiki page and it's associated PDF,
> as well as checking out libvirt for a solution to remotely manage xend
> daemons.  Unless I missed something, it seems both the Xen API and
> libvirt only make xml-rpc calls to a local xend daemon.  Is this true or
> am I way off base? 

  It's a bit more complex, first libvirt does not (yet) make xml-rpc calls
it currently does more ad-hoc HTTP based calls when talking to xend. Second
libvirt interract with Xen in more ways than just with xend. 

> If the Xen API & libvirt can only connect to a local xend daemon, are
> there any alternatives short of providing your own transport (i.e.
> ssh/telnet to invoke the command locally) ?

  I think libvirt 0.1.3 should be able to connect to remote xend daemons
using the HTTP protocol. It will be limited to xend based accesses and
there is unfortunately no authentication.
  Security wise opening the HTTP port is a big no-no in my opinion, anybody
getting access to the network one way or another would instantly get control
over every domain running. Using SSH or other secure authenticated transport
to then connect to the local service sounds way saner, that's why I didn't
really pushed or tested the remote access. But passing an URL pointing to
the remote service when opening the libvirt connection may work, though as
said I don't really recommend this.

Daniel

-- 
Daniel Veillard      | Red Hat http://redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/

Re: Xen API/libvirt & Remote

[Ewan Mellor]

Hi John,

Sorry for the delay in replying.

On Wed, Aug 02, 2006 at 04:28:37PM -0700, John Anderson wrote:

> I've been reading through the Xen API wiki page and it's associated PDF,
> as well as checking out libvirt for a solution to remotely manage xend
> daemons.  Unless I missed something, it seems both the Xen API and libvirt
> only make xml-rpc calls to a local xend daemon.  Is this true or am I way
> off base?
> 
> If the Xen API & libvirt can only connect to a local xend daemon, are
> there any alternatives short of providing your own transport (i.e.
> ssh/telnet to invoke the command locally) ?

As you've discussed with Daniel Veillard already, the reason we don't open a
port by default at the moment is that there's no authentication in the
protocol.  If you're in a secure environment, you could use XML-RPC/HTTP, with
a small patch to Xend.  Alternatively there is now XML-RPC/SSH support too, so
you can set up SSH keys and use that as your authentication layer.  I can dig
more information out if you're interested.

The plan for the future is to improve this aspect of the Xen API
significantly.  I posted new C bindings to the Xen-API mailing list today, and
these show how you would be able to manage Xend remotely using libcurl.  I
intend for all our bindings to work remotely, and over a number of transports,
and securely.  If you're interested in this work, you could join the Xen-API
mailing list, or simply wait until Xen 3.0.3 is released, at which point we're
going to start dropping this work into Xen unstable so that it can be released
with Xen 3.0.4.

Cheers,

Ewan.