Open Stack

On Sun, Jun 19, 2016 at 6:51 PM, Adam Young <ayoung at redhat.com> wrote:

> On 06/16/2016 02:19 AM, Jamie Lennox wrote:
>
> Thanks everyone for your input.
>
> I generally agree that there is something that doesn't quite feel right
> about purely trusting this information to be passed from service to
> service, this is why i was keen for outside input and I have been
> rethinking the approach.
>
>
> They really feel like a variation on Trust tokens.
>
> From the service perspective, they are tokens, just not the one the user
> originally requested.
>
> The "reservation" as I see it is an implicit trust created by the user
> requesting the operation on the initial service.
>
> When the service validates the token, it can get back the,  lets call it a
> "reserved token" in keeping with the term reservation above.  That token
> will have a longer life span than the one the user originally requested,
> but (likely) fewer roles.
>
> When nova calls glance, and then glance calls Swift, we can again
> transition to different reserved tokens if needs be.
>
>
>
I would really, really, really, prefer not to build in the need to
"transition" between "reserved" tokens when jumping between services. This
wont be "impossible", but I really don't want to start from the simpler
proposal; It's a lot of moving parts.

The big difference here is that trusts are explicit and have a LOT of
overhead (and frankly would be clunky for this) as currently implemented,
this is closer to an evolved version of the composite tokens we talked over
in Paris.

--Morgan



>
>
>
> To this end i've proposed reservations (a name that doesn't feel right):
> https://review.openstack.org/#/c/330329/
>
> At a gut feeling level i'm much happier with the concept. I think it will
> allow us to handle the distinction between user->service and
> service->service communication much better and has the added bonus of
> potentially opening up some policy options in future.
>
> Please let me know of any concerns/thoughts on the new approach.
>
> Once again i've only written the proposal part of the spec as there will
> be a lot of details to figure out if we go forward. It is also fairly rough
> but it should convey the point.
>
>
> Thanks
>
> Jamie
>
> On 3 June 2016 at 03:06, Shawn McKinney <smckinney at symas.com> wrote:
>
>>
>> > On Jun 2, 2016, at 10:58 AM, Adam Young < <ayoung at redhat.com>
>> ayoung at redhat.com> wrote:
>> >
>> > Any senseible RBAC setup would support this, but we are not using a
>> sensible one, we are using a hand rolled one. Replacing everything with
>> Fortress implies a complete rewrite of what we do now.  Nuke it from orbit
>> type stuff.
>> >
>> > What I would rather focus on is the splitting of the current policy
>> into two parts:
>> >
>> > 1. Scope check done in code
>> > 2. Role check done in middleware
>> >
>> > Role check should be donebased on URL, not on the policy key like
>> identity:create_user
>> >
>> >
>> > Then, yes, a Fortress style query could be done, or it could be done by
>> asking the service itself.
>>
>> Mostly in agreement.  I prefer to focus on the model (RBAC) rather than a
>> specific impl like Fortress. That is to say support the model and allow the
>> impl to remain pluggable.  That way you enable many vendors to participate
>> in your ecosystem and more important, one isn’t tied to a specific backend
>> (ldapv3, sql, …)
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160619/4dd6763a/attachment.html>