openstack
/
keystone-specs
Code Issues Proposed changes

Outline policy goals 

This document is intended to document the goals we need from a policy
implementation. In addition to that, this document also suggests some
cross-project tools we can use to help make progress towards better
policy in OpenStack.

Co-Authored-By: Adam Young <ayoung@redhat.com>
Co-Authored-By: John Garbutt <john@johngarbutt.com>

Change-Id: I57b2b38db8d5d9368a1056363a87788572712338
This commit is contained in:
Lance Bragstad 2017-04-26 23:03:09 +00:00
parent c71305efab
commit 4c36cefc8d
1 changed files with 114 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
specs/keystone/ongoing/policy-goals.rst Normal file
View File

@ -0,0 +1,114 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
============
Policy Goals
============
Policy in OpenStack has long been the forefront of operator concerns and pain.
The implementation is complicated to understand, inconsistent across projects,
and lacks secure defaults.
The purpose of this document is to define the overall goals we need to achieve
with OpenStack policy implementation and level-set on policy terminology.
Goals
=====
The following goals increase OpenStack adoption by reducing complexity,
allowing better interoperability, and closing security gaps.
1. Administrative rights, via the `admin` role, should be treated consistently
across OpenStack. For example, granting an administrator role to a user on a
project shouldn't result in the ability to modify endpoints because
endpoints aren't a project-specific resource. Likewise, granting a user
administrative rights on the deployment system shouldn't result in the
ability to do administrative things in a specific project.
2. The mapping of policies to operations should be easy to understand,
customize, and maintain.
3. A variety of sensible roles should be available by default upon
installation, or upgrade. These roles should correspond to the default
policies provided by each project. This will require cross-project
communication to ensure the roles make sense across project boundaries.
The list above allows operators to more easily accomplish use-cases such as:
* Grant users read-only access to projects
* Grant users administrator permissions on a per-project basis
* Grant users access to a subset of resource types for a particular project
Future Goals
============
The following goals have been brought up in discussions several times. At this
point we are not ruling out the possibility of addressing these goals, but
formally recognizing them as something to be addressed after completing the
goals listed in the previous section (e.g. you must crawl before you can walk,
and walk before you can run).
1. It should be possible to delegate fine-grained access of a resource to
another user or system.
2. It should be possible to build custom policies that can take into account
users, resources, and scopes. This could result in policy being fed
different assertions on specific resources. For example, having a policy
that says a specific user can access my instance only on specific days and
only if they have specific assertions available in the SAML document they
used to authenticate.
3. It should be possible to determine what operations are available in a
deployment while taking role assignments into consideration. This needs to
be done in such a way that doesn't duplicate information across OpenStack
services or increase maintenance overhead for operators.
Cross-Project Impact
====================
Policy and Role Based Access Control (RBAC) has traditionally been thought of
as a problem space within the OpenStack Identity umbrella. While that statement
logically makes sense, the current implementation of policy is enforced across
the OpenStack services making the ownership of the problem harder to pinpoint.
Keystone currently only acts as an information point to the service, which is
ultimately responsible for enforcing the policy decision based on information
from keystone and information from the project. The OpenStack community has
made several attempts to address these issues (linked below in the References
section), but having the implementation spread across OpenStack makes it
impossible for a single project to propose and fix these issues without
cross-project buy-in.
Cross-Project Resolution
========================
If a proposed solution to one of the above goals requires a coordinated effort
between projects, we will use either `community goals <https://governance.openstack.org/tc/goals/>`_,
`tags <https://governance.openstack.org/tc/reference/tags/index.html>`_,
or both. These tools require cross-project communication, buy-in, and
commitment.
For example, one community goal might be to define a set of default roles and
another to implement them consistently across services. Once a project tests
and implements the standardized default set, they can `assert:basic-rbac` as a
project tag.
These tools weren't available when previous solutions were proposed. Now that
we can use them as a community, they are a natural fit for solving complex,
distributed problems like consistent RBAC enforcement.
References
==========
The following are references to past or present specifications:
* `Admin-ness bug <https://bugs.launchpad.net/keystone/+bug/968696>`_
* `Role Check from Middleware specification <https://review.openstack.org/#/c/391624>`_
* `Tokens with subsets of roles specification <https://review.openstack.org/#/c/186979>`_
* `Role Check on Body Key specification <https://review.openstack.org/#/c/456974>`_
* `Dynamic RBAC Policy specification <https://review.openstack.org/#/c/279379>`_
* `Policy Merge specification <https://review.openstack.org/#/c/295049>`_
* `Fetch Policy by Tag specification <https://review.openstack.org/#/c/298788>`_
* `Policy rules managed from a database specification <https://review.openstack.org/#/c/133814>`_
* `Add policy-remove-scope-checks specification <https://review.openstack.org/#/c/433037/>`_
* `Add additional-default-policy-roles specification <https://review.openstack.org/#/c/427872/>`_
* `Add policy-docs specification <https://review.openstack.org/#/c/433010/>`_
* `Capability API spec <https://review.openstack.org/#/c/386555/>`_