<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Apr 6, 2014 at 10:06 AM, Hopper, Justin <span dir="ltr"><<a href="mailto:justin.hopper@hp.com" target="_blank">justin.hopper@hp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Russell,<br>
<br>
At this point the guard that Nova needs to provide around the instance<br>
does not need to be complex.  It would even suffice to keep those<br>
instances hidden from such operations as ³nova list² when invoked by<br>
directly by the user.<br>
<div class=""><br></div></blockquote><div><br></div><div>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?<br>
<br>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.<br>
</div><div><br></div><div>Chris<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
Thanks,<br>
<br>
Justin Hopper<br>
Software Engineer - DBaaS<br>
irc: juice | gpg: EA238CF3 | twt: @justinhopper<br>
<br>
<br>
<br>
<br>
</div><div class="">On 4/5/14, 14:20, "Russell Bryant" <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br>
<br>
>On 04/04/2014 08:12 PM, Hopper, Justin wrote:<br>
>> Greetings,<br>
>><br>
>> I am trying to address an issue from certain perspectives and I think<br>
>> some support from Nova may be needed.<br>
>><br>
>> _Problem_<br>
>> Services like Trove use run in Nova Compute Instances.  These Services<br>
>> try to provide an integrated and stable platform for which the ³service²<br>
>> can run in a predictable manner.  Such elements include configuration of<br>
>> the service, networking, installed packages, etc.  In today¹s world,<br>
>> when Trove spins up an Instance to deploy a database on, it creates that<br>
>> Instance with the Users Credentials.  Thus, to Nova, the User has full<br>
>> access to that Instance through Nova¹s API.  This access can be used in<br>
>> ways which unintentionally compromise the service.<br>
>><br>
>> _Solution_<br>
>> A proposal is being formed that would put such Instances in a read-only<br>
>> or invisible mode from the perspective of Nova.  That is, the Instance<br>
>> can only be managed from the Service from which it was created.  At this<br>
>> point, we do not need any granular controls.  A simple lock-down of the<br>
>> Nova API for these Instances would suffice.  However, Trove would still<br>
>> need to interact with this Instance via Nova API.<br>
>><br>
</div>>> The basic requirements for Nova would beŠ<br>
<div class="HOEnZb"><div class="h5">>><br>
>>     A way to identify a request originating from a Service vs coming<br>
>>     directly from an end-user<br>
>>     A way to Identify which instances are being managed by a Service<br>
>>     A way to prevent some or all access to the Instance unless the<br>
>>     Service ID in the request matches that attached to the Instance<br>
>><br>
>> Any feedback on this would be appreciated.<br>
><br>
>The use case makes sense to me.  I'm thinking we should expect an<br>
>identity to be created in Keystone for trove and have trove use that for<br>
>managing all of its instances.<br>
><br>
>If that is sufficient, trove would need some changes to use its service<br>
>credentials instead of the user credentials.  I don't think any changes<br>
>are needed in Nova.<br>
><br>
>Is there anything missing to support your use case using that approach?<br>
><br>
>--<br>
>Russell Bryant<br>
><br>
>_______________________________________________<br>
>OpenStack-dev mailing list<br>
><a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>