Open Stack

> > This is comparable to the HEAT use case that Keystone Trusts were 
> originally designed to solve.
> >
> > If the glance client knows the roles required to perform those 
> operations, it could create the trust up front, with the Glance 
> Service user as the trustee; the trustee execute the trust when it 
> needs the token.
> >
> > Are there other cases besides the glance one that require long lived 
> tokens?
>
> Cinder backups. These do many swift operations over a long period, 
> often hours. They should probably be converted to trusts, but I'd need 
> some guidance do so.
>

1.  Identify the roles for the APIs that Cinder is going to be calling 
on swift based on Swifts policy.json
2.  The user Creates trust:  this could be done by the cinder client.  
The create trust call is here:

trustee user is the Cinder service user
trustor user is the actual human being (or reasonable facimile thereof) 
that needs this work done.


https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-trust-ext.md#create-trust-post-os-trusttrusts

impersonation should only be set if the API requires the tokens user_id 
to reflect the trustor.  I know that swift was one of the use cases for 
impersonation, but I don't think it is required.

Expiration date time is optional, but probably appropriate;  chose a 
value that is guaranteed to be long enough for the workflow, but that 
still limits the window for attack.   If this backup routinely takes 12 
hours, perhaps 24 hours is appropriate.

When the user requests the Cinder backup, they will have to include the 
trust ID in the request.  The cinder endpoint, prior to making a call to 
Swift, will get a token from Keystone, passing in the trust id  as per

https://github.com/openstack/identity-api/blob/master/v3/src/markdown/identity-api-v3-os-trust-ext.md#consuming-a-trust-with-post-authtokens