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

[Adrian Turjak]

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 list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Marc Heckmann]

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

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.

-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 
mailto: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!


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 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

Re: [Openstack-operators] [openstack-dev] [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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Marc Heckmann]

See below.

On Thu, 2017-05-25 at 15:49 -0500, Lance Bragstad wrote:


On Thu, May 25, 2017 at 2:36 PM, Marc Heckmann 
mailto:marc.heckm...@ubisoft.com>> 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)?


Maybe I'm over-simplifying, but if properly documented I would expect there to 
be a cut-over release at some point where we would need to switchover and 
create the proper globally scoped role(s). I guess we could live with 
is_admin_project for 2-3 releases in the interim.

-m


-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 
mailto: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!


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 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.open

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

[joehuang]

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 
mailto: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 e

Re: [Openstack-operators] [openstack-dev] [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-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 
> wrote:
>
>> Hey all,
>>
>> To date 

Re: [Openstack-operators] [openstack-dev] [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-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

Re: [Openstack-operators] [openstack-dev] [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-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
>

Re: [Openstack-operators] [openstack-dev] [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-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 l

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

[Marc Heckmann]

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.

-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 
mailto: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 
mailto: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 
mailto: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 
mailto: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 user

Re: [Openstack-operators] [openstack-dev] [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-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 seve

Re: [Openstack-operators] [openstack-dev] [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-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 u

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

[Marc Heckmann]

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
> > >  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-operators@lists.openstack.org
> > > Subject: Re: [openstack-dev]
> > > [keystone][nova]

Re: [Openstack-operators] [openstack-dev] [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
> > > >  wrote:
> > > >
> > > > Hi,
> > > > thanks for bringing this into discussion in the Operators list.
> > > >
> > > > Option 1 and 2 and not co