summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLance Bragstad <lbragstad@gmail.com>2018-09-13 20:22:41 +0000
committerLance Bragstad <lbragstad@gmail.com>2018-10-23 09:31:33 +0000
commitf98da512ea240d5b7644997dea52f4a1314b54d6 (patch)
treeb09b911a972b78eab6632ae94b70582829772d89
parent9c70ba90718243ebf79e554e1299484faa16f485 (diff)
Update policy security roadmap
Some things have changed since this was originally written and this patch attempts to update those things. Change-Id: Ibc24b4192f5cec2efa4eef79e94bdbcf27ffc162
Notes
Notes (review): Code-Review+2: wangxiyuan <wangxiyuan@huawei.com> Code-Review+2: Colleen Murphy <colleen@gazlene.net> Workflow+1: Colleen Murphy <colleen@gazlene.net> Verified+2: Zuul Submitted-by: Zuul Submitted-at: Wed, 07 Nov 2018 13:39:52 +0000 Reviewed-on: https://review.openstack.org/602443 Project: openstack/keystone-specs Branch: refs/heads/master
-rw-r--r--specs/keystone/ongoing/policy-security-roadmap.rst40
1 files changed, 9 insertions, 31 deletions
diff --git a/specs/keystone/ongoing/policy-security-roadmap.rst b/specs/keystone/ongoing/policy-security-roadmap.rst
index ed35241..833f0f9 100644
--- a/specs/keystone/ongoing/policy-security-roadmap.rst
+++ b/specs/keystone/ongoing/policy-security-roadmap.rst
@@ -13,9 +13,9 @@ The implementation is complicated to understand, inconsistent across projects,
13and exposes security issues across OpenStack. 13and exposes security issues across OpenStack.
14 14
15The purpose of this document is to describe the steps necessary to close 15The purpose of this document is to describe the steps necessary to close
16security flaws within the current Role Based Access Control (RBAC) of 16security flaws within the current Role Based Access Control (RBAC)
17OpenStack. Roadmaps to improve delegation usecases and policy will be covered 17implementation used by OpenStack. Roadmaps to improve delegation usecases and
18in a separate document. 18policy will be covered in a separate document.
19 19
20Problem Description 20Problem Description
21=================== 21===================
@@ -130,34 +130,12 @@ communicating proper scope. In the current system, only two scopes are really
130represented within OpenStack. The first is `unscoped`, which can be thought of 130represented within OpenStack. The first is `unscoped`, which can be thought of
131as a valid authentication with an empty set of operations. The second is 131as a valid authentication with an empty set of operations. The second is
132`project-scoped`, which is a valid authentication of a user with a role on a 132`project-scoped`, which is a valid authentication of a user with a role on a
133specific project. A third scope exists, but is rarely used outside of the 133specific project. These scopes are the most commonly used scopes within
134identity service and that is `domain-scoped`. There isn't an existing mechanism 134OpenStack. However, the identity system supports two additional scopes. One is
135to denote `system-scope`, nor does the assignment mechanisms within identity 135called `domain-scoped`, which is a valid authentication of a user with a role
136allow for it. 136on a domain. The other is called `system-scope`, which is a valid
137 137authentication of a user with a role on the deployment system and meant to be
138The first step of this item would be to advertise proper `system-scope`. This 138used to access system specific resources.
139requires keystone to understand system scope. One way to do this would be to
140allow the use of system role assignments. Currently, role assignments must
141consist of a user or group on a project or a domain. This would have to change
142to allow for assignments on a `system` scope. In addition to allowing roles to
143be assigned on the system, the existing scope mechanisms will need to be
144modified to allow users to obtain system-scoped tokens.
145
146The 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
154Work 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.
161 139
162Consuming Libraries 140Consuming Libraries
163------------------- 141-------------------