Update policy security roadmap
Some things have changed since this was originally written and this patch attempts to update those things. Change-Id: Ibc24b4192f5cec2efa4eef79e94bdbcf27ffc162
This commit is contained in:
parent
9c70ba9071
commit
f98da512ea
|
@ -13,9 +13,9 @@ The implementation is complicated to understand, inconsistent across projects,
|
||||||
and exposes security issues across OpenStack.
|
and exposes security issues across OpenStack.
|
||||||
|
|
||||||
The purpose of this document is to describe the steps necessary to close
|
The purpose of this document is to describe the steps necessary to close
|
||||||
security flaws within the current Role Based Access Control (RBAC) of
|
security flaws within the current Role Based Access Control (RBAC)
|
||||||
OpenStack. Roadmaps to improve delegation usecases and policy will be covered
|
implementation used by OpenStack. Roadmaps to improve delegation usecases and
|
||||||
in a separate document.
|
policy will be covered in a separate document.
|
||||||
|
|
||||||
Problem Description
|
Problem Description
|
||||||
===================
|
===================
|
||||||
|
@ -130,34 +130,12 @@ communicating proper scope. In the current system, only two scopes are really
|
||||||
represented within OpenStack. The first is `unscoped`, which can be thought of
|
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
|
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
|
`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
|
specific project. These scopes are the most commonly used scopes within
|
||||||
identity service and that is `domain-scoped`. There isn't an existing mechanism
|
OpenStack. However, the identity system supports two additional scopes. One is
|
||||||
to denote `system-scope`, nor does the assignment mechanisms within identity
|
called `domain-scoped`, which is a valid authentication of a user with a role
|
||||||
allow for it.
|
on a domain. The other is called `system-scope`, which is a valid
|
||||||
|
authentication of a user with a role on the deployment system and meant to be
|
||||||
The first step of this item would be to advertise proper `system-scope`. This
|
used to access system specific resources.
|
||||||
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
|
Consuming Libraries
|
||||||
-------------------
|
-------------------
|
||||||
|
|
Loading…
Reference in New Issue