Open Stack

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 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 <lbragstad at 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 <john at 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.lists at 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 <joehuang at huawei.com> wrote:
>>>
>>>> I think a option 2 is better.
>>>>
>>>> Best Regards
>>>> Chaoyi Huang (joehuang)
>>>> ------------------------------
>>>> *From:* Lance Bragstad [lbragstad at gmail.com]
>>>> *Sent:* 25 May 2017 3:47
>>>> *To:* OpenStack Development Mailing List (not for usage questions);
>>>> openstack-operators at 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/3d033df1c0fdc
>>>> 6cc9d2b02a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342
>>>>
>>>> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbragstad at 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 at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>>
>>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>> _______________________________________________
>> OpenStack-operators mailing list
>> OpenStack-operators at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170606/36d8c6d1/attachment.html>