From e1491f364fea7e66c26e798dc0deb99368d2866b Mon Sep 17 00:00:00 2001 From: Lance Bragstad Date: Thu, 4 May 2017 15:52:19 -0500 Subject: [PATCH] Add policy roadmap for security Add a roadmap that describes the long term policy vision that eliminates the security issues we have today. Co-Authored-By: Matthew Edmonds Co-Authored-By: Adam Young Change-Id: I0b639640764aedbeb17765a337ac640418138533 --- .../ongoing/policy-security-roadmap.rst | 199 ++++++++++++++++++ 1 file changed, 199 insertions(+) create mode 100644 specs/keystone/ongoing/policy-security-roadmap.rst diff --git a/specs/keystone/ongoing/policy-security-roadmap.rst b/specs/keystone/ongoing/policy-security-roadmap.rst new file mode 100644 index 00000000..ed352410 --- /dev/null +++ b/specs/keystone/ongoing/policy-security-roadmap.rst @@ -0,0 +1,199 @@ +.. + This work is licensed under a Creative Commons Attribution 3.0 Unported + License. + + http://creativecommons.org/licenses/by/3.0/legalcode + +======================= +Policy Security Roadmap +======================= + +Policy in OpenStack has long been the forefront of operator concerns and pain. +The implementation is complicated to understand, inconsistent across projects, +and exposes security issues across OpenStack. + +The purpose of this document is to describe the steps necessary to close +security flaws within the current Role Based Access Control (RBAC) of +OpenStack. Roadmaps to improve delegation usecases and policy will be covered +in a separate document. + +Problem Description +=================== + +Identity and access management systems are responsible for allowing and denying +access to resources of the service based on identities. One way to achieve this +is by using Role Based Access Control (RBAC). RBAC is a security model that +allows access to resources through roles, which can be assigned to users or +identities. + +OpenStack services base many of their operations within the context of a +project. For our purposes, projects can be thought of as logical containers of +resources. For example, an instance is owned by a project, meaning the instance +should be accessible from within that project but not outside of it. This helps +OpenStack model multiple organizations within a single deployment while +maintaining a level of separation or multi-tenancy. A side-effect is that this +introduces an additional level of complexity to OpenStack's access control +model. Not only does the entire system need to be aware of identities, roles, +and assignment, but it also needs to properly account for scope of specific +operations. + +As a result, OpenStack relies on a derivative of the RBAC model unofficially +referenced as scoped-RBAC. + +The scoped-RBAC model builds upon all assumptions of traditional RBAC, but adds +the concept of scope to the implementation. This would be the ideal model for +OpenStack if all operations within OpenStack aligned nicely within projects. +However, this is not the case. To highlight this more effectively, let's use +some examples. + +Example One +----------- + +Let's assume we would like to create an instance. We've already established +that instances should be contained within projects, so it makes sense to apply +the scope of the project we want to own the instance in to the request for +creating the instance (e.g. Bob wants to create an instance in the `Staging` +project, so first he gets a token scoped to the `Staging` project to send with +his compute API request for an instance). + +This example clearly shows how scoped-RBAC works well with resource operations +that map properly to project scope. + +Example Two +----------- + +Let's look at an example of the opposite case. Let's assume we would +like to live migrate an instance from one compute host to another so that we +can perform some maintenance. That host could be responsible for instances that +are owned by different projects. Which project should you scope to such that +you can live migrate instances off a host for maintenance without violating +multi-tenant separation of concerns? + +This is an example of an operation that doesn't fit well within the construct +of a project. Instead, live migration is more of a system-wide operation that +is independent of a specific project. + +Summary +------- + +Some operations within OpenStack work nicely with the concept of project scope, +while others do not. Further reading and context on this can be found in +`bug 968696 `_, which +highlights the issues of scoped-RBAC for system-wide OpenStack operations and +resources. + +One of the more problematic side-effects of the existing implementation that +operators have to deal with is choosing the lesser of two evils when violating +the principal of least privilege. The principal of least privilege states that +a user should have only the permissions necessary to carry out their duties and +nothing more. The current gap between system-scoped and project-scoped +operations or resources forces operators to either grant too many permissions +for the user or not give the user enough permissions to effectively do their +job. It's apparent that granting too many permissions violates the principal of +least privilege, but it's arguably true for the inverse, since too much +restriction doesn't let the user effectively do their job. + +Road Map +======== + +This road map attempts to describe the steps necessary to mitigate the issues +outlined above by painting a picture of what the long term vision of policy in +OpenStack should be. Each of the following sections denotes a piece of work in +a sequence that results in a desired end state. + +Reclassifying Operation & Scope +------------------------------- + +Based on the example operations in the previous section, a good starting place +might be reassessing each operation and what the ideal scope should be. The +majority of this work could be considered preparation for consuming proper +scope from an identity system. Ideally, the responsibility of the service in +this case should be to compare the operation being done on a resource to a +scope provided by the identity system (e.g. does the instance being modified in +this request belong to the project the token is scoped to). + +Work Items +~~~~~~~~~~ + +The following work items are needed to satisfy this item: + +* Split the role check from the scope check in each service. +* Isolate the logic for scope checks into consistent patterns or in a + consumable library. +* Assess each operation and associate which scope, or scopes, are appropriate. + +Communicating Difference in Scope +--------------------------------- + +The next step, which could be worked in parallel to the previous step, is +communicating proper scope. In the current system, only two scopes are really +represented within OpenStack. The first is `unscoped`, which can be thought of +as a valid authentication with an empty set of operations. The second is +`project-scoped`, which is a valid authentication of a user with a role on a +specific project. A third scope exists, but is rarely used outside of the +identity service and that is `domain-scoped`. There isn't an existing mechanism +to denote `system-scope`, nor does the assignment mechanisms within identity +allow for it. + +The first step of this item would be to advertise proper `system-scope`. This +requires keystone to understand system scope. One way to do this would be to +allow the use of system role assignments. Currently, role assignments must +consist of a user or group on a project or a domain. This would have to change +to allow for assignments on a `system` scope. In addition to allowing roles to +be assigned on the system, the existing scope mechanisms will need to be +modified to allow users to obtain system-scoped tokens. + +The following are assumptions about the system scoping mechanism: + +* A request for a system-scoped token returns a token with + `token.system={'all'=True}` for a specific role or roles. +* System scoping should not be piggy-backed onto unscoped requests. Doing so + could lead to security vulnerabilities given the existing usage pattern of + unscoped tokens today. + +Work Items +~~~~~~~~~~ + +* Make it so assignments can be set on the system (e.g. `openstack role add + --user Bob --system observer`) in both the client and identity server. +* Introduce a new scoping mechanism that distinguishes `system-scope` from + `project-scoped`, `domain-scoped`, and `unscoped` requests. + +Consuming Libraries +------------------- + +Now that we have a way to assign roles on the system and scope tokens to that +context, we need to ensure the consuming libraries handle these changes +properly. Most OpenStack projects consuming tokens from keystone to enforce +policies do so through the use of `oslo.context`. The token response is used to +build a context dictionary using `oslo.context`. The project uses attributes of +the context dictionary to make assertions about authorization scope. We need to +ensure `oslo.context` properly handles this new scope. + +Once those changes are made, the keystone team should be in a great place to +help other projects consume these changes. This might consist of helping other +projects separate their scope check from the role check or classifying +different scopes required for operations. + +Work Items +~~~~~~~~~~ + +* Add support to `oslo.context` and `oslo.policy` for consuming system-scoped + tokens and relaying that information in generated contexts for projects to + consume. + +Conclusion +========== + +The end results should consist of an easy-to-use mechanism for granting system +roles, a clear interface for denoting scope to services, and a straight forward +policy pattern that projects can use to evaluate scope. + +References +========== + +The following are references to past or present specifications: + +* `RBAC `_ +* `Admin-ness bug `_ +* `System Scope Specification `_