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....@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....@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" <rbry...@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@lists.openstack.org >> >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >_______________________________________________ >> >OpenStack-dev mailing list >> >OpenStack-dev@lists.openstack.org >> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >_______________________________________________ >OpenStack-dev mailing list >OpenStack-dev@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev