Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

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.

Thanks for all the feedback and patience.


[0] https://review.openstack.org/#/c/464763/

On Tue, Jun 6, 2017 at 4:39 PM, Marc Heckmann 
wrote:

> On Tue, 2017-06-06 at 17:01 -0400, Erik McCormick wrote:
> > On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad 
> > wrote:
> > >
> > >
> > > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann  > > t.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?
>
> #2
>
> > >
> >
> > 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  > > > 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  > > > om>
> > > > 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
> > > > 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Erik McCormick]

On Tue, Jun 6, 2017 at 4:44 PM, Lance Bragstad  wrote:
>
>
> On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann 
> 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 
>> 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 
>> 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
>>  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  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-operat...@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 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann 
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?


>
> -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 
> 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 
> 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  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-operat...@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 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

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  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 
> 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  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-operat...@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 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

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  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  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-operat...@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 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

I took a stab at working through the API a bit more and I've capture that
information in the spec [0]. Rendered version is available, too [1].

[0] https://review.openstack.org/#/c/464763/
[1]
http://docs-draft.openstack.org/63/464763/12/check/gate-keystone-specs-docs-ubuntu-xenial/1dbeb65//doc/build/html/specs/keystone/ongoing/global-roles.html

On Wed, May 31, 2017 at 9:10 AM, Lance Bragstad  wrote:

>
>
> On Fri, May 26, 2017 at 10:21 AM, Sean Dague  wrote:
>
>> On 05/26/2017 10:44 AM, Lance Bragstad wrote:
>> 
>> > Interesting - I guess the way I was thinking about it was on a per-token
>> > basis, since today you can't have a single token represent multiple
>> > scopes. Would it be unreasonable to have oslo.context build this
>> > information based on multiple tokens from the same user, or is that a
>> > bad idea?
>>
>> No service consumer is interacting with Tokens. That's all been
>> abstracted away. The code in the consumers consumer is interested in is
>> the context representation.
>>
>> Which is good, because then the important parts are figuring out the
>> right context interface to consume. And the right Keystone front end to
>> be explicit about what was intended by the operator "make jane an admin
>> on compute in region 1".
>>
>> And the middle can be whatever works best on the Keystone side. As long
>> as the details of that aren't leaked out, it can also be refactored in
>> the future by having keystonemiddleware+oslo.context translate to the
>> known interface.
>>
>
> Ok - I think that makes sense. So if I copy/paste your example from
> earlier and modify it a bit ( s/is_admin/global/)::
>
> {
>"user": "me!",
>"global": True,
>"roles": ["admin", "auditor"],
>
> }
>
> Or
>
> {
>"user": "me!",
>"global": True,
>"roles": ["reader"],
>
> }
>
> That might be one way we can represent global roles through 
> oslo.context/keystonemiddleware.
> The library would be on the hook for maintaining the mapping of token scope
> to context scope, which makes sense:
>
> if token['is_global'] == True:
> context.global = True
> elif token['domain_scoped']:
> # domain scoping?
> else:
> # handle project scoping
>
> I need to go dig into oslo.context a bit more to get familiar with how
> this works on the project level. Because if I understand correctly,
> oslo.context currently doesn't relay global scope and that will be a
> required thing to get done before this work is useful, regardless of going
> with option #1, #2, and especially #3.
>
>
>
>> -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Fri, May 26, 2017 at 10:21 AM, Sean Dague  wrote:

> On 05/26/2017 10:44 AM, Lance Bragstad wrote:
> 
> > Interesting - I guess the way I was thinking about it was on a per-token
> > basis, since today you can't have a single token represent multiple
> > scopes. Would it be unreasonable to have oslo.context build this
> > information based on multiple tokens from the same user, or is that a
> > bad idea?
>
> No service consumer is interacting with Tokens. That's all been
> abstracted away. The code in the consumers consumer is interested in is
> the context representation.
>
> Which is good, because then the important parts are figuring out the
> right context interface to consume. And the right Keystone front end to
> be explicit about what was intended by the operator "make jane an admin
> on compute in region 1".
>
> And the middle can be whatever works best on the Keystone side. As long
> as the details of that aren't leaked out, it can also be refactored in
> the future by having keystonemiddleware+oslo.context translate to the
> known interface.
>

