openstack
/
keystone-specs
Code Issues Proposed changes
keystone-specs/specs/keystone/ongoing/policy-goals.rst

5.6 KiB
Raw Blame History

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's 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: