On Sun, Jun 19, 2016 at 6:51 PM, Adam Young <[email protected]> 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 <[email protected]> wrote: > >> >> > On Jun 2, 2016, at 10:58 AM, Adam Young < <[email protected]> >> [email protected]> 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: >> [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: > [email protected]?subject:unsubscribehttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
