Open Stack

On 07/22/2014 06:55 PM, Steven Hardy wrote:
> 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.

I fully agree.  In no way should the default behavior change.

> 
> 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?

Role-based limits seem to be a natural progression of the idea, though I
didn't want to throw that out there from the get-go.

-NGK

> 
> Steve
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>