Browse Source

Update policy security roadmap

Some things have changed since this was originally written and this
patch attempts to update those things.

Change-Id: Ibc24b4192f5cec2efa4eef79e94bdbcf27ffc162
changes/43/602443/2
Lance Bragstad 9 months ago
parent
commit
f98da512ea
1 changed files with 9 additions and 31 deletions
  1. 9
    31
      specs/keystone/ongoing/policy-security-roadmap.rst

+ 9
- 31
specs/keystone/ongoing/policy-security-roadmap.rst View File

@@ -13,9 +13,9 @@ The implementation is complicated to understand, inconsistent across projects,
13 13
 and exposes security issues across OpenStack.
14 14
 
15 15
 The purpose of this document is to describe the steps necessary to close
16
-security flaws within the current Role Based Access Control (RBAC) of
17
-OpenStack. Roadmaps to improve delegation usecases and policy will be covered
18
-in a separate document.
16
+security flaws within the current Role Based Access Control (RBAC)
17
+implementation used by OpenStack. Roadmaps to improve delegation usecases and
18
+policy will be covered in a separate document.
19 19
 
20 20
 Problem Description
21 21
 ===================
@@ -130,34 +130,12 @@ communicating proper scope. In the current system, only two scopes are really
130 130
 represented within OpenStack. The first is `unscoped`, which can be thought of
131 131
 as a valid authentication with an empty set of operations. The second is
132 132
 `project-scoped`, which is a valid authentication of a user with a role on a
133
-specific project. A third scope exists, but is rarely used outside of the
134
-identity service and that is `domain-scoped`. There isn't an existing mechanism
135
-to denote `system-scope`, nor does the assignment mechanisms within identity
136
-allow for it.
137
-
138
-The first step of this item would be to advertise proper `system-scope`. This
139
-requires keystone to understand system scope. One way to do this would be to
140
-allow the use of system role assignments. Currently, role assignments must
141
-consist of a user or group on a project or a domain. This would have to change
142
-to allow for assignments on a `system` scope. In addition to allowing roles to
143
-be assigned on the system, the existing scope mechanisms will need to be
144
-modified to allow users to obtain system-scoped tokens.
145
-
146
-The following are assumptions about the system scoping mechanism:
147
-
148
-* A request for a system-scoped token returns a token with
149
-  `token.system={'all'=True}` for a specific role or roles.
150
-* System scoping should not be piggy-backed onto unscoped requests. Doing so
151
-  could lead to security vulnerabilities given the existing usage pattern of
152
-  unscoped tokens today.
153
-
154
-Work Items
155
-~~~~~~~~~~
156
-
157
-* Make it so assignments can be set on the system (e.g. `openstack role add
158
-  --user Bob --system observer`) in both the client and identity server.
159
-* Introduce a new scoping mechanism that distinguishes `system-scope` from
160
-  `project-scoped`, `domain-scoped`, and `unscoped` requests.
133
+specific project. These scopes are the most commonly used scopes within
134
+OpenStack. However, the identity system supports two additional scopes. One is
135
+called `domain-scoped`, which is a valid authentication of a user with a role
136
+on a domain. The other is called `system-scope`, which is a valid
137
+authentication of a user with a role on the deployment system and meant to be
138
+used to access system specific resources.
161 139
 
162 140
 Consuming Libraries
163 141
 -------------------

Loading…
Cancel
Save