Open Stack

On Fri, Dec 25, 2015 at 07:04:19PM -0800, Preston L. Bannister wrote:
>    In the implementation of a instance backup service for OpenStack, on
>    restore I need to (re)create the restored instance in the original tenant.
>    Restores can be fired off by an administrator (not the original user), so
>    at instance-create time I have two main choices:
>     1. Create the instance as the backup service.
>     2. Create the instance as the original user.
>    Clearly (1) is workable (given the backup user has access to the tenant).
>    Keypairs are a bit of an issue, but solvable.
>    Also clearly (2) is better, but that requires a means to impersonate the
>    original user. Keystone trusts seem to be that means, but raises
>    additional questions. (Also the fact the current documentation for
>    Keystone is incomplete in this area does not raise the confidence level.)
>     1. How far back is the Keystone OS-TRUST extension reliable? (Kilo?
>        Juno?)

Heat first started using trusts in Havana, and although there were a few
bugs early in that process, IIRC things have been pretty much solid since
Icehouse.

https://blueprints.launchpad.net/heat/+spec/heat-trusts

>     2. Do any OpenStack distributions omit the OS-TRUST extension?
>    A feature labelled as an "extension" poses a risk to the developer. :)

Trusts have long been enabled by default in keystone:

https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L2005

So, FWIW, my take on it is it's reasonable for other services to rely on
them being enabled by default - heat has used trusts by default since Kilo:

https://bugs.launchpad.net/heat/+bug/1286157

The mitigation for it being an extension in the Heat case, is we provide a
config option to switch back to the old pre-trusts behavior, but we default
to using trusts unless explicitly configured otherwise.

HTH,

Steve