Open Stack

Hi Justin,

Glad you like the idea of using lock ;-) 

I still think you need some more granularity that user or admin - currently for Trove to lock the users  VMs as admin it would need an account that has admin rights across the board in Nova, and I don't think folks would want to delegate that much power to Trove.

Also the folks who genuinely need to enforce an admin level lock on a VM (normally if there is some security issue with the VM) wouldn’t want Trove to be able to unlock it.

So I think we're on the right lines, but needs more thinking about how to get a bit more granularity - I'm thinking of some other variant of lock that fits somewhere between the current user and admin locks, and is controlled via policy by a specific role, so you have something like:

User without AppLock role  - can apply/remove user lock to instance.    Cannot perform operations is any lock is set on the instance
User with AppLock role - can apply/remove application lock to instance.   Cannot perform operations on the instance if the admin lock is set
User with Admin role - can apply/remove admin lock.   Can perform any operations on the instance

Phil

> -----Original Message-----
> From: Hopper, Justin
> Sent: 07 April 2014 19:01
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
> 
> Phil,
> 
> I think you “lock” concept is more along the lines of what we are looking for.
> Hiding them is not a requirement.  Preventing the user from using Nova
> directly on those Instances is.  So locking it with an “Admin” user so that they
> could not snapshot, resize it directly in Nova would be great.  When they use
> the Trove API, Trove, as Admin, could “unlock” those Instances, make the
> modification and then “lock” them after it is complete.
> 
> Thanks,
> 
> Justin Hopper
> Software Engineer - DBaaS
> irc: juice | gpg: EA238CF3 | twt: @justinhopper
> 
> 
> 
> 
> On 4/7/14, 10:01, "Day, Phil" <philip.day at hp.com> wrote:
> 
> >I can see the case for Trove being to create an instance within a
> >customer's tenant (if nothing else it would make adding it onto their
> >Neutron network a lot easier), but I'm wondering why it really needs to
> >be hidden from them ?
> >
> >If the instances have a name that makes it pretty obvious that Trove
> >created them, and the user presumably knows that did this from Trove,
> why
> >hide them  ?    I'd of thought that would lead to a whole bunch of
> >confusion and support calls when they  try to work out why they are out
> >of quota and can only see subset of the instances being counted by the
> >system.
> >
> >If the need is to stop the users doing something with those instances
> >then maybe we need an extension to the lock mechanism such that a lock
> >can be made by a specific user (so the trove user in the same tenant
> >could lock the instance so that a non-trove user in that tenant
> >couldn’t unlock ).  We already have this to an extent, in that an
> >instance locked by an admin can' t be unlocked by the owner, so I don’t
> think it would be
> >too hard to build on that.   Feels like that would be a lot more
> >transparent than trying to obfuscate the instances themselves.
> >
> >> -----Original Message-----
> >> From: Hopper, Justin
> >> Sent: 06 April 2014 01:37
> >> To: OpenStack Development Mailing List (not for usage questions)
> >> Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature
> >>
> >> Russell,
> >>
> >> Thanks for the quick reply. If I understand what you are suggesting
> >>it is that  there would be one Trove-Service Tenant/User that owns all
> >>instances from  the perspective of Nova.  This was one option proposed
> >>during our  discussions.  However, what we thought would be best is to
> >>continue to use  the user credentials so that Nova has the correct
> >>association.  We wanted a  more substantial and deliberate
> >>relationship between Nova and a  dependent service.  In this
> >>relationship, Nova would acknowledge which  instances are being
> >>managed by which Services and while ownership was still  to that of
> >>the User, management/manipulation of said Instance would be  solely
> >>done by the Service.
> >>
> >> At this point the guard that Nova needs to provide around the
> >>instance does  not need to be complex.  It would even suffice to keep
> >>those instances  hidden from such operations as ³nova list² when
> >>invoked by directly by the  user.
> >>
> >> Thanks,
> >>
> >> Justin Hopper
> >> Software Engineer - DBaaS
> >> irc: juice | gpg: EA238CF3 | twt: @justinhopper
> >>
> >>
> >>
> >>
> >> On 4/5/14, 14:20, "Russell Bryant" <rbryant at redhat.com> wrote:
> >>
> >> >On 04/04/2014 08:12 PM, Hopper, Justin wrote:
> >> >> Greetings,
> >> >>
> >> >> I am trying to address an issue from certain perspectives and I
> >> >> think some support from Nova may be needed.
> >> >>
> >> >> _Problem_
> >> >> Services like Trove use run in Nova Compute Instances.  These
> >> >> Services try to provide an integrated and stable platform for
> >> >> which the ³service² can run in a predictable manner.  Such
> >> >> elements include configuration of the service, networking, installed
> packages, etc.
> >> >> In today¹s world, when Trove spins up an Instance to deploy a
> >> >> database on, it creates that Instance with the Users Credentials.
> >> >> Thus, to Nova, the User has full access to that Instance through
> >> >> Nova¹s API.  This access can be used in ways which unintentionally
> >> compromise the service.
> >> >>
> >> >> _Solution_
> >> >> A proposal is being formed that would put such Instances in a
> >> >> read-only or invisible mode from the perspective of Nova.  That
> >> >> is, the Instance can only be managed from the Service from which
> >> >> it was created.  At this point, we do not need any granular
> >> >> controls.  A simple lock-down of the Nova API for these Instances
> would suffice.
> >> >> However, Trove would still need to interact with this Instance via
> >>Nova
> >> API.
> >> >>
> >> >> The basic requirements for Nova would beŠ
> >> >>
> >> >>     A way to identify a request originating from a Service vs coming
> >> >>     directly from an end-user
> >> >>     A way to Identify which instances are being managed by a Service
> >> >>     A way to prevent some or all access to the Instance unless the
> >> >>     Service ID in the request matches that attached to the
> >> >> Instance
> >> >>
> >> >> Any feedback on this would be appreciated.
> >> >
> >> >The use case makes sense to me.  I'm thinking we should expect an
> >> >identity to be created in Keystone for trove and have trove use that
> >> >for managing all of its instances.
> >> >
> >> >If that is sufficient, trove would need some changes to use its
> >> >service credentials instead of the user credentials.  I don't think
> >> >any changes are needed in Nova.
> >> >
> >> >Is there anything missing to support your use case using that approach?
> >> >
> >> >--
> >> >Russell Bryant
> >> >
> >> >_______________________________________________
> >> >OpenStack-dev mailing list
> >> >OpenStack-dev at lists.openstack.org
> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >_______________________________________________
> >OpenStack-dev mailing list
> >OpenStack-dev at lists.openstack.org
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev