<br><br>On Wednesday, July 23, 2014, Russell Bryant <<a href="mailto:rbryant@redhat.com">rbryant@redhat.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 07/22/2014 11:00 PM, Nathan Kinder wrote:<br>
><br>
><br>
> On 07/22/2014 06:55 PM, Steven Hardy wrote:<br>
>> On Tue, Jul 22, 2014 at 05:20:44PM -0700, Nathan Kinder wrote:<br>
>>> Hi,<br>
>>><br>
>>> I've had a few discussions recently related to Keystone trusts with<br>
>>> regards to imposing restrictions on trusts at a deployment level.<br>
>>> Currently, the creator of a trust is able to specify the following<br>
>>> restrictions on the trust at creation time:<br>
>>><br>
>>>   - an expiration time for the trust<br>
>>>   - the number of times that the trust can be used to issue trust tokens<br>
>>><br>
>>> If an expiration time (expires_at) is not specified by the creator of<br>
>>> the trust, then it never expires.  Similarly, if the number of uses<br>
>>> (remaining_uses) is not specified by the creator of the trust, it has an<br>
>>> unlimited number of uses.  The important thing to note is that the<br>
>>> restrictions are entirely in the control of the trust creator.<br>
>>><br>
>>> There may be cases where a particular deployment wants to specify global<br>
>>> maximum values for these restrictions to prevent a trust from being<br>
>>> granted indefinitely.  For example, Keystone configuration could specify<br>
>>> that a trust can't be created that has >100 remaining uses or is valid<br>
>>> for more than 6 months.  This would certainly cause problems for some<br>
>>> deployments that may be relying on indefinite trusts, but it is also a<br>
>>> nice security control for deployments that don't want to allow something<br>
>>> so open-ended.<br>
>>><br>
>>> I'm wondering about the feasibility of this sort of change, particularly<br>
>>> from an API compatibility perspective.  An attempt to create a trust<br>
>>> without an expires_at value should still be considered as an attempt to<br>
>>> create a trust that never expires, but Keystone could return a '403<br>
>>> Forbidden' response if this request violates the maximum specified in<br>
>>> configuration (this would be similar for remaining_uses).  The semantics<br>
>>> of the API remain the same, but the response has the potential to be<br>
>>> rejected for new reasons.  Is this considered as an API change, or would<br>
>>> this be considered to be OK to implement in the v3 API?  The existing<br>
>>> API docs [1][2] don't really go to this level of detail with regards to<br>
>>> when exactly a 403 will be returned for trust creation, though I know of<br>
>>> specific cases where this response is returned for the create-trust request.<br>
>><br>
>> FWIW if you start enforcing either of these restrictions by default, you<br>
>> will break heat, and every other delegation-to-a-service use case I'm aware<br>
>> of, where you simply don't have any idea how long the lifetime of the thing<br>
>> created by the service (e.g heat stack, Solum application definition,<br>
>> Mistral workflow or whatever) will be.<br>
>><br>
>> So while I can understand the desire to make this configurable for some<br>
>> environments, please leave the defaults as the current behavior and be<br>
>> aware that adding these kind of restrictions won't work for many existing<br>
>> trusts use-cases.<br>
><br>
> I fully agree.  In no way should the default behavior change.<br>
><br>
>><br>
>> Maybe the solution would be some sort of policy defined exception to these<br>
>> limits?  E.g when delegating to a user in the service project, they do not<br>
>> apply?<br>
><br>
> Role-based limits seem to be a natural progression of the idea, though I<br>
> didn't want to throw that out there from the get-go.<br>
<br>
I was concerned about this idea from an API compatibility perspective,<br>
but I think the way you have laid it out here makes sense.  Like both<br>
you and Steven said, the behavior of the API when the parameter is not<br>
specified should *not* change.  However, allowing deployment-specific<br>
policy that would reject the request seems fine.<br>
<br>
Thanks,<br>
<br>
--<br>
Russell Bryant<br><br>
</blockquote><div><br></div><div>This all seems quite reasonable. And as long as the default behavior is reasonable (doesn't change) I see this as quite doable and should not have any negative impact on the API<span></span>. </div>
<div><br></div><div>I can see a benefit to having this type of enforcement in some deployments. </div><div><div><br></div><div>--Morgan </div></div>