<div dir="ltr">Ok - based on the responses in the thread here, I've re-proposed the global roles specification to keystone's backlog [0]. I'll start working on the implementation and get something in review as soon as possible. I'll plan to move the specification from backlog to Queens once development opens.<div><br></div><div>Thanks for all the feedback and patience.<br><div><div><br></div><div><br></div><div>[0] <a href="https://review.openstack.org/#/c/464763/">https://review.openstack.org/#/c/464763/</a></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 6, 2017 at 4:39 PM, Marc Heckmann <span dir="ltr"><<a href="mailto:marc.heckmann@ubisoft.com" target="_blank">marc.heckmann@ubisoft.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote:<br>
> On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad <<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>><br>
> wrote:<br>
> ><br>
> ><br>
> > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckmann@ubisof<br>
> > <a href="http://t.com" rel="noreferrer" target="_blank">t.com</a>><br>
> > wrote:<br>
> > ><br>
> > > Hi,<br>
> > ><br>
> > > On Tue, 2017-06-06 at 10:09 -0500, Lance Bragstad wrote:<br>
> > ><br>
> > > Also, with all the people involved with this thread, I'm curious<br>
> > > what the<br>
> > > best way is to get consensus. If I've tallied the responses<br>
> > > properly, we<br>
> > > have 5 in favor of option #2 and 1 in favor of option #3. This<br>
> > > week is spec<br>
> > > freeze for keystone, so I see a slim chance of this getting<br>
> > > committed to<br>
> > > Pike [0]. If we do have spare cycles across the team we could<br>
> > > start working<br>
> > > on an early version and get eyes on it. If we straighten out<br>
> > > everyone<br>
> > > concerns early we could land option #2 early in Queens.<br>
> > ><br>
> > ><br>
> > > I was the only one in favour of option 3 only because I've spent<br>
> > > a bunch<br>
> > > of time playing with option #1 in the past. As I mentioned<br>
> > > previously in the<br>
> > > thread, if #2 is more in line with where the project is going,<br>
> > > then I'm all<br>
> > > for it. At this point, the admin scope issue has been around long<br>
> > > enough<br>
> > > that Queens doesn't seem that far off.<br>
> ><br>
> ><br>
> > From an administrative point-of-view, would you consider option #1<br>
> > or option<br>
> > #2 to better long term?<br>
<br>
</div></div>#2<br>
<div class="HOEnZb"><div class="h5"><br>
> ><br>
><br>
> Count me as another +1 for option 2. It's the right way to go long<br>
> term, and we've lived with how it is now long enough that I'm OK<br>
> waiting a release or even 2 more for it with things as is. I think<br>
> option 3 would just muddy the waters.<br>
><br>
> -Erik<br>
><br>
> > ><br>
> > ><br>
> > > -m<br>
> > ><br>
> > ><br>
> > > I guess it comes down to how fast folks want it.<br>
> > ><br>
> > > [0] <a href="https://review.openstack.org/#/c/464763/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/464763/</a><br>
> > ><br>
> > > On Tue, Jun 6, 2017 at 10:01 AM, Lance Bragstad <lbragstad@gmail.<br>
> > > com><br>
> > > wrote:<br>
> > ><br>
> > > I replied to John, but directly. I'm sending the responses I sent<br>
> > > to him<br>
> > > but with the intended audience on the thread. Sorry for not<br>
> > > catching that<br>
> > > earlier.<br>
> > ><br>
> > ><br>
> > > On Fri, May 26, 2017 at 2:44 AM, John Garbutt <john@johngarbutt.c<br>
> > > om><br>
> > > wrote:<br>
> > ><br>
> > > +1 on not forcing Operators to transition to something new twice,<br>
> > > even if<br>
> > > we did go for option 3.<br>
> > ><br>
> > ><br>
> > > The more I think about this, the more it worries me from a<br>
> > > developer<br>
> > > perspective. If we ended up going with option 3, then we'd be<br>
> > > supporting<br>
> > > both methods of elevating privileges. That means two paths for<br>
> > > doing the<br>
> > > same thing in keystone. It also means oslo.context,<br>
> > > keystonemiddleware, or<br>
> > > any other library consuming tokens that needs to understand<br>
> > > elevated<br>
> > > privileges needs to understand both approaches.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Do we have an agreed non-distruptive upgrade path mapped out yet?<br>
> > > (For any<br>
> > > of the options) We spoke about fallback rules you pass but with a<br>
> > > warning to<br>
> > > give us a smoother transition. I think that's my main objection<br>
> > > with the<br>
> > > existing patches, having to tell all admins to get their token<br>
> > > for a<br>
> > > different project, and give them roles in that project, all<br>
> > > before being<br>
> > > able to upgrade.<br>
> > ><br>
> > ><br>
> > > Thanks for bringing up the upgrade case! You've kinda described<br>
> > > an upgrade<br>
> > > for option 1. This is what I was thinking for option 2:<br>
> > ><br>
> > > - deployment upgrades to a release that supports global role<br>
> > > assignments<br>
> > > - operator creates a set of global roles (i.e. global_admin)<br>
> > > - operator grants global roles to various people that need it<br>
> > > (i.e. all<br>
> > > admins)<br>
> > > - operator informs admins to create globally scoped tokens<br>
> > > - operator rolls out necessary policy changes<br>
> > ><br>
> > > If I'm thinking about this properly, nothing would change at the<br>
> > > project-scope level for existing users (who don't need a global<br>
> > > role<br>
> > > assignment). I'm hoping someone can help firm ^ that up or<br>
> > > improve it if<br>
> > > needed.<br>
> > ><br>
> > ><br>
> > ><br>
> > > Thanks,<br>
> > > johnthetubaguy<br>
> > ><br>
> > > On Fri, 26 May 2017 at 08:09, Belmiro Moreira<br>
> > > <<a href="mailto:moreira.belmiro.email.lists@gmail.com">moreira.belmiro.email.lists@<wbr>gmail.com</a>> wrote:<br>
> > ><br>
> > > Hi,<br>
> > > thanks for bringing this into discussion in the Operators list.<br>
> > ><br>
> > > Option 1 and 2 and not complementary but complety different.<br>
> > > So, considering "Option 2" and the goal to target it for Queens I<br>
> > > would<br>
> > > prefer not going into a migration path in<br>
> > > Pike and then again in Queens.<br>
> > ><br>
> > > Belmiro<br>
> > ><br>
> > > On Fri, May 26, 2017 at 2:52 AM, joehuang <<a href="mailto:joehuang@huawei.com">joehuang@huawei.com</a>><br>
> > > wrote:<br>
> > ><br>
> > > I think a option 2 is better.<br>
> > ><br>
> > > Best Regards<br>
> > > Chaoyi Huang (joehuang)<br>
> > > ______________________________<wbr>__<br>
> > > From: Lance Bragstad [<a href="mailto:lbragstad@gmail.com">lbragstad@gmail.com</a>]<br>
> > > Sent: 25 May 2017 3:47<br>
> > > To: OpenStack Development Mailing List (not for usage questions);<br>
> > > <a href="mailto:openstack-operators@lists.openstack.org">openstack-operators@lists.<wbr>openstack.org</a><br>
> > > Subject: Re: [openstack-dev]<br>
> > > [keystone][nova][cinder][<wbr>glance][neutron][horizon][<wbr>policy]<br>
> > > defining<br>
> > > admin-ness<br>
> > ><br>
> > > I'd like to fill in a little more context here. I see three<br>
> > > options with<br>
> > > the current two proposals.<br>
> > ><br>
> > > Option 1<br>
> > ><br>
> > > Use a special admin project to denote elevated privileges. For<br>
> > > those<br>
> > > unfamiliar with the approach, it would rely on every deployment<br>
> > > having an<br>
> > > "admin" project defined in configuration [0].<br>
> > ><br>
> > > How it works:<br>
> > ><br>
> > > Role assignments on this project represent global scope which is<br>
> > > denoted<br>
> > > by a boolean attribute in the token response. A user with an<br>
> > > 'admin' role<br>
> > > assignment on this project is equivalent to the global or cloud<br>
> > > administrator. Ideally, if a user has a 'reader' role assignment<br>
> > > on the<br>
> > > admin project, they could have access to list everything within<br>
> > > the<br>
> > > deployment, pending all the proper changes are made across the<br>
> > > various<br>
> > > services. The workflow requires a special project for any sort of<br>
> > > elevated<br>
> > > privilege.<br>
> > ><br>
> > > Pros:<br>
> > > - Almost all the work is done to make keystone understand the<br>
> > > admin<br>
> > > project, there are already several patches in review to other<br>
> > > projects to<br>
> > > consume this<br>
> > > - Operators can create roles and assign them to the admin_project<br>
> > > as<br>
> > > needed after the upgrade to give proper global scope to their<br>
> > > users<br>
> > ><br>
> > > Cons:<br>
> > > - All global assignments are linked back to a single project<br>
> > > - Describing the flow is confusing because in order to give<br>
> > > someone global<br>
> > > access you have to give them a role assignment on a very specific<br>
> > > project,<br>
> > > which seems like an anti-pattern<br>
> > > - We currently don't allow some things to exist in the global<br>
> > > sense (i.e.<br>
> > > I can't launch instances without tenancy), the admin project<br>
> > > could own<br>
> > > resources<br>
> > > - What happens if the admin project disappears?<br>
> > > - Tooling or scripts will be written around the admin project,<br>
> > > instead of<br>
> > > treating all projects equally<br>
> > ><br>
> > > Option 2<br>
> > ><br>
> > > Implement global role assignments in keystone.<br>
> > ><br>
> > > How it works:<br>
> > ><br>
> > > Role assignments in keystone can be scoped to global context.<br>
> > > Users can<br>
> > > then ask for a globally scoped token<br>
> > ><br>
> > > Pros:<br>
> > > - This approach represents a more accurate long term vision for<br>
> > > role<br>
> > > assignments (at least how we understand it today)<br>
> > > - Operators can create global roles and assign them as needed<br>
> > > after the<br>
> > > upgrade to give proper global scope to their users<br>
> > > - It's easier to explain global scope using global role<br>
> > > assignments<br>
> > > instead of a special project<br>
> > > - token.is_global = True and token.role = 'reader' is easier to<br>
> > > understand<br>
> > > than token.is_admin_project = True and token.role = 'reader'<br>
> > > - A global token can't be associated to a project, making it<br>
> > > harder for<br>
> > > operations that require a project to consume a global token (i.e.<br>
> > > I<br>
> > > shouldn't be able to launch an instance with a globally scoped<br>
> > > token)<br>
> > ><br>
> > > Cons:<br>
> > > - We need to start from scratch implementing global scope in<br>
> > > keystone,<br>
> > > steps for this are detailed in the spec<br>
> > ><br>
> > > Option 3<br>
> > ><br>
> > > We do option one and then follow it up with option two.<br>
> > ><br>
> > > How it works:<br>
> > ><br>
> > > We implement option one and continue solving the admin-ness<br>
> > > issues in Pike<br>
> > > by helping projects consume and enforce it. We then target the<br>
> > > implementation of global roles for Queens.<br>
> > ><br>
> > > Pros:<br>
> > > - If we make the interface in oslo.context for global roles<br>
> > > consistent,<br>
> > > then consuming projects shouldn't know the difference between<br>
> > > using the<br>
> > > admin_project or a global role assignment<br>
> > ><br>
> > > Cons:<br>
> > > - It's more work and we're already strapped for resources<br>
> > > - We've told operators that the admin_project is a thing but<br>
> > > after Queens<br>
> > > they will be able to do real global role assignments, so they<br>
> > > should now<br>
> > > migrate *again*<br>
> > > - We have to support two paths for solving the same problem in<br>
> > > keystone,<br>
> > > more maintenance and more testing to ensure they both behave<br>
> > > exactly the<br>
> > > same way<br>
> > >   - This can get more complicated for projects dedicated to<br>
> > > testing policy<br>
> > > and RBAC, like Patrole<br>
> > ><br>
> > ><br>
> > > Looking for feedback here as to which one is preferred given<br>
> > > timing and<br>
> > > payoff, specifically from operators who would be doing the<br>
> > > migrations to<br>
> > > implement and maintain proper scope in their deployments.<br>
> > ><br>
> > > Thanks for reading!<br>
> > ><br>
> > ><br>
> > > [0]<br>
> > > <a href="https://github.com/openstack/keystone/blob/3d033df1c0fdc6cc9d2b02" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>keystone/blob/<wbr>3d033df1c0fdc6cc9d2b02</a><br>
> > > a702efca286371f2bd/etc/<wbr>keystone.conf.sample#L2334-<wbr>L2342<br>
> > ><br>
> > > On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbragstad@gmail<br>
> > > .com><br>
> > > wrote:<br>
> > ><br>
> > > Hey all,<br>
> > ><br>
> > > To date we have two proposed solutions for tackling the admin-<br>
> > > ness issue<br>
> > > we have across the services. One builds on the existing scope<br>
> > > concepts by<br>
> > > scoping to an admin project [0]. The other introduces global role<br>
> > > assignments [1] as a way to denote elevated privileges.<br>
> > ><br>
> > > I'd like to get some feedback from operators, as well as<br>
> > > developers from<br>
> > > other projects, on each approach. Since work is required in<br>
> > > keystone, it<br>
> > > would be good to get consensus before spec freeze (June 9th). If<br>
> > > you have<br>
> > > specific questions on either approach, feel free to ping me or<br>
> > > drop by the<br>
> > > weekly policy meeting [2].<br>
> > ><br>
> > > Thanks!<br>
> > ><br>
> > > [0] <a href="http://adam.younglogic.com/2017/05/fixing-bug-96869/" rel="noreferrer" target="_blank">http://adam.younglogic.com/<wbr>2017/05/fixing-bug-96869/</a><br>
> > > [1] <a href="https://review.openstack.org/#/c/464763/" rel="noreferrer" target="_blank">https://review.openstack.org/#<wbr>/c/464763/</a><br>
> > > [2] <a href="http://eavesdrop.openstack.org/#Keystone_Policy_Meeting" rel="noreferrer" target="_blank">http://eavesdrop.openstack.<wbr>org/#Keystone_Policy_Meeting</a><br>
> > ><br>
> > ><br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > OpenStack-operators mailing list<br>
> > > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-ope</a><br>
> > > rators<br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > OpenStack-operators mailing list<br>
> > > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-ope</a><br>
> > > rators<br>
> > ><br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > OpenStack-operators mailing list<br>
> > > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-ope</a><br>
> > > rators<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > ______________________________<wbr>_________________<br>
> > > OpenStack-operators mailing list<br>
> > > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> > > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-ope</a><br>
> > > rators<br>
> ><br>
> ><br>
> ><br>
> > ______________________________<wbr>_________________<br>
> > OpenStack-operators mailing list<br>
> > <a href="mailto:OpenStack-operators@lists.openstack.org">OpenStack-operators@lists.<wbr>openstack.org</a><br>
> > <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-opera" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-opera</a><br>
> > tors<br>
> > </div></div></blockquote></div><br></div>