Open Stack

Hi Phil,

I spent some time this afternoon looking this over and testing it out.
Currently Trove does have “admim” role in Nova (per Devstack) and there is
a Trove-Admin API that currently requires this.  I suppose this level of
authority may be overreaching in certain deployments.  If so then a new
Role with hierarchy would be necessary.  It looks like it would only
complicate “check_instance_lock” slightly more than it is today.  First by
also accessing the “locked_by” attribute in Instance and secondly by
checking the context token role to see if it meets or exceeds the current
“locked_by” level.

This is looking very promising for our use case.  So much that we would
like to see it extended to Security Groups :)

Thanks,

Justin Hopper
Software Engineer - DBaaS
irc: juice | gpg: EA238CF3 | twt: @justinhopper




On 4/8/14, 3:40, "Day, Phil" <philip.day at hp.com> wrote:

>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
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5441 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140408/e16b3707/attachment.bin>