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

[Adam Young]

On 06/08/2015 02:10 PM, Steve Lewis wrote:

Monday, June 8, 2015 07:10, Adam Young wrote:

2.  Delegation are long lived affairs.  If anything is going to take
longer than the duration of the token, it should be in the context of a
delegation, and the user should re-authenticate to prove identity.

Requiring re-authenticating to perform many tasks that involves delegation (a 
distinction that users don't understand, or care to) is a sure way to convince 
users to use short and weak passwords. Please, no.
Requiring re-authentication is not the same as requireing the user to 
retype their password.  The Users agent re-authenticates, not the user 
him/herself.  In the case of the CLI, that is using Env Vars, and in the 
case of Horizon, it is using the unscoped token that the user has in 
their session.  For Service users, it should be X509 or Kerberos, but it 
will be the service password.  Don't confuse the one with the other, please.







__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[David Chadwick]

I agree, there are two very different models for getting a third party
to do something for you: delegation oF authority and sub-contracting.
Your examples of the kids at daycare and buying something online neatly
show up the differences between the two models. So lets be sure we use
the right model for the right task. Using the wrong model will lead to
either over complication (DoA when subcontracting is sufficient) or
security vulnerability (subcontracting when DoA is needed)

regards

David

On 08/06/2015 15:10, Adam Young wrote:
> On 06/06/2015 06:00 AM, David Chadwick wrote:
>> In order to do this fully, you will need to work out what all the
>> possible supply chains are in OpenStack, so that when any customer
>> starts any chain of events, there is sufficient information in the
>> message passed to the supplier that allows that supplier to order from
>> its supplier. This has to be ensured all the way down the chain, so that
>> important information that one supplier needs was not omitted by a
>> previous supplier higher up the chain. I suspect that the name of the
>> initial requestor (at least) will need to be passed all the way down the
>> chain.
> Yes, I think so.  This is in keeping with how I understand we need to
> unify delegation across Keystone constructs.
> 
> 1.  Tokens live too long.  They should be short and ephemeral, and if a
> user needs a new one to complete an action, getting one should be
> trivial.  They should be bound to the endpoint that is the target of the
> operation.  5 minutes makes sense as a length of life, as that is
> essentially "now"  when you factor in clock skew. Revocations on tokens
> to not make sense.
> 
> 2.  Delegation are long lived affairs.  If anything is going to take
> longer than the duration of the token, it should be in the context of a
> delegation, and the user should re-authenticate to prove identity. 
> Delegations need to be focused on workflow, not "all operations ther
> user can do"  which means that the Glance case discussed here is a good
> start of documenting "what do you need to get this job done?"
> 
> 
> We need to keep it light (not fill up a database) for normal operations,
> but maintain the chain of responsibility on a given operation.  Trusts
> are the closest thing we have to this model.
> 
> In the supply chain example, if one company exchanges a good with
> another company, they don't care about the end user, because there is no
> realy connection between the good and the user yet;   if there is a
> problem, the original manufacterur can produce  another car identical to
> the first and replace it without the user being any the wiser.
> 
> Contrast this with picking kids up from daycare:  as a parent, I have to
> sign a form saying that my mother-in-law will be picking up the kids on
> a specific day.  My Mother-in-law is not authorized to sign a form that
> will allow her friend to pick the kids up.  My kids are very, very
> specific to me, and should be carefully handed off from approved
> supervisor to approved supervisor.
> 
> Fetching an image from Glance may well be a causal or a protected
> operation, depending on the image.
> 
> Casual if it is a global image: anyone in the world can do it, so no big
> deal.
> 
> Protected if, for example, the image is pre-populated with an enrollment
> secret.  Only the owners should be able to get at it
> 
> 
> 
>>
>> regards
>>
>> David
>>
>> On 06/06/2015 03:25, Bhandaru, Malini K 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
>>>
>>>  
>>> > -- keeping it simple, only two levels.  This
>>> protects from on the cusp expired user-tokens.
>>>
>>> Could check user quota before attempting the storage.
>>>
>>>  
>>> Should user not have paid dues, Glance knows which objects to garbage
>>> collect!
>>>
>>>  
>>> Regards
>>>
>>> Malini
>>>
>>>  
>>> *From:*Adam Young [mailto:ayo...@redhat.com]
>>> *Sent:* Friday, June 05, 2015 4:11 PM
>>> *To:* openstack-dev@lists.openstack.org
>>> *Subject:* Re: [openstack-dev] [Glance][Keystone] Glance and trusts
>>>
>>>  
>>&

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

[Steve Lewis]

Monday, June 8, 2015 07:10, Adam Young wrote:
> 2.  Delegation are long lived affairs.  If anything is going to take
> longer than the duration of the token, it should be in the context of a
> delegation, and the user should re-authenticate to prove identity.

Requiring re-authenticating to perform many tasks that involves delegation (a 
distinction that users don't understand, or care to) is a sure way to convince 
users to use short and weak passwords. Please, no.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

On 06/06/2015 06:00 AM, David Chadwick wrote:

In order to do this fully, you will need to work out what all the
possible supply chains are in OpenStack, so that when any customer
starts any chain of events, there is sufficient information in the
message passed to the supplier that allows that supplier to order from
its supplier. This has to be ensured all the way down the chain, so that
important information that one supplier needs was not omitted by a
previous supplier higher up the chain. I suspect that the name of the
initial requestor (at least) will need to be passed all the way down the
chain.
Yes, I think so.  This is in keeping with how I understand we need to 
unify delegation across Keystone constructs.


1.  Tokens live too long.  They should be short and ephemeral, and if a 
user needs a new one to complete an action, getting one should be 
trivial.  They should be bound to the endpoint that is the target of the 
operation.  5 minutes makes sense as a length of life, as that is 
essentially "now"  when you factor in clock skew. Revocations on tokens 
to not make sense.


2.  Delegation are long lived affairs.  If anything is going to take 
longer than the duration of the token, it should be in the context of a 
delegation, and the user should re-authenticate to prove identity.  
Delegations need to be focused on workflow, not "all operations ther 
user can do"  which means that the Glance case discussed here is a good 
start of documenting "what do you need to get this job done?"



We need to keep it light (not fill up a database) for normal operations, 
but maintain the chain of responsibility on a given operation.  Trusts 
are the closest thing we have to this model.


In the supply chain example, if one company exchanges a good with 
another company, they don't care about the end user, because there is no 
realy connection between the good and the user yet;   if there is a 
problem, the original manufacterur can produce  another car identical to 
the first and replace it without the user being any the wiser.


Contrast this with picking kids up from daycare:  as a parent, I have to 
sign a form saying that my mother-in-law will be picking up the kids on 
a specific day.  My Mother-in-law is not authorized to sign a form that 
will allow her friend to pick the kids up.  My kids are very, very 
specific to me, and should be carefully handed off from approved 
supervisor to approved supervisor.


Fetching an image from Glance may well be a causal or a protected 
operation, depending on the image.


Casual if it is a global image: anyone in the world can do it, so no big 
deal.


Protected if, for example, the image is pre-populated with an enrollment 
secret.  Only the owners should be able to get at it






regards

David

On 06/06/2015 03:25, Bhandaru, Malini K 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

  


> -- keeping it simple, only two levels.  This
protects from on the cusp expired user-tokens.

Could check user quota before attempting the storage.

  


Should user not have paid dues, Glance knows which objects to garbage
collect!

  


Regards

Malini

  


*From:*Adam Young [mailto:ayo...@redhat.com]
*Sent:* Friday, June 05, 2015 4:11 PM
*To:* openstack-dev@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
 mailto:d.w.chadw...@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 serv

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

[stuart . mclaren]

On Jun 5, 2015, at 19:25, Bhandaru, Malini K  
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

> -- 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:ayo...@redhat.com]
Sent: Friday, June 05, 2015 4:11 PM
To: openstack-dev@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  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 

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

[Morgan Fainberg]

> On Jun 5, 2015, at 19:25, Bhandaru, Malini K  
> 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
>  
> > -- 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:ayo...@redhat.com] 
> Sent: Friday, June 05, 2015 4:11 PM
> To: openstack-dev@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  
> 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 any

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

