[openstack-dev] [Glance][Keystone] Glance and trusts

stuart.mclaren at hp.com stuart.mclaren at hp.com
Mon Jun 8 09:40:11 UTC 2015


>> On Jun 5, 2015, at 19:25, Bhandaru, Malini K <malini.k.bhandaru at intel.com> wrote:
>>
>> Continuing with David?s example and the need to control access to a Swift object that Adam points out,
>>
>> How about using the Glance token from glance-API service to glance-registry but carry along extra data in the call, namely user-id, domain, and public/private information, so the object can be access controlled.
>>
>> Alternately and encapsulating token
>>
>> <Glance-token <user-token>> -- keeping it simple, only two levels.  This protects from on the cusp expired user-tokens.
>> Could check user quota before attempting the storage.
>
> We already went over this type of design and determined it was sub-optimal. Instead we allow for passing the X-SERVICE-TOKEN, which is being passed in addition to the auth token.
> Right now I do not believe that X-SERVICE-TOKEN is being used anywhere.

Support was recently added to the Swift server. (Glance -> Swift support should land in Liberty.)

> In the near future we are looking to make all inter-service (e.g. Nova ->glance) communication have the service token.
>
> This design was specifically implemented for the case you're describing.
>
> In theory it would be possible to allow the quota check / read with only a service token (and a proper policy.json) but would require the user's token to do writes.
>
>
>>
>> Should user not have paid dues, Glance knows which objects to garbage collect!
>>
>> Regards
>> Malini
>>
>> From: Adam Young [mailto:ayoung at redhat.com]
>> Sent: Friday, June 05, 2015 4:11 PM
>> To: openstack-dev at lists.openstack.org
>> Subject: Re: [openstack-dev] [Glance][Keystone] Glance and trusts
>>
>> On 06/05/2015 10:39 AM, Dolph Mathews wrote:
>>
>> On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick <d.w.chadwick at kent.ac.uk> wrote:
>> I did suggest another solution to Adam whilst we were in Vancouver, and
>> this mirrors what happens in the real world today when I order something
>> from a supplier and a whole supply chain is involved in creating the end
>> product that I ordered. This is not too dissimilar to a user requesting
>> a new VM. Essentially each element in the supply chain trusts the two
>> adjacent elements. It has contracts with both its customers and its
>> suppliers to define the obligations of each party. When something is
>> ordered from it, it trusts the purchaser, and on the strength of this,
>> it will order from its suppliers. Each element may or may not know who
>> the original customer is, but if it needs to know, it trusts the
>> purchaser to tell it. Furthermore the customer does not need to delegate
>> any of his/her permissions to his/her supplier. If we used such a system
>> of trust between Openstack services, then we would not need delegation
>> of authority and "trusts" as they are implemented today. It could
>> significantly simplify the interactions between OpenStack services.
>>
>> +1! I feel like this is the model that we started with in OpenStack, and have grown additional complexity over time without much benefit.
>>
>> We could roll Glance into Nova, too, and get the same benefit.  There is a reason we have separate services.  GLance shoud not Trust Nova for all operations, just some.
>>
>> David's example elides the fact that there  are checks built in to the supply chain system to prevent cheating.
>>
>>
>>
>>
>>
>>
>>
>> regards
>> David
>>
>> On 03/06/2015 21:03, Adam Young wrote:
>>> On 06/02/2015 12:57 PM, Mikhail Fedosin wrote:
>>>> Hello! I think it's a good time to discuss implementation of trusts in
>>>> Glance v2 and v3 api.
>>>>
>>>> Currently we have two different situations during image creation where
>>>> our token may expire, which leads to unsuccessful operation.
>>>>
>>>> First is connection between glance-api and glance-registry. In this
>>>> case we have a solution (https://review.openstack.org/#/c/29967/) -
>>>> use_user_token parameter in glance-api.conf, but it is True by default
>>>> . If it's changed to False then glance-api will use its own
>>>> credentials to authorize in glance-registry and it prevents many
>>>> possible issues with user token expiration. So, I'm interested if
>>>> there are some performance degradations if we change use_user_token to
>>>> False and what are the reasons against making it the default value.
>>>>
>>>> Second one is linked with Swift. Current implementation uploads chunks
>>>> one by one and requires authorization each time. It may lead to
>>>> problems: for example we have to upload 100 chunks, after 99th one,
>>>> token expired and glance can't upload the last one, catches an
>>>> exception and tries to remove stale chunks from storage. Of course it
>>>> will fail, because token is not valid anymore, and that's why there
>>>> will be 99 garbage objects in the storage.
>>>> With Single-tenant mode glance uses its own credentials to upload
>>>> files, so it's possible to create new connection on each chunk upload
>>>> or catch Unauthorized exception and recreate connections only in that
>>>> cases. But with Multi-tenant mode there is no way to do it, because
>>>> user credentials are required. So it seems that trusts is the only one
>>>> solution here.
>>> The problem with using trusts is that it would need to be created
>>> per-user, and that is going to be expensive.  It would be possible, as
>>> Heat does something of this nature:
>>>
>>> 1. User calls glance,
>>> 2. Glance creates a trust with some limitation, either time or number of
>>> uses
>>> 3.  Trusts are used for all operations with swift.
>>> 4. Glance should clean up the trust when it is complete.
>>>
>>> I don't love the solution, but I think it is the best we have.  Ideally
>>> the user would opt in to the trust, but in this case, it is kindof
>>> implicit by them calling the API.
>>>
>>>
>>> We should limit the trust creation to only have those roles (or a
>>> subset) on the token used to create the trust.
>>>
>>>
>>>
>>>
>>>> I would be happy to hear your opinions on that matter. If you know
>>>> other situations where trusts are useful or some other approaches
>>>> please share.
>>>>
>>>> Best regards,
>>>> Mike Fedosin
>>>>
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> OpenStack Development Mailing List (not for usage questions)
>>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150606/20b20ca2/attachment-0001.html>
>
> ------------------------------



More information about the OpenStack-dev mailing list