Open Stack

On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad <lbragstad at gmail.com> wrote:
>
>
> On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckmann at 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 <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/3d033df1c0fdc6cc9d2b02a702efca286371f2bd/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
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>