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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
