Open Stack

On 20 June 2016 at 12:33, Morgan Fainberg <morgan.fainberg at gmail.com> wrote:

>
>
> 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.
>

It's kind of like each of those things - but i guess mentally i'm trying to
think of it differently and why I explicitly avoided calling it a token
even though there's the obvious similarity.

I'm trying to think of it as authorization for a single operation. Just by
nature of openstack that single operation might pass through a couple of
services to actually be completed.

I don't think we would ever transition or roll reservations. A reservation
lasts for the lifetime of one user request and represents permission for
the rest of openstack to execute this operation on behalf of the user. You
should not be able to use a reservation to fetch another token or
reservation, it is a verified bundle of state.

I also want to not think about it in terms of reducing roles. Ideally we
wouldn't even need to include roles in the reservation because we know up
front the policy check has succeeded (though i doubt this will be
practical). This reservation is only useful to perform the pre-authorized
operation it specifies. Roles are done with by this point, that check has
happened.

As i'm still trying to find good analogies i'll just try saying it in
different ways to get the point across:

An unscoped token is a user's authentication.
A scoped token is a user's authorization on some project.
A reservation is keystone's assertion that openstack services should
perform the enclosed operation for the enclosed user.

A user exchanges credentials for an unscoped token, then uses that to scope
a token to a project and then make calls. A service exchanges the scoped
token and current request information to create a reservation. Service to
service communication then is all about the reservation.

A reservation is operation state, it is not a token that can be used to
perform other actions.

Sorry for rambling.


>
>>
>>
>>
>> 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
>>
>>
>
> __________________________________________________________________________
> 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/20160620/a8ff8cd6/attachment.html>