Browse Source

Follow-up -- replace 'auditor' role with 'reader'

Follow-up patch after Vancouver summit. After discussion the term
'reader' was determined to be more appropriate than 'auditor' as
a default name for roles.

Change-Id: Ia99807952d4f1025a69e9c94edf1ea949afb7d09
Harry Rybacki 11 months ago
parent
commit
0dd3d3f6e6
1 changed files with 20 additions and 20 deletions
  1. 20
    20
      specs/keystone/rocky/define-default-roles.rst

+ 20
- 20
specs/keystone/rocky/define-default-roles.rst View File

@@ -56,8 +56,8 @@ use to adopt the proposed default roles in a future `community goal
56 56
 Default Roles
57 57
 -------------
58 58
 
59
-**auditor**: It should only be used for read-only APIs and operations. Alternatively
60
-referred to as ``reader``, this role fills an extremely popular need from operators.
59
+**reader**: It should only be used for read-only APIs and operations. Alternatively
60
+referred to as ``readonly`` or ``observer``, this role fills an extremely popular need from operators.
61 61
 
62 62
 **member**: serves as the
63 63
 general purpose ‘do-er’ role. It introduces granularity between the administrator(s)
@@ -87,7 +87,7 @@ along with relevant historical context justifying the `need for system-scope
87 87
 Examples
88 88
 --------
89 89
 
90
-`auditor:`
90
+`reader:`
91 91
 An example project-scoped application of this role would be listing project tags (``identity:get_project_tags``).
92 92
 An example system-scoped application of this role would be listing service endpoints
93 93
 (``identity:list_endpoints``).
@@ -108,7 +108,7 @@ It serves merely as a snippet of existing rules to showcase how policies, scope,
108 108
 default roles can work together to provide a richer policy experience.
109 109
 
110 110
 +-------------+------------------------------+---------------------------------+---------------------------------+
111
-|             | auditor                      | member                          | admin                           |
111
+|             | reader                       | member                          | admin                           |
112 112
 +=============+==============================+=================================+=================================+
113 113
 | **Project** | * identity:list_project_tags | * identity:list_project_tags    | * identity:list_project_tags    |
114 114
 |             | * identity:get_project_tag   | * identity:get_project_tag      | * identity:get_project_tag      |
@@ -133,13 +133,13 @@ the following.
133 133
   The default roles discussed will be created by Keystone, during the bootstrap process, using `implied roles
134 134
   <https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_.
135 135
   As indicated in the above table, having ``admin`` role implies a user also has the same rights as
136
-  the ``member`` role. Therefore this user will also has the same rights as the ``auditor`` role as
137
-  ``member`` implies ``auditor``.
136
+  the ``member`` role. Therefore this user will also has the same rights as the ``reader`` role as
137
+  ``member`` implies ``reader``.
138 138
 
139 139
   This keeps policy files clean. For example:
140 140
 
141
-  "identity:list_endpoints": "role:auditor OR role:member OR role:admin" is equivalent to
142
-  "identity:list_endpoints": "role:auditor" as a result of the implied roles chain.
141
+  "identity:list_endpoints": "role:reader OR role:member OR role:admin" is equivalent to
142
+  "identity:list_endpoints": "role:reader" as a result of the implied roles chain.
143 143
 
144 144
    The chain of implied roles will be documented alongside of the `policy-in-code defaults
145 145
    <https://github.com/openstack/keystone/blob/master/keystone/common/policies/base.py>`_ in addition to
@@ -148,15 +148,15 @@ the following.
148 148
 ::
149 149
 
150 150
     # scope_types = ('project')
151
-    "identity:list_project_tags": "role:auditor"
152
-    "identity:get_project_tag": "role:auditor"
151
+    "identity:list_project_tags": "role:reader"
152
+    "identity:get_project_tag": "role:reader"
153 153
     "identity:update_project_tags": "role:member"
154 154
     "identity:create_project_tag": "role:admin"
155 155
     "identity:delete_project_tags": "role:admin"
156 156
 
157 157
     # scope_types = ('system')
158
-    "identity:list_endpoints": "role:auditor"
159
-    "identity:get_endpoints": "role:auditor"
158
+    "identity:list_endpoints": "role:reader"
159
+    "identity:get_endpoints": "role:reader"
160 160
     "identity:update_endpoint": "role:member"
161 161
     "identity:create_endpoint": "role:admin"
162 162
     "os_compute_api:os-hypervisors": "role:admin"
@@ -165,10 +165,10 @@ the following.
165 165
 
166 166
 Let's assume the following role assignment exist:
167 167
 
168
-- **Alice** has role **auditor** on system
168
+- **Alice** has role **reader** on system
169 169
 - **Bob** has the role **member** on system
170 170
 - **Charlie** has role **admin** on system
171
-- **Qiana** has role **auditor** on Project Alpha
171
+- **Qiana** has role **reader** on Project Alpha
172 172
 - **Rebecca** has role **member** on Project Alpha
173 173
 - **Steve** has role **admin** on Project Alpha
174 174
 
@@ -201,15 +201,15 @@ Risk Mitigation
201 201
 
202 202
 **Scenario One -- A role serving the purposes described in this spec exists under another name**:
203 203
 Let us assume that Deployment A already has ``Role X`` which serves the purpose of the proposed here as
204
-the ``auditor`` role. In this instance, it is reasonable to assume that operators may have custom policy
204
+the ``reader`` role. In this instance, it is reasonable to assume that operators may have custom policy
205 205
 work in place and do not want to port immediately.
206 206
 
207 207
 This issue may be mitigated through the use of implied roles. Operators need simply to ensure that
208
-``auditor`` implies ``Role X``. Please review the documentation on `implied roles
208
+``reader`` implies ``Role X``. Please review the documentation on `implied roles
209 209
 <https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/implied_role.html>`_. for
210 210
 specific instructions on how make one role imply another.
211 211
 
212
-**Scenario Two -- An existing ``auditor``, ``member``, or ``admin`` role already exists**: Let us assume
212
+**Scenario Two -- An existing ``reader``, ``member``, or ``admin`` role already exists**: Let us assume
213 213
 that Deployment B already has a ``member`` role. Keystone will not attempt to overwrite any existing roles
214 214
 that have been populated. It will instead note that a role with the name ``member`` already exists in log
215 215
 output.
@@ -217,8 +217,8 @@ output.
217 217
 Alternatives
218 218
 ------------
219 219
 
220
-reader/writer/admin vs auditor/member/admin. There was much debate regarding the naming
221
-conventions for these roles. We have opted to use `auditor`, `member`, and `admin` as we
220
+reader/writer/admin vs reader/member/admin. There was much debate regarding the naming
221
+conventions for these roles. We have opted to use `reader`, `member`, and `admin` as we
222 222
 believe they most accurately describe their purpose when the context of OpenStack is taken
223 223
 into consideration.
224 224
 
@@ -237,7 +237,7 @@ Work Items
237 237
 ----------
238 238
 
239 239
 * Add ability for Keystone bootstrap to create proposed roles
240
-* Implement auditor role across policies
240
+* Implement reader role across policies
241 241
 * Implement member role across policies
242 242
 * Implement admin role across policies
243 243
 * Implement scope_types for all policies in Keystone

Loading…
Cancel
Save