Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Hopper, Justin]

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"  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"  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
>> >>
>

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Day, Phil]

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

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Day, Phil]

Its more than just non-admin,  it also allows a user to lock an instance so 
that they don’t accidentally perform some operation on a VM.

At one point it was (by default) an admin only operation on the OSAPI, but its 
always been open to all users in EC2.   Recently it was changed so that admin 
and non-admin locks are considered as separate things.

From: Chen CH Ji [mailto:jiche...@cn.ibm.com]
Sent: 08 April 2014 07:13
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature


the instance lock is a mechanism that prevent non-admin user to operate on the 
instance (resize, etc, looks to me snapshot is not currently included)
the permission is a wider concept that major in API layer to allow or prevent 
user in using the API , guess instance lock might be enough for prevent 
instance actions .


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: 
jiche...@cn.ibm.com<mailto:jiche...@cn.ibm.com>
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, 
Beijing 100193, PRC

[Inactive hide details for "Hopper, Justin" ---04/08/2014 02:05:02 PM---Phil, I 
am reviewing the existing “check_instance_lock]"Hopper, Justin" ---04/08/2014 
02:05:02 PM---Phil, I am reviewing the existing “check_instance_lock” 
implementation to see

From: "Hopper, Justin" mailto:justin.hop...@hp.com>>
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>,
Date: 04/08/2014 02:05 PM
Subject: Re: [openstack-dev] [Nova][Trove] Managed Instances Feature





Phil,

I am reviewing the existing “check_instance_lock” implementation to see
how it might be leveraged.  Off the cuff, it looks pretty much what we
need.  I need to look into the permissions to better understand how one
can “lock” and instance.

Thanks for the guidance.


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




On 4/7/14, 10:01, "Day, Phil" mailto: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: EA238

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Chen CH Ji]

the instance lock is a mechanism that prevent non-admin user to operate on
the instance (resize, etc, looks to me snapshot is not currently included)
the permission is a wider concept that major in API layer to allow or
prevent user in using the API , guess instance lock might be enough for
prevent instance actions .


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82454158
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   "Hopper, Justin" 
To: "OpenStack Development Mailing List (not for usage questions)"
,
Date:   04/08/2014 02:05 PM
Subject:        Re: [openstack-dev] [Nova][Trove] Managed Instances Feature



Phil,

I am reviewing the existing “check_instance_lock” implementation to see
how it might be leveraged.  Off the cuff, it looks pretty much what we
need.  I need to look into the permissions to better understand how one
can “lock” and instance.

Thanks for the guidance.


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




On 4/7/14, 10:01, "Day, Phil"  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"  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 In

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Hopper, Justin]

Phil,

I am reviewing the existing “check_instance_lock” implementation to see
how it might be leveraged.  Off the cuff, it looks pretty much what we
need.  I need to look into the permissions to better understand how one
can “lock” and instance.

Thanks for the guidance.


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




On 4/7/14, 10:01, "Day, Phil"  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"  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Š
>>

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Hopper, Justin]

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"  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"  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.
>> >> 

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Day, Phil]

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"  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 th

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Russell Bryant]

On 04/06/2014 03:22 PM, Vipul Sabhaya wrote:
> 
> 
> 
> On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant  > wrote:
> 
> On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
> > On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin
> mailto:justin.hop...@hp.com>
> > >> wrote:
> >
> > Russell,
> >
> > 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.
> >
> >
> > Are you looking for something to prevent accidental manipulation of an
> > instance created by Trove or intentional changes as well? Whilst doing
> > some filtering in nova list is simple on the surface, we don't try to
> > keep server uuids secret in the API, so its likely that sort of
> > information will leak through other parts of the API say through
> volume
> > or networking interfaces. Having to enforce another level of
> permissions
> > throughout the API would be a considerable change. Also it would
> > introduce inconsistencies into the information returned by Nova - eg
> > does quota/usage information returned to the user include the server
> > that Trove created or is that meant to be adjusted as well?
> >
> > If you need a high level of support from the Nova API to hide servers,
> > then if its possible, as Russell suggests to get what you want by
> > building on top of the Nova API using additional identities then I
> think
> > that would be the way to go. If you're just looking for a simple
> way to
> > offer to Trove clients a filtered list of servers, then perhaps Trove
> > could offer a server list call which is a proxy to Nova and
> filters out
> > the servers which are Trove specific since Trove knows which ones it
> > created.
> 
> Yeah, I would *really* prefer to go the route of having trove own all
> instances from the perspective of Nova.  Trove is what is really
> managing these instances, and it already has to keep track of what
> instances are associated with which user.
> 
> Although this approach would work, there are some manageability issues
> with it.  When trove is managing 100’s of nova instances, then things
> tend to break down when looking directly at the Trove tenant through the
> Nova API and trying to piece together the associations, what resource
> failed to provision, etc.

This isn't specific enough to understand what the problem is.

> It sounds like what you really want is for Trove to own the instances,
> so I think we need to get down to very specifically won't work with that
> approach.
> 
> For example, is it a billing thing?  As it stands, all notifications for
> trove managed instances will have the user's info in them.  Do you not
> want to lose that?  If that's the problem, that seems solvable with a
> much simpler approach.
> 
> 
> We have for the most part solved the billing issue since Trove does
> maintain the association, and able to send events on-behalf of the
> correct user.  We would lose out on the additional layer of checks that
> Nova provides, such as Rate Limiting per project, Quotas enforced at the
> Nova layer.  The trove tenant would essentially need full access without
> any such limits.

Don't you get rate limiting and quotas through the trove API, instead?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Vipul Sabhaya]

On Sun, Apr 6, 2014 at 9:36 AM, Russell Bryant  wrote:

