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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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.


On Tue, Jun 6, 2017 at 10:01 AM, Lance Bragstad <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
I think a option 2 is better. 

Best Regards
Chaoyi Huang (joehuang)

From: Lance Bragstad [[hidden email]]
Sent: 25 May 2017 3:47
To: OpenStack Development Mailing List (not for usage questions); [hidden email]
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!



On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <[hidden email]> 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!




_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators


_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators





_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [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 <[hidden email]>
> wrote:
> >
> >
> > On Tue, Jun 6, 2017 at 3:06 PM, Marc Heckmann <marc.heckmann@ubisof
> > 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 <lbragstad@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 <[hidden email]
> > > 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
> > > <[hidden email]> 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 <[hidden email]>
> > > wrote:
> > >
> > > I think a option 2 is better.
> > >
> > > Best Regards
> > > Chaoyi Huang (joehuang)
> > > ________________________________
> > > From: Lance Bragstad [[hidden email]]
> > > Sent: 25 May 2017 3:47
> > > To: OpenStack Development Mailing List (not for usage questions);
> > > [hidden email]
> > > 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/3d033df1c0fdc6cc9d2b02
> > > a702efca286371f2bd/etc/keystone.conf.sample#L2334-L2342
> > >
> > > On Wed, May 24, 2017 at 10:35 AM, Lance Bragstad <lbragstad@gmail
> > > .com>
> > > wrote:
> > >
> > > Hey all,
> > >
> > > To date we have two proposed solutions for tackling the admin-
> > > ness issue
> > > we have across the services. One builds on the existing scope
> > > concepts by
> > > scoping to an admin project [0]. The other introduces global role
> > > assignments [1] as a way to denote elevated privileges.
> > >
> > > I'd like to get some feedback from operators, as well as
> > > developers from
> > > other projects, on each approach. Since work is required in
> > > keystone, it
> > > would be good to get consensus before spec freeze (June 9th). If
> > > you have
> > > specific questions on either approach, feel free to ping me or
> > > drop by the
> > > weekly policy meeting [2].
> > >
> > > Thanks!
> > >
> > > [0] http://adam.younglogic.com/2017/05/fixing-bug-96869/
> > > [1] https://review.openstack.org/#/c/464763/
> > > [2] http://eavesdrop.openstack.org/#Keystone_Policy_Meeting
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > [hidden email]
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > [hidden email]
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > >
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > [hidden email]
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > OpenStack-operators mailing list
> > > [hidden email]
> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-ope
> > > rators
> >
> >
> >
> > _______________________________________________
> > OpenStack-operators mailing list
> > [hidden email]
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-opera
> > tors
> >
_______________________________________________
OpenStack-operators mailing list
[hidden email]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Loading...