Open Stack

On Wednesday, July 23, 2014, Russell Bryant <rbryant at redhat.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140723/f5c97f6a/attachment.html>