> On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
> > On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin  > > wrote:
> >
> > Russell,
> >
> > 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.
> >
> >
> > Are you looking for something to prevent accidental manipulation of an
> > instance created by Trove or intentional changes as well? Whilst doing
> > some filtering in nova list is simple on the surface, we don't try to
> > keep server uuids secret in the API, so its likely that sort of
> > information will leak through other parts of the API say through volume
> > or networking interfaces. Having to enforce another level of permissions
> > throughout the API would be a considerable change. Also it would
> > introduce inconsistencies into the information returned by Nova - eg
> > does quota/usage information returned to the user include the server
> > that Trove created or is that meant to be adjusted as well?
> >
> > If you need a high level of support from the Nova API to hide servers,
> > then if its possible, as Russell suggests to get what you want by
> > building on top of the Nova API using additional identities then I think
> > that would be the way to go. If you're just looking for a simple way to
> > offer to Trove clients a filtered list of servers, then perhaps Trove
> > could offer a server list call which is a proxy to Nova and filters out
> > the servers which are Trove specific since Trove knows which ones it
> > created.
>
> Yeah, I would *really* prefer to go the route of having trove own all
> instances from the perspective of Nova.  Trove is what is really
> managing these instances, and it already has to keep track of what
> instances are associated with which user.
>
> Although this approach would work, there are some manageability issues
with it.  When trove is managing 100's of nova instances, then things tend
to break down when looking directly at the Trove tenant through the Nova
API and trying to piece together the associations, what resource failed to
provision, etc.


> It sounds like what you really want is for Trove to own the instances,
> so I think we need to get down to very specifically won't work with that
> approach.
>
> For example, is it a billing thing?  As it stands, all notifications for
> trove managed instances will have the user's info in them.  Do you not
> want to lose that?  If that's the problem, that seems solvable with a
> much simpler approach.
>
>
We have for the most part solved the billing issue since Trove does
maintain the association, and able to send events on-behalf of the correct
user.  We would lose out on the additional layer of checks that Nova
provides, such as Rate Limiting per project, Quotas enforced at the Nova
layer.  The trove tenant would essentially need full access without any
such limits.

Since we'd prefer to keep these checks at the Infrastructure layer intact
for Users that interact with the Trove API, I think the issue goes beyond
just filtering them out from the API.

One idea that we've floated around is possibly introducing a 'shadow'
tenant, that allows Services like Trove to create Nova / Cinder / Neutron
resources on behalf of the actual tenant.  The resources owned by this
shadow tenant would only be visible / manipulated by a higher-level
Service.  This could require some Service token to be provided along with
the original tenant token.

Example: POST /v2/{shadow_tenant_id}/servers


> --
> 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

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Russell Bryant]

On 04/06/2014 09:02 AM, Christopher Yeoh wrote:
> On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin  > wrote:
> 
> Russell,
> 
> 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.
> 
> 
> Are you looking for something to prevent accidental manipulation of an
> instance created by Trove or intentional changes as well? Whilst doing
> some filtering in nova list is simple on the surface, we don't try to
> keep server uuids secret in the API, so its likely that sort of
> information will leak through other parts of the API say through volume
> or networking interfaces. Having to enforce another level of permissions
> throughout the API would be a considerable change. Also it would
> introduce inconsistencies into the information returned by Nova - eg
> does quota/usage information returned to the user include the server
> that Trove created or is that meant to be adjusted as well?
> 
> If you need a high level of support from the Nova API to hide servers,
> then if its possible, as Russell suggests to get what you want by
> building on top of the Nova API using additional identities then I think
> that would be the way to go. If you're just looking for a simple way to
> offer to Trove clients a filtered list of servers, then perhaps Trove
> could offer a server list call which is a proxy to Nova and filters out
> the servers which are Trove specific since Trove knows which ones it
> created.

Yeah, I would *really* prefer to go the route of having trove own all
instances from the perspective of Nova.  Trove is what is really
managing these instances, and it already has to keep track of what
instances are associated with which user.

It sounds like what you really want is for Trove to own the instances,
so I think we need to get down to very specifically won't work with that
approach.

For example, is it a billing thing?  As it stands, all notifications for
trove managed instances will have the user's info in them.  Do you not
want to lose that?  If that's the problem, that seems solvable with a
much simpler approach.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Christopher Yeoh]

On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin wrote:

> Russell,
>
> 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.
>
>
Are you looking for something to prevent accidental manipulation of an
instance created by Trove or intentional changes as well? Whilst doing some
filtering in nova list is simple on the surface, we don't try to keep
server uuids secret in the API, so its likely that sort of information will
leak through other parts of the API say through volume or networking
interfaces. Having to enforce another level of permissions throughout the
API would be a considerable change. Also it would introduce inconsistencies
into the information returned by Nova - eg does quota/usage information
returned to the user include the server that Trove created or is that meant
to be adjusted as well?

If you need a high level of support from the Nova API to hide servers, then
if its possible, as Russell suggests to get what you want by building on
top of the Nova API using additional identities then I think that would be
the way to go. If you're just looking for a simple way to offer to Trove
clients a filtered list of servers, then perhaps Trove could offer a server
list call which is a proxy to Nova and filters out the servers which are
Trove specific since Trove knows which ones it created.

Chris


> Thanks,
>
> Justin Hopper
> Software Engineer - DBaaS
> irc: juice | gpg: EA238CF3 | twt: @justinhopper
>
>
>
>
> On 4/5/14, 14:20, "Russell Bryant"  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

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Hopper, Justin]

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"  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


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

Re: [openstack-dev] [Nova][Trove] Managed Instances Feature

[Russell Bryant]

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] [Nova][Trove] Managed Instances Feature

[Hopper, Justin]

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.

Thanks, 

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




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