Feedback Request from Keystone PTL

Owned by Andrew Ukasick
Last updated: Jun 22, 2017


See email below from Lance Bragstad, the Keystone PTL.

---------- Forwarded message ----------
From: Lance Bragstad <lbragstad@gmail.com>
Date: Fri, Jun 2, 2017 at 12:51 PM
Subject: Policy/RBAC Feedback
To: Gage Hugo <gagehugo@gmail.com>

Hey Gage,

 

Per our conversation on IRC earlier. Here are the things I'm looking for in feedback from operators that I think will drive us towards better policy across OpenStack. I'll preface my feedback asks with a summary of where I think some of the direction is heading and what we have on the table.

 

Summary

 

OpenStack has a lot of policy problems. Policy defaults or how we manage it hasn't really evolved in the last five years, even though OpenStack has. After spending the last 6 - 9 months working on policy, I think our work breaks down into three things. The first is fixing admin-ness, the second is discoverability, and the third is to enhance policy usability via better roles/defautls/etc.

 

Fixing Admin-ness

 

So, this is the bug [0] that we've had open *forever* (chrome literally auto-completes the URL for me when I start typing bugs.launchpad). The net of it is that when you give a user the `admin` role on a project, they get `admin` everywhere. The current authorization model used across OpenStack doesn't do a good job of distinguishing between project specific operations and global operations. I've attempted to explained this in greater detail [1] [2]. This is easier (at least for me) to see in an example. When you create an instance, it needs to be owned by a project. In order to have nova do that for you, you need to have a project scoped token. Project-scoped tokens are a good solution for this since instances must live within projects. On the other hand, endpoints or services are global resources that tie to the underlying infrastructure of the deployment. An endpoint or a service isn't really suppose to be associated with a project. So getting a project scoped token to make changes to an endpoint, or add a service is a little strange.

 

The good news is that we have two proposals on the table for solving this issue. I've attempted to summarize these two approaches in a separate thread on the operator and dev mailing lists [3] [4]. Where I'd love to get feedback with respect to this specific policy problem, is how operators ideally want to manage global privileges in OpenStack? Do they want to have a single `admin_project` specified in configuration and all global assignments are derived from that project? Or do they want to us to introduce global role assignments [5]?

 Comments...

Operation and Role Discoverability 

 

Today it is really hard for API users to figure out what they can do in a deployment. Adam's RBAC in middleware approach [6] tries to mitigate this by making it so keystone is the place where you associate operations. It be great to have operator feedback on that specific approach and see if that's how operators visualize policy management 2 - 5 years down the road and how that specific implementation can play into upgrades, etc.

 

I think being able to answer the question "What can I do in this deployment?" is something that can be answered by a capabilities API. Several of the services (nova and cinder for sure) have expressed interest in developing a capabilities API. It would take a token and build a list of operations that user can do based on not only their role assignments, but also how the deployment is configured. For example, a user might have the role to do live migrations, but if nova isn't configured with a virtualization driver that supports live migrations, then the user shouldn't see live_migrate in their list of capabilities (it would be misleading otherwise and frustrating for users to be presented with somewhat false information). Keystone can help answer part of that question, but the other part of that question kinda needs to be answered by the service. I think if we were able to get each service in a better place with policy, we might be able to help develop consistent capability APIs in each service (this would be a ton of work, but seems to be the best option I can come up with from a user experience perspective).

 

I'd love feedback here.

  Comments...

Enhancing Policy 

 

Outside of the first two topics, this seems to be the catch all for everything else we could do to make policy/RBAC easier. I've had discussions with various members of other projects about standardizing a new set of roles across OpenStack and moving to those by default [7] [8]. If you've used GCE, they have a *ton* of roles setup for your account by default when you sign up. It'd be great to try and strive for something like that with OpenStack (I think this would be a huge interoperability win for OpenStack because it would eliminate the needs for most custom policies, I hope anyway). In addition to having better defaults, it would be nice to build on all this work to find a way to do per-resource policy. For example, if we're both members of the same project and I go on vacation, it would be great for me to setup a policy that let's you reboot my instance if it starts acting up (this is kind of similar to what AWS does with policy, which is lightyears from where we are today). I haven't been able to come up with a solution for this yet, but I would also classify it as a long-term policy goal at this point with all the other work we have to do.

 

I'd love to hear what long term things operators want from policy/RBAC in general so we can start thinking about those things now.

  Comments...

 

Thanks for taking point on this, Gage. I appreciate you being the liaison here. Let me know if there is anything about this note that needs further clarification.

 

Have a great weekend,

 

Lance

 

 

[0] https://bugs.launchpad.net/keystone/+bug/968696

[1] https://review.openstack.org/#/c/460344/

[2] https://review.openstack.org/#/c/462733/

[3] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117419.html

[4] http://lists.openstack.org/pipermail/openstack-dev/2017-May/117441.html

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

[6] https://review.openstack.org/#/c/452198/

[7] https://review.openstack.org/#/c/428454/

[8] https://github.com/lbragstad/orbac (some of the info here might be a bit stale - I was working with John Garbutt on this and had to write it down somewhere)