Open Stack

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