1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
|
=============
Default Roles
=============
------
Primer
------
Like most OpenStack services, keystone protects its API using role-based access
control (RBAC).
Users can access different APIs depending on the roles they have on a project,
domain, or system.
As of the Rocky release, keystone provides three roles called ``admin``,
``member``, and ``reader`` by default. Operators can grant these roles to any
actor (e.g., group or user) on any target (e.g., system, domain, or project).
If you need a refresher on authorization scopes and token types, please refer
to the `token guide`_. The following sections describe how each default role
behaves with keystone's API across different scopes.
Default roles and behaviors across scopes allow operators to delegate more
functionality to their team, auditors, customers, and users without maintaining
custom policies.
.. _`token guide`: https://docs.openstack.org/keystone/latest/admin/tokens-overview.html#authorization-scopes
-----------------
Roles Definitions
-----------------
The default roles imply one another. The ``admin`` role implies the ``member``
role, and the ``member`` role implies the ``reader`` role. This implication
means users with the ``admin`` role automatically have the ``member`` and
``reader`` roles. Additionally, users with the ``member`` role automatically
have the ``reader`` role. Implying roles reduces role assignments and forms a
natural hierarchy between the default roles. It also reduces the complexity of
default policies by making check strings short. For example, a policy that
requires ``reader`` can be expressed as:
.. code-block:: yaml
"identity:list_foo": "role:reader"
Instead of:
.. code-block:: yaml
"identity:list_foo": "role:admin or role:member or role:reader"
Reader
======
The ``reader`` role provides read-only access to resources within the system, a
domain, or a project. Depending on the assignment scope, two users with the
``reader`` role can expect different API behaviors. For example, a user with
the ``reader`` role on the system can list all projects within the deployment.
A user with the ``reader`` role on a domain can only list projects within their
domain.
By analyzing the scope of a role assignment, we increase the re-usability of
the ``reader`` role and provide greater functionality without introducing more
roles. For example, to accomplish this without analyzing assignment scope, you
would need ``system-reader``, ``domain-reader``, and ``project-reader`` roles
in addition to custom policies for each service.
Member
======
Within keystone, there isn't a distinct advantage to having the ``member`` role
instead of the ``reader`` role. The ``member`` role is more applicable to other
services. The ``member`` role works nicely for introducing granularity between
``admin`` and ``reader`` roles. Other services might write default policies
that require the ``member`` role to create resources, but the ``admin`` role to
delete them. For example, users with ``reader`` on a project could list
instance, users with ``member`` on a project can list and create instances, and
users with ``admin`` on a project can list, create, and delete instances.
Service developers can use the ``member`` role to provide more flexibility
between ``admin`` and ``reader`` on different scopes.
Admin
=====
We reserve the ``admin`` role for the most privileged operations within a given
scope. It is important to note that having ``admin`` on a project, domain, or
the system carries separate authorization and are not transitive. For example,
users with ``admin`` on the system should be able to manage every aspect of the
deployment because they're operators. Users with ``admin`` on a project
shouldn't be able to manage things outside the project because it would violate
the tenancy of their role assignment (this doesn't apply consistently since
services are addressing this individually at their own pace).
.. note::
As of the Train release, keystone applies the following personas
consistently across its API.
---------------------
System Administrators
---------------------
*System administrators* are allowed to manage every resource in keystone.
System administrators are typically operators and cloud administrators. They
can control resources that ultimately affect the behavior of the deployment.
For example, they can add or remove services and endpoints in the catalog,
create new domains, add federated mappings, and clean up stale resources, like
a user's application credentials or trusts.
You can find *system administrators* in your deployment with the following
assignments:
.. code-block:: console
$ openstack role assignment list --names --system all
+-------+------------------+-----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+------------------+-----------------------+---------+--------+--------+-----------+
| admin | | system-admins@Default | | | all | False |
| admin | admin@Default | | | | all | False |
| admin | operator@Default | | | | all | False |
+-------+------------------+-----------------------+---------+--------+--------+-----------+
-------------------------------
System Members & System Readers
-------------------------------
In keystone, *system members* and *system readers* are very similar and have
the same authorization. Users with these roles on the system can view all
resources within keystone. They can audit role assignments, users, projects,
and group memberships, among other resources.
The *system reader* persona is useful for auditors or members of a support
team. You can find *system members* and *system readers* in your deployment
with the following assignments:
.. code-block:: console
$ openstack role assignment list --names --system all --role member --role reader
+--------+------------------------+-------------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------------------------+-------------------------+---------+--------+--------+-----------+
| reader | | system-auditors@Default | | | all | False |
| admin | operator@Default | | | | all | False |
| member | system-support@Default | | | | all | False |
+--------+------------------------+-------------------------+---------+--------+--------+-----------+
.. warning::
Filtering system role assignments is currently broken and is being tracked
as a `bug <https://bugs.launchpad.net/keystone/+bug/1846817>`_.
---------------------
Domain Administrators
---------------------
*Domain administrators* can manage most aspects of the domain or its contents.
These users can create new projects and users within their domain. They can
inspect the role assignments users have on projects within their domain.
*Domain administrators* aren't allowed to access system-specific resources or
resources outside their domain. Users that need control over project, group,
and user creation are a great fit for *domain administrators*.
You can find *domain administrators* in your deployment with the following role
assignment:
.. code-block:: console
$ openstack role assignment list --names --domain foobar --role admin
+-------+----------------+----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+----------------+----------------------+---------+--------+--------+-----------+
| admin | jsmith@Default | | | foobar | | False |
| admin | | foobar-admins@foobar | | foobar | | False |
+-------+----------------+----------------------+---------+--------+--------+-----------+
-------------------------------
Domain Members & Domain Readers
-------------------------------
Domain members and domain readers have the same relationship as system members
and system readers. They're allowed to view resources and information about
their domain. They aren't allowed to access system-specific information or
information about projects, groups, and users outside their domain.
The domain member and domain reader use-cases are great for auditing, support,
or monitoring the details of an account. You can find domain members and domain
readers with the following role assignments:
.. code-block:: console
$ openstack role assignment list --names --role member --domain foobar
+--------+-------------+-------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+-------------+-------+---------+--------+--------+-----------+
| member | jdoe@foobar | | | foobar | | False |
+--------+-------------+-------+---------+--------+--------+-----------+
$ openstack role assignment list --names --role reader --domain foobar
+--------+-----------------+-------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+-----------------+-------+---------+--------+--------+-----------+
| reader | auditor@Default | | | foobar | | False |
+--------+-----------------+-------+---------+--------+--------+-----------+
----------------------
Project Administrators
----------------------
*Project administrators* can only view and modify data within the project in
their role assignment. They're able to view information about their projects
and set tags on their projects. They're not allowed to view system or domain
resources, as that would violate the tenancy of their role assignment. Since
the majority of the resources in keystone's API are system and domain-specific,
*project administrators* don't have much authorization.
You can find *project administrators* in your deployment with the following
role assignment:
.. code-block:: console
$ openstack role assignment list --names --project production --role admin
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
| admin | jsmith@Default | | production@foobar | | | False |
| admin | | production-admins@foobar | production@foobar | | | False |
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
---------------------------------
Project Members & Project Readers
---------------------------------
*Project members* and *project readers* can discover information about their
projects. They can access important information like resource limits for their
project, but they're not allowed to view information outside their project or
view system-specific information.
You can find *project members* and *project readers* in your deployment with
the following role assignments:
.. code-block:: console
$ openstack role assignment list --names --project production --role member
+--------+------+--------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------+--------------------------+-------------------+--------+--------+-----------+
| member | | foobar-operators@Default | production@foobar | | | False |
+--------+------+--------------------------+-------------------+--------+--------+-----------+
$ openstack role assignment list --names --project production --role reader
+--------+-----------------+----------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+-----------------+----------------------------+-------------------+--------+--------+-----------+
| reader | auditor@Default | | production@foobar | | | False |
| reader | | production-support@Default | production@foobar | | | False |
+--------+-----------------+----------------------------+-------------------+--------+--------+-----------+
----------------
Writing Policies
----------------
If the granularity provided above doesn't meet your specific use-case, you can
still override policies and maintain them manually. You can read more about how
to do that in oslo.policy usage `documentation`_.
.. _`documentation`: https://docs.openstack.org/oslo.policy/latest/admin/index.html
|