Ok - I think that makes sense. So if I copy/paste your example from earlier
and modify it a bit ( s/is_admin/global/)::

{
   "user": "me!",
   "global": True,
   "roles": ["admin", "auditor"],
   
}

Or

{
   "user": "me!",
   "global": True,
   "roles": ["reader"],
   
}

That might be one way we can represent global roles through
oslo.context/keystonemiddleware. The library would be on the hook for
maintaining the mapping of token scope to context scope, which makes sense:

if token['is_global'] == True:
context.global = True
elif token['domain_scoped']:
# domain scoping?
else:
# handle project scoping

I need to go dig into oslo.context a bit more to get familiar with how this
works on the project level. Because if I understand correctly, oslo.context
currently doesn't relay global scope and that will be a required thing to
get done before this work is useful, regardless of going with option #1,
#2, and especially #3.



> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Sean Dague]

On 05/26/2017 10:44 AM, Lance Bragstad wrote:

> Interesting - I guess the way I was thinking about it was on a per-token
> basis, since today you can't have a single token represent multiple
> scopes. Would it be unreasonable to have oslo.context build this
> information based on multiple tokens from the same user, or is that a
> bad idea?

No service consumer is interacting with Tokens. That's all been
abstracted away. The code in the consumers consumer is interested in is
the context representation.

Which is good, because then the important parts are figuring out the
right context interface to consume. And the right Keystone front end to
be explicit about what was intended by the operator "make jane an admin
on compute in region 1".

And the middle can be whatever works best on the Keystone side. As long
as the details of that aren't leaked out, it can also be refactored in
the future by having keystonemiddleware+oslo.context translate to the
known interface.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Fri, May 26, 2017 at 9:31 AM, Sean Dague  wrote:

> On 05/26/2017 10:05 AM, Lance Bragstad wrote:
> >
> >
> > On Fri, May 26, 2017 at 5:32 AM, Sean Dague  > > wrote:
> >
> > On 05/26/2017 03:44 AM, John Garbutt wrote:
> > > +1 on not forcing Operators to transition to something new twice,
> even
> > > if we did go for option 3.
> > >
> > > 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.
> >
> > I definitely think the double migration is a good reason to just do
> this
> > thing right the first time.
> >
> > My biggest real concern with is_admin_project (and the service
> project),
> > is that it's not very explicit. It's mostly a way to trick the
> current
> > plumbing into acting a different way. Which is fine if you are a
> > deployer and need to create this behavior with the existing codebase
> you
> > have. Which seems to have all come down to their being a
> > misunderstanding of what Roles were back in 2012, and the two camps
> went
> > off in different directions (roles really being project scoped, and
> > roles meaning global).
> >
> > It would be really great if the inflated context we got was "roles:
> x,
> > y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware
> > and oslo.context might be weaving some magic there). I honestly think
> > that until we've got a very clear separation at that level, it's
> going
> > to be really tough to get policy files in projects to be any more
> > sensible in their defaults. Leaking is_admin_project all the way
> through
> > to a service and having them have to consider it for their policy
> (which
> > we do with the context today) definitely feels like a layer
> violation.
> >
> >
> > This is another good point. If we can ensure projects rely on
> > oslo.context to get scope information in a canonical form (like
> > context.scope == 'global' or context.scope == 'project') that might make
> > consuming all this easier. But it does require us to ensure oslo.context
> > does the right thing with various token types. I included some of that
> > information in the spec [0] but I didn't go into great detail. I thought
> > about adding it to the keystone spec but wasn't sure if that would be
> > the right place for it.
> >
> > [0] https://review.openstack.org/#/c/464763
>
> Personally, as someone that has to think about consuming oslo.context, I
> really don't want
> "scope" as a context option. Because now it means role means something
> different.
>
> I want the context to say:
>
> {
>"user": "me!"
>"project": "some_fun_work",
>"project_roles": ["member"],
>"is_admin": True,
>"roles": ["admin", "auditor"],
>
> }
>
> That's something I can imagine understanding. Because context switching
> on scope and conditionally doing different things in code depending on
> that is something that's going to cause bugs. It's hard code to not get
> wrong.
>
>
Interesting - I guess the way I was thinking about it was on a per-token
basis, since today you can't have a single token represent multiple scopes.
Would it be unreasonable to have oslo.context build this information based
on multiple tokens from the same user, or is that a bad idea?


> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Sean Dague]

On 05/26/2017 10:05 AM, Lance Bragstad wrote:
> 
> 
> On Fri, May 26, 2017 at 5:32 AM, Sean Dague  > wrote:
> 
> On 05/26/2017 03:44 AM, John Garbutt wrote:
> > +1 on not forcing Operators to transition to something new twice, even
> > if we did go for option 3.
> >
> > 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.
> 
> I definitely think the double migration is a good reason to just do this
> thing right the first time.
> 
> My biggest real concern with is_admin_project (and the service project),
> is that it's not very explicit. It's mostly a way to trick the current
> plumbing into acting a different way. Which is fine if you are a
> deployer and need to create this behavior with the existing codebase you
> have. Which seems to have all come down to their being a
> misunderstanding of what Roles were back in 2012, and the two camps went
> off in different directions (roles really being project scoped, and
> roles meaning global).
> 
> It would be really great if the inflated context we got was "roles: x,
> y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware
> and oslo.context might be weaving some magic there). I honestly think
> that until we've got a very clear separation at that level, it's going
> to be really tough to get policy files in projects to be any more
> sensible in their defaults. Leaking is_admin_project all the way through
> to a service and having them have to consider it for their policy (which
> we do with the context today) definitely feels like a layer violation.
> 
> 
> This is another good point. If we can ensure projects rely on
> oslo.context to get scope information in a canonical form (like
> context.scope == 'global' or context.scope == 'project') that might make
> consuming all this easier. But it does require us to ensure oslo.context
> does the right thing with various token types. I included some of that
> information in the spec [0] but I didn't go into great detail. I thought
> about adding it to the keystone spec but wasn't sure if that would be
> the right place for it.
> 
> [0] https://review.openstack.org/#/c/464763

Personally, as someone that has to think about consuming oslo.context, I
really don't want
"scope" as a context option. Because now it means role means something
different.

I want the context to say:

{
   "user": "me!"
   "project": "some_fun_work",
   "project_roles": ["member"],
   "is_admin": True,
   "roles": ["admin", "auditor"],
   
}

That's something I can imagine understanding. Because context switching
on scope and conditionally doing different things in code depending on
that is something that's going to cause bugs. It's hard code to not get
wrong.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Fri, May 26, 2017 at 5:32 AM, Sean Dague  wrote:

> On 05/26/2017 03:44 AM, John Garbutt wrote:
> > +1 on not forcing Operators to transition to something new twice, even
> > if we did go for option 3.
> >
> > 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.
>
> I definitely think the double migration is a good reason to just do this
> thing right the first time.
>
> My biggest real concern with is_admin_project (and the service project),
> is that it's not very explicit. It's mostly a way to trick the current
> plumbing into acting a different way. Which is fine if you are a
> deployer and need to create this behavior with the existing codebase you
> have. Which seems to have all come down to their being a
> misunderstanding of what Roles were back in 2012, and the two camps went
> off in different directions (roles really being project scoped, and
> roles meaning global).
>
> It would be really great if the inflated context we got was "roles: x,
> y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware
> and oslo.context might be weaving some magic there). I honestly think
> that until we've got a very clear separation at that level, it's going
> to be really tough to get policy files in projects to be any more
> sensible in their defaults. Leaking is_admin_project all the way through
> to a service and having them have to consider it for their policy (which
> we do with the context today) definitely feels like a layer violation.
>

