Hi Thomas/Olivier,
thanks for the replies. I have found a way to do sufficient UBAC (User
Based Access Control) using the features in XenServer itself (although, I
do need to use 6.2 or 6.5 - I'll explain in a bit). What I have done is to
use PAM authentication w/ a unix/linux user created on the XenServer
itself. Once I set up PAM, what I do is create a linux user called User1,
and then create a subject using User1. After that, I set the role to only
read-only, and host.call_plugin. At this time, the subject is allowed to
run only these two commands.
The model that we have, is that there are multiple control VMs w/ a
hostname, that need to create objects (network, vbd/vif, other VMs) such
that the operations being executed from said control VM can operate only on
objects that "belong" to it on the XenServer. So, what I do is encrypt the
arguments to the host-plugin using openssl asymetric encryption, so that it
can identify who it is, and then I save the hostname of the control VM in
either the description or other-config based on what kind of an object I'm
creating on XenServer. This does address the needs that I have.
However, what I have found, is that the licensing on XenServer 6.0.2
doesn't seem to be unrestricted for some commands
(subject-role-add/subject-role-remove) as it is on Xenserver 6.2 and 6.5.
Is this something that either of you, or somebody on the list is familiar
w/? The specific error that I receive is as follows :
[root@XenServer ~]# xe subject-role-remove
uuid=3e34169d-e0ac-a1ba-8b3a-86237342db51 role-name=pool-admin
This operation is not allowed under your license. Please contact your
support representative.
[root@XenServer ~]#
This is even though the installation says that it is xenenterprise. The
license does say that it is 'Citrix XenServer'. Am I missing something?
Regards,
Shiva
On Wed, Feb 25, 2015 at 6:16 AM, Thomas Sanders <thomas.sanders@citrix.com>
wrote:
> Cloudstack/Cloudplatform does something like this.
>
> XenServer itself doesn't have the necessary information in the datamodel:
> a VM doesn't have an "owner". Therefore XenServer's existing RBAC feature
> can't do what you want at present.
>
> It might be less work to add the feature to XenServer than to implement it
> by writing new gateway software that mediates between the users and
> XenServer... but it sounds as if Olivier is adding it to his existing
> gateway/mediator software Xen-Orchestra.
>
>
> > -----Original Message-----
> > From: xen-api-bounces@lists.xen.org [mailto:
> xen-api-bounces@lists.xen.org]
> > On Behalf Of Olivier Lambert
> > Sent: 25 February 2015 12:12 PM
> > To: Shiva Bhanujan
> > Cc: xen-api@lists.xenproject.org
> > Subject: Re: [Xen-API] User Based Access Control
> >
> > Hi,
> >
> > https://xen-orchestra.com/blog/xo-4-x-starts-to-show-up/
> >
> > It actually works and we are in closed Beta so far. I will create a
> > small video to show you how it works.
> >
> > Should be out to the end of the month.
> >
> > Regards,
> >
> >
> > Olivier.
> >
> > On Wed, Feb 18, 2015 at 7:55 PM, Shiva Bhanujan <sxb075@gmail.com>
> wrote:
> > > Hello,
> > >
> > > I'm trying to figure out if we can have a mechanism such that when
> user A
> > > creates a VM, or a network or any object from dom0, another user B
> would
> > not
> > > have any access to objects created by user A. Is there such a
> mechanism
> > > available?
> > >
> > > I've looked at the RBAC mechanism in PAM, and Xen Orchestra, but I
> doubt
> > if
> > > they address this need. Is anybody aware of anything that might
> satisfy
> > > this need?
> > >
> > > Regards,
> > > Shiva
> > >
> > >
> > > _______________________________________________
> > > Xen-api mailing list
> > > Xen-api@lists.xen.org
> > > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
> > >
> >
> > _______________________________________________
> > Xen-api mailing list
> > Xen-api@lists.xen.org
> > http://lists.xen.org/cgi-bin/mailman/listinfo/xen-api
>