Add support to trusts such that redelegation between consumers of trusts (trustees, which are services for the currently expected use-cases) is possible.
Heat uses trusts to enable the service to act on behalf of a user when performing deferred operations during the lifecycle of a Heat stack, for example, when creating new instances in response to an autoscaling event.
The usage is as follows:
This poses a problem if the request creating the Heat stack comes from another service which is also using trusts, as the token in the request will be scoped to a trust, thus will be denied from creating the trust in step (2) above.
The main use-case for this is Solum, which wishes to use trusts in a similar way to Heat, to perform deferred operations via trusts, which may include creating Heat stacks, thus requiring creation of trusts enabling redelegation from a trust-scoped token.
Another potential use-case is when Heat creates an alarm with Ceilometer, we would like Ceilometer to create a trust, so it can impersonate the user owning the stack when sending asynchronous alarm signals to Heat (which could trigger creation of stacks, thus creation of trusts).
The proposal is that Keystone trusts will add optional support for chained delegation, which would enable a trust to specify that redelegation is permissible via a flag set on creation.
On creation of a trust, a new allow_redelegation argument may be specified, which if omitted will default to False, meaning the current default behavior remains where no redelegation is allowed.
If allow_redelegation is True, then explicit redelegation of some or all of the roles delegated by the trust will be possible, up to a configurable maximum number of redelegations, tracked by a redelegation_count associated with each trust, which is incremented each time a redelegation happens.
Thus, the following becomes possible:
One new DB column and item in the data structure representing a trust, similar to “remaining_uses” which was added during Icehouse.
One new optional item in the dictionary representing the trust, allow_redelegation.
Backwards compatibility will be maintained by simply defaulting it to zero inside the controller if it’s not passed by the user.
None, other than allowing for explicit redelegation where none is currently allowed.
To limit the maximum number of redelegations, there will be a new global config option max_redelegation_count, defaulted to a small number (such as 3) has been suggested.
If redelegation_count would be greater than max_redelegation_count when creating the trust, the request will be rejected.
Currently this is expected to be primarily useful for layered services consuming trusts, but other use-cases could include supporting redelegation workflow between human users.
There’s no actual impact on the end user though, as the default behavior is unchanged.
The performance penalty for the additional logic to decrement the counter on trust create should be negligible.
Writing a new tempest test will be a good idea. I’ll do that as part of the implementation, exact items to be tested TBC, but will probably include:
identity-api documentation will require an update.