This is another good point. If we can ensure projects rely on oslo.context
to get scope information in a canonical form (like context.scope ==
'global' or context.scope == 'project') that might make consuming all this
easier. But it does require us to ensure oslo.context does the right thing
with various token types. I included some of that information in the spec
[0] but I didn't go into great detail. I thought about adding it to the
keystone spec but wasn't sure if that would be the right place for it.

[0] https://review.openstack.org/#/c/464763


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Sean Dague]

On 05/26/2017 03:44 AM, John Garbutt wrote:
> +1 on not forcing Operators to transition to something new twice, even
> if we did go for option 3.
> 
> 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.

I definitely think the double migration is a good reason to just do this
thing right the first time.

My biggest real concern with is_admin_project (and the service project),
is that it's not very explicit. It's mostly a way to trick the current
plumbing into acting a different way. Which is fine if you are a
deployer and need to create this behavior with the existing codebase you
have. Which seems to have all come down to their being a
misunderstanding of what Roles were back in 2012, and the two camps went
off in different directions (roles really being project scoped, and
roles meaning global).

It would be really great if the inflated context we got was "roles: x,
y, z, project_roles: q, r, s" (and fully accepting keystonemiddleware
and oslo.context might be weaving some magic there). I honestly think
that until we've got a very clear separation at that level, it's going
to be really tough to get policy files in projects to be any more
sensible in their defaults. Leaking is_admin_project all the way through
to a service and having them have to consider it for their policy (which
we do with the context today) definitely feels like a layer violation.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[John Garbutt]

+1 on not forcing Operators to transition to something new twice, even if
we did go for option 3.

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,
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  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-operat...@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
>> 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Belmiro Moreira]

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  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-operat...@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 

Re: [openstack-dev] [Openstack-operators] [keystone][nova][cinder][glance][neutron][horizon][policy] defining admin-ness

[Lance Bragstad]

On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann 
wrote:

> First of all @Lance, thanks for taking the time to write and summarize
> this for us. It's much appreciated.
>

Absolutely! it helps me think about it, too.


>
> While I'm not aware of all the nuances, based on my own testing, I feel
> that we are really close with option 1.
>
> That being said, as you already stated, option 2 is clearly more inline
> with the idea of having a "global" Cloud Admin role. So long term, #2 is
> more desirable.
>
> Given the two sentences above, I certainly would prefer option 3 so that
> we can have a usable solution quickly. I certainly will continue to test
> and provide feedback for the option 1 part.
>
>
It sounds like eventually migrating everything from the is_admin_project to
true global roles is a migration you're willing to make. This might be a
loaded question and it will vary across deployments, but how long would you
expect that migration to take for you're specific deployment(s)?


-m
>
>
>
>
> On Thu, 2017-05-25 at 10:42 +1200, Adrian Turjak wrote:
>
>
>
> On 25/05/17 07:47, Lance Bragstad wrote:
> 
>
> *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
>
> 
>
>
> On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad 
> 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!
>
>
> Please option 2. The concept of being an "admin" while you are only scoped
> to a project is stupid when that admin role gives you super user power yet
> you only have it when scoped to just that project. That concept never
> really made sense. Global scope makes so much more sense when that is the
> power the role gives.
>
> At same time, it kind of would be nice to make scope actually matter. As
> admin you have a role on Project X, yet you can now (while scoped to this
> project) pretty much do anything anywhere! I think global roles is a great
> step in the right direction, but beyond and after that we need to seriously
> start looking at making scope itself matter, so that giving someone 'admin'
> or some such on a project actually only gives them something akin to
> project_admin or some sort of admin-lite powers scoped to that project and
> sub-projects. That though falls into the policy work being done, but should
> be noted, as it is related.
>
> Still, at least global scope for roles make the superuser case make some
> actual sense, because (and I can't speak for other deployers), we have one
> project pretty much dedicated as an "admin_project" and it's just odd to
> actually need to give our service users roles in a project when that
> project is empty and a pointless construct for their purpose.
>
> Also thanks for pushing this! I've been watching your global roles spec
> review in hopes we'd go down that path. :)
>
> -Adrian
>
> ___
> OpenStack-operators mailing 
> listOpenStack-operators@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev