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
> 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, S
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
> 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
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" 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 >> 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
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" 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 >> 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 authentic
