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