Open Stack

On Tue, Jul 22, 2014 at 05:20:44PM -0700, Nathan Kinder wrote:
> Hi,
> 
> I've had a few discussions recently related to Keystone trusts with
> regards to imposing restrictions on trusts at a deployment level.
> Currently, the creator of a trust is able to specify the following
> restrictions on the trust at creation time:
> 
>   - an expiration time for the trust
>   - the number of times that the trust can be used to issue trust tokens
> 
> If an expiration time (expires_at) is not specified by the creator of
> the trust, then it never expires.  Similarly, if the number of uses
> (remaining_uses) is not specified by the creator of the trust, it has an
> unlimited number of uses.  The important thing to note is that the
> restrictions are entirely in the control of the trust creator.
> 
> There may be cases where a particular deployment wants to specify global
> maximum values for these restrictions to prevent a trust from being
> granted indefinitely.  For example, Keystone configuration could specify
> that a trust can't be created that has >100 remaining uses or is valid
> for more than 6 months.  This would certainly cause problems for some
> deployments that may be relying on indefinite trusts, but it is also a
> nice security control for deployments that don't want to allow something
> so open-ended.
> 
> I'm wondering about the feasibility of this sort of change, particularly
> from an API compatibility perspective.  An attempt to create a trust
> without an expires_at value should still be considered as an attempt to
> create a trust that never expires, but Keystone could return a '403
> Forbidden' response if this request violates the maximum specified in
> configuration (this would be similar for remaining_uses).  The semantics
> of the API remain the same, but the response has the potential to be
> rejected for new reasons.  Is this considered as an API change, or would
> this be considered to be OK to implement in the v3 API?  The existing
> API docs [1][2] don't really go to this level of detail with regards to
> when exactly a 403 will be returned for trust creation, though I know of
> specific cases where this response is returned for the create-trust request.

FWIW if you start enforcing either of these restrictions by default, you
will break heat, and every other delegation-to-a-service use case I'm aware
of, where you simply don't have any idea how long the lifetime of the thing
created by the service (e.g heat stack, Solum application definition,
Mistral workflow or whatever) will be.

So while I can understand the desire to make this configurable for some
environments, please leave the defaults as the current behavior and be
aware that adding these kind of restrictions won't work for many existing
trusts use-cases.

Maybe the solution would be some sort of policy defined exception to these
limits?  E.g when delegating to a user in the service project, they do not
apply?

Steve