On Wednesday, July 23, 2014, Russell Bryant <[email protected]> wrote:
> On 07/22/2014 11:00 PM, Nathan Kinder wrote: > > > > > > 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. > > I was concerned about this idea from an API compatibility perspective, > but I think the way you have laid it out here makes sense. Like both > you and Steven said, the behavior of the API when the parameter is not > specified should *not* change. However, allowing deployment-specific > policy that would reject the request seems fine. > > Thanks, > > -- > Russell Bryant > > 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. I can see a benefit to having this type of enforcement in some deployments. --Morgan
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
