> 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
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