[David Chadwick]

In order to do this fully, you will need to work out what all the
possible supply chains are in OpenStack, so that when any customer
starts any chain of events, there is sufficient information in the
message passed to the supplier that allows that supplier to order from
its supplier. This has to be ensured all the way down the chain, so that
important information that one supplier needs was not omitted by a
previous supplier higher up the chain. I suspect that the name of the
initial requestor (at least) will need to be passed all the way down the
chain.

regards

David

On 06/06/2015 03:25, Bhandaru, Malini K 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
> 
>  
> 
> > -- keeping it simple, only two levels.  This
> protects from on the cusp expired user-tokens.
> 
> Could check user quota before attempting the storage.
> 
>  
> 
> Should user not have paid dues, Glance knows which objects to garbage
> collect!
> 
>  
> 
> Regards
> 
> Malini
> 
>  
> 
> *From:*Adam Young [mailto:ayo...@redhat.com]
> *Sent:* Friday, June 05, 2015 4:11 PM
> *To:* openstack-dev@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
> mailto:d.w.chadw...@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

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

[Bhandaru, Malini K]

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

> -- keeping it simple, only two levels.  This 
protects from on the cusp expired user-tokens.
Could check user quota before attempting the storage.

Should user not have paid dues, Glance knows which objects to garbage collect!

Regards
Malini

From: Adam Young [mailto:ayo...@redhat.com]
Sent: Friday, June 05, 2015 4:11 PM
To: openstack-dev@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 
mailto:d.w.chadw...@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 b

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

[Adam Young]

On 06/05/2015 10:39 AM, Dolph Mathews wrote:


On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick 
mailto:d.w.chadw...@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-requ...@lists.openstack.org?subject:unsubscribe

>> ht

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

[Dolph Mathews]

On Thu, Jun 4, 2015 at 1:54 AM, David Chadwick 
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.


>
> 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
___

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

[David Chadwick]

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.

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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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

[Adam Young]

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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev