RE: [Propose] Improvements in XenServer + ACS integration
Just trying to understand our existing integration I found http://docs.openstack.org/juno/config-reference/content/introduction-to-xen.html which discusses how OpenStack uses XAPI plugins. Do we have a similar document describing the integration of CloudStack with Xen via SSH? Don't we also use XAPI plugins? See https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=tree;f=scripts/vm/hypervisor/xenserver and https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;a=blob;f=plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java;hb=HEAD#l630 It's true that the database encryption algorithms could be improved. I filed https://issues.apache.org/jira/browse/CLOUDSTACK-8015; hopefully we could move away from MD5 and DES. -Original Message- From: Marco Sinhoreli [mailto:marco.sinhor...@shapeblue.com] Sent: Monday, November 24, 2014 10:18 AM To: dev@cloudstack.apache.org Subject: Re: [Propose] Improvements in XenServer + ACS integration Hi Stephen: Thank you for yours comments! I understand your worry about host.plugins and agree but, compared with the actual ACS approach where shell scripts are used over ssh to call root commands inside XenServer, it represents an better one. My worry is about to store root password in the ACS DB where people not authorized can revert the md5sum applied and then connect directly to the server and run anything. An great approach is limit the commands called by host.plugins using the sudo. About xenstore, it's only an another way share informations (or use it as semaphore) to some agent running in the system VMs for example not as a public interface. Marco Sinhoreli Consultant Manager Phone: +55 21 2586 6390 | Fax: +55 21 2586 6002 | Mobile: +55 21 98276 3636 | Mobile: +55 21 99711 4645 Praia de Botafogo 501, bloco 1 - sala 101, Botafogo, Rio de Janeiro, RJ - Brazil - CEP 22250-040 marco.sinhor...@shapeblue.com | www.shapeblue.com http://www.shapeblue.com/ | Twitter:@shapeBlue https://twitter.com/#!/shapeblue On 24/11/14 08:51, Stephen Turner stephen.tur...@citrix.com wrote: Thanks for showing me this at the conference, Marco. I like the idea of authenticated users, but I haven't understood the role of the XenServer plugin here. Only a pool admin can call Host.call_plugin, and pool admins have the same permissions as root, so the plugin can't convey any additional privileges and I don't see how it acts as a security layer. In general, I think we should move away from XenServer plugins (and Alex Huang already made some steps in this direction at the beginning of the year). The problem with plugins is that if XenServer changes, it may break the plugin, and we will have to scramble to fix it up when we notice. You also mentioned xenstore: I would certainly caution against using that, because it's not supposed to be a public interface. I guess my philosophy is that we should treat XenServer as a black box as much as possible, accessible only through the public API. (Of course, Host.call_plugin is an API call, but you know what I mean). Just because we know that dom0 is just a Linux box and we can do anything, doesn't mean that that's good architecture. XenCenter only uses the public API, for example. And if the public API doesn't provide something we really need, we should advocate to the upstream project to change it, or even submit a patch as XenServer is open source too. -- Stephen Turner -Original Message- From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com] Sent: 24 November 2014 08:44 To: dev@cloudstack.apache.org Subject: Re: [Propose] Improvements in XenServer + ACS integration Great idea and work Marco! The gist of the proposal is that we can allow non-root users to add hosts and Marco successfully shows us how that is possible. On 23-Nov-2014, at 5:42 pm, Marco Sinhoreli marco.sinhor...@shapeblue.com wrote: Hi community, I'm starting this discussion to share some ideas about XenServer integration in ACS. Since XenServer has some nice features to do that like RBAC, host plugin and XenStore, I demonstrate these to some community members at CCCEU14. Some references you can look in these links: https://blog.xenproject.org/2011/11/09/xcp-rbac-and-pam-authenticatio n -in-the-xenapi/ https://wiki.xenserver.org/index.php?title=RBAC http://wiki.xen.org/wiki/XAPI_Host_Plugins http://wiki.xen.org/wiki/XenStore Actual status in ACS: During the XenServer setup, is possible to define a user to connect to the xapi. In XenCenter, is possible to use a different user (no-root) using external authentication like AD our PAM since the RBAC is configured properly for this. In ACS it's not possible because many command need be called by root using SSH. Another issue in this approach is about security: root password is stored in DB and, in this approach we have a security compliance issue. The root used used to call shell scripts
Re: [Propose] Improvements in XenServer + ACS integration
Great idea and work Marco!
The gist of the proposal is that we can allow non-root users to add hosts and
Marco successfully shows us how that is possible.
On 23-Nov-2014, at 5:42 pm, Marco Sinhoreli marco.sinhor...@shapeblue.com
wrote:
Hi community,
I’m starting this discussion to share some ideas about XenServer integration
in ACS. Since XenServer has some nice features to do that like RBAC, host
plugin and XenStore, I demonstrate these to some community members at CCCEU14.
Some references you can look in these links:
https://blog.xenproject.org/2011/11/09/xcp-rbac-and-pam-authentication-in-the-xenapi/
https://wiki.xenserver.org/index.php?title=RBAC
http://wiki.xen.org/wiki/XAPI_Host_Plugins
http://wiki.xen.org/wiki/XenStore
Actual status in ACS:
During the XenServer setup, is possible to define a user to connect to the
xapi. In XenCenter, is possible to use a different user (no-root) using
external authentication like AD our PAM since the RBAC is configured properly
for this. In ACS it’s not possible because many command need be called by
root using SSH. Another issue in this approach is about security: root
password is stored in DB and, in this approach we have a security compliance
issue. The root used used to call shell scripts in the XenServer host are all
hard-coded.
What we can do?
- Substitute host SSH connection to XAPI host plugins
In my view, I prefer use just one-way to connect to XenServer, in this case,
changing host SSH interactions to use exclusively XAPI. XAPI implements Host
Plugins where could be used to as a security layer to call commands into host.
An example of host plugin:
# cat xen_plugin_demo
#!/usr/bin/python
import XenAPIPlugin
import subprocess
def main(session, args):
try:
p = subprocess.Popen(args[cmd].split( ), stdout=subprocess.PIPE,
stderr=subprocess.PIPE)
out, err = p.communicate()
return out
except KeyError:
raise RuntimeError(No argument found with key.)
if __name__ == __main__:
XenAPIPlugin.dispatch({main: main})
And a client:
$ cat call_plugin.py
import XenAPI
import sys
session = XenAPI.Session('https://192.168.56.12')
session.login_with_password('cloud', 'password')
host, = session.xenapi.host.get_all()
print
print session.xenapi.host.call_plugin(host, 'xen_plugin_demo', 'main', {'cmd'
: .join(sys.argv[1:])})
Calling:
$ python call_plugin.py ls /root
add_roles.sh
support.tar.bz2
- Setup RBAC to use a non-root to manage the XenServer host
As a suggestion, for this approach, need to have a user pre-seted in PAM or
configure XenServer AD. Follow what need be running in the XenServer shell to
setup the user, external auth, associate RBAC role to this user:
adduser cloudstack
password cloudstack
xe pool-enable-external-auth auth-type=PAM config:user=cloudstack
service-name=CloudStack
xe subject-add subject-name=cloudstack
subject_uuid=$(xe subject-list | awk '/^uuid/{print $5}')
role_uuid=$(xe role-list name=pool-admin params=uuid | awk '/^uuid/{print
$5}')
xe subject-role-add uuid=${subject_uuid} role-uuid=${role_uuid}
We can in this case, maintain the scripts used today, needing change the way
to call them from ACS.
Best regards,
Marco Sinhoreli
Consultant Manager
Phone: +55 21 2586 6390 | Fax: +55 21 2586 6002 | Mobile: +55 21 98276 3636 |
Mobile: +55 21 99711 4645
Praia de Botafogo 501, bloco 1 - sala 101, Botafogo, Rio de Janeiro, RJ -
Brazil - CEP 22250-040
marco.sinhor...@shapeblue.com | www.shapeblue.com | Twitter:@shapeBlue
Find out more about ShapeBlue and our range of CloudStack related services
IaaS Cloud Design Build
CSForge – rapid IaaS deployment framework
CloudStack Consulting
CloudStack Software Engineering
CloudStack Infrastructure Support
CloudStack Bootcamp Training Courses
This email and any attachments to it may be confidential and are intended
solely for the use of the individual to whom it is addressed. Any views or
opinions expressed are solely those of the author and do not necessarily
represent those of Shape Blue Ltd or related companies. If you are not the
intended recipient of this email, you must neither take any action based upon
its contents, nor copy or show it to anyone. Please contact the sender if you
believe you have received this email in error. Shape Blue Ltd is a company
incorporated in England Wales. ShapeBlue Services India LLP is a company
incorporated in India and is operated under license from Shape Blue Ltd.
Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is
operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company
registered by The Republic of South Africa and is traded under license from
Shape Blue Ltd. ShapeBlue is a registered trademark.
Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +91 88 262 30892 | rohit.ya...@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab
Find
RE: [Propose] Improvements in XenServer + ACS integration
Thanks for showing me this at the conference, Marco.
I like the idea of authenticated users, but I haven't understood the role of
the XenServer plugin here. Only a pool admin can call Host.call_plugin, and
pool admins have the same permissions as root, so the plugin can't convey any
additional privileges and I don't see how it acts as a security layer. In
general, I think we should move away from XenServer plugins (and Alex Huang
already made some steps in this direction at the beginning of the year). The
problem with plugins is that if XenServer changes, it may break the plugin, and
we will have to scramble to fix it up when we notice.
You also mentioned xenstore: I would certainly caution against using that,
because it's not supposed to be a public interface.
I guess my philosophy is that we should treat XenServer as a black box as much
as possible, accessible only through the public API. (Of course,
Host.call_plugin is an API call, but you know what I mean). Just because we
know that dom0 is just a Linux box and we can do anything, doesn't mean that
that's good architecture. XenCenter only uses the public API, for example. And
if the public API doesn't provide something we really need, we should advocate
to the upstream project to change it, or even submit a patch as XenServer is
open source too.
--
Stephen Turner
-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: 24 November 2014 08:44
To: dev@cloudstack.apache.org
Subject: Re: [Propose] Improvements in XenServer + ACS integration
Great idea and work Marco!
The gist of the proposal is that we can allow non-root users to add hosts and
Marco successfully shows us how that is possible.
On 23-Nov-2014, at 5:42 pm, Marco Sinhoreli marco.sinhor...@shapeblue.com
wrote:
Hi community,
I'm starting this discussion to share some ideas about XenServer integration
in ACS. Since XenServer has some nice features to do that like RBAC, host
plugin and XenStore, I demonstrate these to some community members at CCCEU14.
Some references you can look in these links:
https://blog.xenproject.org/2011/11/09/xcp-rbac-and-pam-authentication
-in-the-xenapi/ https://wiki.xenserver.org/index.php?title=RBAC
http://wiki.xen.org/wiki/XAPI_Host_Plugins
http://wiki.xen.org/wiki/XenStore
Actual status in ACS:
During the XenServer setup, is possible to define a user to connect to the
xapi. In XenCenter, is possible to use a different user (no-root) using
external authentication like AD our PAM since the RBAC is configured properly
for this. In ACS it's not possible because many command need be called by
root using SSH. Another issue in this approach is about security: root
password is stored in DB and, in this approach we have a security compliance
issue. The root used used to call shell scripts in the XenServer host are all
hard-coded.
What we can do?
- Substitute host SSH connection to XAPI host plugins In my view, I
prefer use just one-way to connect to XenServer, in this case, changing host
SSH interactions to use exclusively XAPI. XAPI implements Host Plugins where
could be used to as a security layer to call commands into host.
An example of host plugin:
# cat xen_plugin_demo
#!/usr/bin/python
import XenAPIPlugin
import subprocess
def main(session, args):
try:
p = subprocess.Popen(args[cmd].split( ), stdout=subprocess.PIPE,
stderr=subprocess.PIPE) out, err = p.communicate()
return out
except KeyError:
raise RuntimeError(No argument found with key.)
if __name__ == __main__:
XenAPIPlugin.dispatch({main: main})
And a client:
$ cat call_plugin.py
import XenAPI
import sys
session =
XenAPI.Session('https://secure-web.cisco.com/11oaIT0CArnYayDlQLndB8lR7
lQ49gVxf2sio9aLIq1ZY2HcalTSEU-sxMWIGBtez69UyOkhjgoSY99b9P1H6x2vKiMGr79
TzSNVYdOK6BkY9mgKMi7MzA4LLWJmuMWocGWgyzznE_PdtwBz0xBzr3DuVUqw_OGIWtIDN
Gb6O0HA/https%3A%2F%2F192.168.56.12')
session.login_with_password('cloud', 'password') host, =
session.xenapi.host.get_all()
print
print session.xenapi.host.call_plugin(host, 'xen_plugin_demo', 'main',
{'cmd' : .join(sys.argv[1:])})
Calling:
$ python call_plugin.py ls /root
add_roles.sh
support.tar.bz2
- Setup RBAC to use a non-root to manage the XenServer host As a
suggestion, for this approach, need to have a user pre-seted in PAM or
configure XenServer AD. Follow what need be running in the XenServer shell to
setup the user, external auth, associate RBAC role to this user:
adduser cloudstack
password cloudstack
xe pool-enable-external-auth auth-type=PAM config:user=cloudstack
service-name=CloudStack xe subject-add subject-name=cloudstack
subject_uuid=$(xe subject-list | awk '/^uuid/{print $5}')
role_uuid=$(xe role-list name=pool-admin params=uuid | awk
'/^uuid/{print $5}') xe subject-role-add uuid=${subject_uuid}
role-uuid=${role_uuid}
We can in this case, maintain the scripts used today
Re: [Propose] Improvements in XenServer + ACS integration
Hi Stephen:
Thank you for yours comments! I understand your worry about host.plugins
and agree but, compared with the actual ACS approach where shell scripts
are used over ssh to call root commands inside XenServer, it represents an
better one. My worry is about to store root password in the ACS DB where
people not authorized can revert the md5sum applied and then connect
directly to the server and run anything. An great approach is limit the
commands called by host.plugins using the sudo. About xenstore, it's only
an another way share informations (or use it as semaphore) to some agent
running in the system VMs for example not as a public interface.
Marco Sinhoreli
Consultant Manager
Phone: +55 21 2586 6390 | Fax: +55 21 2586 6002 | Mobile: +55 21 98276
3636 | Mobile: +55 21 99711 4645
Praia de Botafogo 501, bloco 1 - sala 101, Botafogo, Rio de Janeiro, RJ -
Brazil - CEP 22250-040
marco.sinhor...@shapeblue.com | www.shapeblue.com
http://www.shapeblue.com/ | Twitter:@shapeBlue
https://twitter.com/#!/shapeblue
On 24/11/14 08:51, Stephen Turner stephen.tur...@citrix.com wrote:
Thanks for showing me this at the conference, Marco.
I like the idea of authenticated users, but I haven't understood the role
of the XenServer plugin here. Only a pool admin can call
Host.call_plugin, and pool admins have the same permissions as root, so
the plugin can't convey any additional privileges and I don't see how it
acts as a security layer. In general, I think we should move away from
XenServer plugins (and Alex Huang already made some steps in this
direction at the beginning of the year). The problem with plugins is that
if XenServer changes, it may break the plugin, and we will have to
scramble to fix it up when we notice.
You also mentioned xenstore: I would certainly caution against using
that, because it's not supposed to be a public interface.
I guess my philosophy is that we should treat XenServer as a black box as
much as possible, accessible only through the public API. (Of course,
Host.call_plugin is an API call, but you know what I mean). Just because
we know that dom0 is just a Linux box and we can do anything, doesn't
mean that that's good architecture. XenCenter only uses the public API,
for example. And if the public API doesn't provide something we really
need, we should advocate to the upstream project to change it, or even
submit a patch as XenServer is open source too.
--
Stephen Turner
-Original Message-
From: Rohit Yadav [mailto:rohit.ya...@shapeblue.com]
Sent: 24 November 2014 08:44
To: dev@cloudstack.apache.org
Subject: Re: [Propose] Improvements in XenServer + ACS integration
Great idea and work Marco!
The gist of the proposal is that we can allow non-root users to add hosts
and Marco successfully shows us how that is possible.
On 23-Nov-2014, at 5:42 pm, Marco Sinhoreli
marco.sinhor...@shapeblue.com wrote:
Hi community,
I'm starting this discussion to share some ideas about XenServer
integration in ACS. Since XenServer has some nice features to do that
like RBAC, host plugin and XenStore, I demonstrate these to some
community members at CCCEU14.
Some references you can look in these links:
https://blog.xenproject.org/2011/11/09/xcp-rbac-and-pam-authentication
-in-the-xenapi/ https://wiki.xenserver.org/index.php?title=RBAC
http://wiki.xen.org/wiki/XAPI_Host_Plugins
http://wiki.xen.org/wiki/XenStore
Actual status in ACS:
During the XenServer setup, is possible to define a user to connect to
the xapi. In XenCenter, is possible to use a different user (no-root)
using external authentication like AD our PAM since the RBAC is
configured properly for this. In ACS it's not possible because many
command need be called by root using SSH. Another issue in this approach
is about security: root password is stored in DB and, in this approach
we have a security compliance issue. The root used used to call shell
scripts in the XenServer host are all hard-coded.
What we can do?
- Substitute host SSH connection to XAPI host plugins In my view, I
prefer use just one-way to connect to XenServer, in this case, changing
host SSH interactions to use exclusively XAPI. XAPI implements Host
Plugins where could be used to as a security layer to call commands into
host.
An example of host plugin:
# cat xen_plugin_demo
#!/usr/bin/python
import XenAPIPlugin
import subprocess
def main(session, args):
try:
p = subprocess.Popen(args[cmd].split( ), stdout=subprocess.PIPE,
stderr=subprocess.PIPE) out, err = p.communicate()
return out
except KeyError:
raise RuntimeError(No argument found with key.)
if __name__ == __main__:
XenAPIPlugin.dispatch({main: main})
And a client:
$ cat call_plugin.py
import XenAPI
import sys
session =
XenAPI.Session('https://secure-web.cisco.com/11oaIT0CArnYayDlQLndB8lR7
lQ49gVxf2sio9aLIq1ZY2HcalTSEU-sxMWIGBtez69UyOkhjgoSY99b9P1H6x2vKiMGr79
TzSNVYdOK6BkY9mgKMi7MzA4LLWJmuMWocGWgyzznE_PdtwBz0xBzr3DuVUqw_OGIWtIDN
