From 4c36cefc8dfb7644e58d722d11ad9b37922e3d55 Mon Sep 17 00:00:00 2001 From: Lance Bragstad Date: Wed, 26 Apr 2017 23:03:09 +0000 Subject: [PATCH] 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 Co-Authored-By: John Garbutt Change-Id: I57b2b38db8d5d9368a1056363a87788572712338 --- specs/keystone/ongoing/policy-goals.rst | 114 ++++++++++++++++++++++++ 1 file changed, 114 insertions(+) create mode 100644 specs/keystone/ongoing/policy-goals.rst diff --git a/specs/keystone/ongoing/policy-goals.rst b/specs/keystone/ongoing/policy-goals.rst new file mode 100644 index 00000000..90166521 --- /dev/null +++ b/specs/keystone/ongoing/policy-goals.rst @@ -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 `_, +`tags `_, +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 `_ +* `Role Check from Middleware specification `_ +* `Tokens with subsets of roles specification `_ +* `Role Check on Body Key specification `_ +* `Dynamic RBAC Policy specification `_ +* `Policy Merge specification `_ +* `Fetch Policy by Tag specification `_ +* `Policy rules managed from a database specification `_ +* `Add policy-remove-scope-checks specification `_ +* `Add additional-default-policy-roles specification `_ +* `Add policy-docs specification `_ +* `Capability API spec `_