Browse Source

Update app cred capabilities spec

This change brings the spec, which was agreed upon nearly a year ago,
into alignment with the current proposed implementation. It also cleans
up some formatting and style issues.

Change-Id: I0bd99d24517b90f16557aadc3d721ecee9cd8eb5
Colleen Murphy 1 month ago
parent
commit
c83ae97852
1 changed files with 170 additions and 292 deletions
  1. 170
    292
      specs/keystone/stein/capabilities-app-creds.rst

+ 170
- 292
specs/keystone/stein/capabilities-app-creds.rst View File

@@ -16,7 +16,7 @@ credentials and trusts. Other than that they allow unfettered use of the roles
16 16
 being delegated in the project the application credential is created for. This
17 17
 renders application credentials questionable anywhere a least-privilege
18 18
 delegation is desired. Technically it would be possible to store a white list
19
-style list of capabilities for an application credential which other OpenStack
19
+style list of access rules for an application credential which other OpenStack
20 20
 services would then enforce. This spec outlines an approach for storing and
21 21
 handling such restrictions.
22 22
 
@@ -34,11 +34,12 @@ in the Grizzly release). Right now, trusts are used by the following projects
34 34
 among others (list may not be complete):
35 35
 
36 36
 * Heat: operations on behalf of the user at times when a token may have expired
37
-        already.
37
+  already.
38
+
38 39
 * Magnum: access to Magnum's certificate signing API and other OpenStack APIs
39
-          from inside a cluster's instances where the container orchestration
40
-          engine requires it (e.g. Glance as backend for docker-registry or
41
-          cinder as backend for docker-volume)
40
+  from inside a cluster's instances where the container orchestration engine
41
+  requires it (e.g. Glance as backend for docker-registry or cinder as backend
42
+  for docker-volume)
42 43
 
43 44
 Other projects (neutron-lbaas, Barbican) hesitate to employ trusts and
44 45
 application credentials since they are an all-or-nothing approach: they grant
@@ -78,137 +79,98 @@ The approach to implementing fine-grained permissions for application
78 79
 credentials is two-pronged. Permission data is stored in Keystone and enforced
79 80
 by keystonemiddleware as follows:
80 81
 
81
-1) Alongside an application credential, a capability list with zero or more
82
-   capabilities can be stored. An entry in this list consists of:
83
-
84
-     (a) A URL path (e.g. `/v2.1/servers` or `/v2.1/servers/{server_id}`).
85
-         This URL path must be permissible according to a URL path template
86
-         which must exist in the table of URL path templates (see `Permissible
87
-         Path Templates`_ below).
88
-     (b) A dictionary whose keys need to exactly match the placeholders in the
89
-         URL path. Both extraneous and missing keys for one or more
90
-         capabilities will cause application credential creation to fail.
91
-     (c) A request type (e.g. `GET`)
92
-     (d) A service UUID from the Keystone service catalog. This UUID is not
93
-         user provided. Instead, it is filled in from the URL template this
94
-         capability is validated against.
95
-
96
-   This list is a whitelist, e.g. any request not explicitly allowed by a
97
-   capability is rejected. Keystone itself does not validate the content of
98
-   capabilities because that would require domain knowledge of each service on
99
-   Keystone's path. Every capability must reference an row in the table
100
-   described in the `Permissible Path Templates`_ section below. If one or more
101
-   capabilities entries fail this test, API Credential creation will fail.
102
-
103
-2) A boolean `allow_chained` attribute of the application credential (`False`
104
-   by default) controls whether chained API calls, i.e. follow-up calls issued
105
-   by a service as a result of an API call permitted by a capability.  This may
106
-   only be set to `True` if all capabilities listed in the template were
107
-   validated against an URL template with its own `allow_chained` attribute set
108
-   to `True`.
109
-
110
-3) `keystonemiddleware` on the service's side receives the capability list
111
-   during token validation. It then performs templating on all entries and
112
-   checks
113
-
114
-     (a) The service's own service ID (e.g.
115
-         `ae8a69ae-3bc2-4189-88be-c0b9ea6ef06f`)
116
-     (b) The URL path (e.g. `/v2.1/servers/{*}` or
117
-         `/v2.1/servers/b2088298-50e5-4c81-8a50-66bfd1d8943b`)
118
-     (c) The request's type (e.g. `GET`)
119
-
120
-   Against every entry in the templated URL list computed from the capability
121
-   information in the token (See `URL Path Templating`_ for how it is
122
-   computed). If a capability matches the request, checking stops and the
123
-   request is handed over to `oslo.policy` for the regular role based checking.
124
-   If no capabilities match, the request is rejected right away.
125
-
126
-   There are three special cases to capability list processing:
127
-
128
-     (a) If no list is provided (i.e. if the `capabilities` attribute is
129
-         `None`), no capability checking is performed and the request is passed
130
-         to `oslo.policy` right away.
131
-     (b) If an empty list is provided (i.e. `[]`), all requests are rejected
132
-         (even if the request would otherwise pass the test in (c).
133
-     (c) If the application credential's `allow_chained` attribute is `True`
134
-         and there is a valid service token in the request,
135
-         `keystonemiddleware` passes the request to `oslo.policy` right away.
136
-
137
-Permissible Path Templates
138
---------------------------
139
-
140
-Every capability must be validated against a URL Path Template referenced by
141
-UUID upon application credential upon creation. This section describes how an
142
-operator defines such URL path templates and how they are used by Keystone.
143
-
144
-The permissible URL path templates are operator configured through the Keystone
145
-API and stored in a dedicated table in the Keystone database. Keystone will
146
-document a curated list of URL templates for those APIs where such a thing can
147
-be generated automatically. The operator can then use this list as-is in the
148
-simplest case, or modify it for their local setup as they chose. For every URL
149
-template the following information is stored:
150
-
151
-1) A service UUID that matches one of the services in the Keystone catalog.
152
-   This is copied to the capability verbatim. The service UUID is validated
153
-   upon URL template creation: it must match an existing service's UUID. This
154
-   UUID should not have a foreign key constraint so as not to create
155
-   dependencies from the catalog on URL templates or the capabilities validated
156
-   against them. If a service is deleted later, and a non-existent UUID is thus
157
-   being referenced, keystonemiddleware will reject any capabilities
158
-   referencing it since there is no service whose service UUID will match it at
159
-   that point.
160
-2) A UUID that serves as a unique resource identifier. This is used to
161
-   reference the path template to use for evaluation when creating a
162
-   capability. This reference is only used for validation upon application
163
-   credential creation and not recorded as part of the application credential.
164
-3) A URL template string, such as `/v2.1/servers/{server_id}`. The combination
165
-   of this string and the service ID from (1) must be unique. It is anchored at
166
-   the beginning of a path, i.e. capabilities' path attributes must fully match
82
+1) Alongside an application credential, a list of access rules with zero or
83
+   more access rules can be stored. An entry in this list consists of:
84
+
85
+   (a) A URL path (e.g. `/v2.1/servers`, `/v2.1/servers/*` or
86
+       `/v2.1/servers/{server_id}`). This URL path must be explicitly permitted
87
+       according to an operator-configured list of access rules (see `Access Rules
88
+       Config`_ below).
89
+   (b) A request method (e.g. `GET`)
90
+   (c) A service type (ideally matching the `published Service Types Authority`_)
91
+       from the Keystone service catalog.
92
+
93
+   This list is a whitelist, i.e. any request not explicitly allowed by an
94
+   access rule is rejected. Keystone itself does not validate the content of
95
+   access rules because that would require domain knowledge of each service in
96
+   the catalog. Every access rule must match a permitted access rule as
97
+   described in the `Access Rules Config`_ section below. If one or more
98
+   access rule entries fail this test, application credential creation will
99
+   fail.
100
+
101
+2) A future iteration of this feature will create a toggle to control whether a
102
+   service can use one of these token to make background requests on behalf of
103
+   the user, for example to allow the compute service to make requests to the
104
+   block storage service even though the block storage API wasn't explicitly
105
+   whitelisted in the application credential access rules. For the time being,
106
+   chained service requests like this will be unrestricted and will rely on
107
+   operator-configured policies to prevent abuse.
108
+
109
+3) `keystonemiddleware` on the service's side receives the access rule list
110
+   during token validation. It then checks
111
+
112
+   (a) The service type (e.g.  `compute`)
113
+   (b) The URL path (e.g. `/v2.1/servers/*` or `/v2.1/servers/{server_id}`
114
+       or `/v2.1/servers/b2088298-50e5-4c81-8a50-66bfd1d8943b`)
115
+   (c) The request method (e.g. `GET`)
116
+
117
+   Against every entry in the access rule list retrieved from the token. If an
118
+   access rule matches the request, checking stops and the request is handed over
119
+   to `oslo.policy` for the regular role based checking. If no access rules
120
+   match, the request is rejected right away.
121
+
122
+   There are three special cases to access rule list processing:
123
+
124
+   (a) If no list is provided (i.e. if the `access_rules` attribute is
125
+       `None`), no access rule checking is performed and the request is passed
126
+       to `oslo.policy` right away.
127
+   (b) If an empty list is provided (i.e. `[]`), all requests are rejected
128
+       (even if the request would otherwise pass the test in (c).
129
+   (c) If there is a valid service token in the request, `keystonemiddleware`
130
+       passes the request to `oslo.policy` right away, though a future iteration
131
+       of this feature will enable a toggle to control this behavior.
132
+
133
+.. _published Service Types Authority: https://service-types.openstack.org/
134
+
135
+Access Rules Config
136
+-------------------
137
+
138
+Every access rule must be validated against an operator-configured list upon
139
+application credential upon creation, unless the operator has explicitly
140
+configured a permissive mode that does no validation. This section describes how
141
+an operator defines a list and how they are used by Keystone.
142
+
143
+The allowed access rules are operator configured as a JSON config file on disk,
144
+with the idea that perhaps such a catalog might be exposed on service endpoints
145
+someday. Keystone will document a curated list of URL templates for those APIs
146
+where such a thing can be generated automatically. The operator can then use
147
+this list as-is in the simplest case, or modify it for their local setup as they
148
+chose. For every access rule the following information is stored:
149
+
150
+1) A service type that matches one of the services in the Keystone catalog.
151
+
152
+2) A URL path pattern, such as `/v2.1/servers/{server_id}`. The combination
153
+   of this string and the service type from (1) must be unique. It is anchored at
154
+   the beginning of a path, i.e. access rules' path attributes must fully match
167 155
    this pattern and may not be preceded or followed by extra characters. The
168 156
    template string may contain the following special wildcard templates:
169 157
 
170
-   * `{*}`: allows arbitrary strings (excluding the `/` character) in
171
-            capability enforcement.
172
-   * `{**}`: allows arbitrary strings (including the `/` character) in
173
-             capability enforcement.
158
+   * `{named_variable}`: allows arbitrary strings (excluding the `/` character).
159
+     Named placeholders in the access rule path pattern are there for
160
+     readability and direct comparison to API references and policy files, they
161
+     do not correlate to string formatting substitutions. Examples include
162
+     `{project_id}`, `{user_id}`, or `{server_id}`.
174 163
 
175
-   A user using a URL template containing wild cards for validating one of
176
-   their capabilities may substitute the wild card by any string fulfilling the
177
-   constraint imposed by the wild card. This allows the operator to be
178
-   permissive in their URL templates (to the point of only having one "{**}"
179
-   pattern in the most extreme case) and the user to be more restrictive than a
180
-   wild card template in their capabilities.
181
-4) A boolean `allow_chained` attribute (`False` by default). If this is `True`
182
-   for all URL templates referenced when creating an application credential,
183
-   that application credential's own `allow_chained` attribute may be set to
184
-   `True`.
185
-5) A list of template keys to be provided by the user (henceforth referred to
186
-   as "user template keys").
187
-6) A list of template keys to be provided from token context. (henceforth
188
-   referred to as "context template keys"). The following are available:
189
-
190
-     * `domain_id` UUID of the domain the Application Credential is scoped to
191
-       (where applicable)
192
-     * `project_id` UUID of the project the Application Credential is scoped to
193
-       (where applicable)
194
-     * `user_id` UUID of the user who created the Application Credential
195
-
196
-Between (4) and (5) all template keys in the URL template string must be
197
-covered. If this condition is not met, creation of the path template fails.
198
-
199
-URL Path Templating
200
--------------------
164
+   * `*`: allows arbitrary strings (excluding the `/` character)
201 165
 
202
-`keystonemiddleware` receives the capability list information upon token
203
-validation. It then processes each capability as follows:
166
+   * `**`: allows arbitrary strings (including the `/` character)
204 167
 
205
-1) All placeholders from the user template keys list are replaced by the
206
-   corresponding values in the user provided dictionary of values in the
207
-   capability.
208
-2) All placeholders from the context template keys list are replaced by the
209
-   corresponding values from token context.
210
-3) Wild card placeholders (`{*}`) are left in place. These will be used during
211
-   capability enforcement to match any string in the respective path component.
168
+   A user using a path pattern containing wild cards for validating one of
169
+   their access rules may substitute the wild card by any string fulfilling the
170
+   constraint imposed by the wild card. This allows the operator to be
171
+   permissive in their URL templates (to the point of only having one "**"
172
+   pattern in the most extreme case) and the user to be more restrictive than a
173
+   wild card template in their access rules.
212 174
 
213 175
 Preventing Regressions
214 176
 ----------------------
@@ -216,76 +178,87 @@ Preventing Regressions
216 178
 If a Keystone API which supports this feature encounters a `keystonemiddleware`
217 179
 version (or 3rd party software authenticating against Keystone) that dates to
218 180
 before implementation of this feature there is potential for regression: while
219
-Keystone would provide the capability list upon token validation, the other
181
+Keystone would provide the access rule list upon token validation, the other
220 182
 side would simply ignore it - giving the requests all the permissions granted
221 183
 by the delegated roles. This can be prevented by treating application
222
-credentials with capabilities (i.e. a `capabilities` attribute that is not
184
+credentials with access rules (i.e. a `access_rules` attribute that is not
223 185
 `None`) as follows):
224 186
 
225 187
 1) When requesting token validation, `keystonemiddleware` (or any 3rd party
226
-   application that supports capability enforcement) sets an
227
-   `Openstack-Identity-Capabilities` header with a version string as its value.
228
-   Token validation for an application credential with a capability list will
188
+   application that supports access rule enforcement) sets an
189
+   `Openstack-Identity-Access-Rules` header with a version string as its value.
190
+   Token validation for an application credential with a access rule list will
229 191
    only succeed if this header is present. The version string will allow us to
230 192
    safely extend this feature by invalidating tokens using the extended version
231 193
    in situations where `keystonemiddleware` only supports an older version
232 194
    of this feature.
233 195
 
234
-2) If there is no `Openstack-Identity-Capabilities` header in the token
196
+2) If there is no `Openstack-Identity-Access-Rules` header in the token
235 197
    validation request, token validation fails.
236 198
 
237
-This way we ensure that nobody erroneously assumes capabilities are being
199
+This way we ensure that nobody erroneously assumes access rules are being
238 200
 enforced in environments where outdated `keystonemiddleware` (or its equivalent
239 201
 in 3rd party software) cannot enforce them because it is not aware of them. For
240
-any application credentials that do not have capabilities, validation proceeds
241
-as it would have before the introduction of capabilities (regardless of whether
242
-there is an `Openstack-Identity-Capabilities` or not).
202
+any application credentials that do not have access rules, validation proceeds
203
+as it would have before the introduction of access rules (regardless of whether
204
+there is an `Openstack-Identity-Access-Rules` or not).
205
+
206
+Discoverability for Access Rules Config
207
+---------------------------------------
208
+
209
+Any user with a valid auth token can list the operator maintained access rules
210
+through the Keystone API::
211
+
212
+    GET /v3/access_rules_config
243 213
 
244
-Discoverability for URL Path Templates
245
---------------------------------------
214
+.. code-block:: json
215
+
216
+   {
217
+       "compute": [
218
+           {
219
+               "path": "/v2.1/servers",
220
+               "method": "GET"
221
+           }
222
+       ]
223
+   }
246 224
 
247
-Any user with a valid auth token can list the operator maintained URL path
248
-templates through the Keystone API. This allows them to discover the URL path
249
-templates they can use for creating capability enabled application credentials.
225
+This allows them to discover the URL path templates they can use for creating
226
+access rules in application credentials.
250 227
 
251
-URL Templates and Roles
252
------------------------
228
+Access Rules and Roles
229
+----------------------
253 230
 
254
-URL path templates will have an optional ROLE_ID value. If this value is set,
255
-it indicates the role that the user needs to provide in the application
231
+Configured access rules will have an optional ROLE_ID value. If this value is
232
+set, it indicates the role that the user needs to provide in the application
256 233
 credential in order for the call to proceed. In addition, if the role_id value
257
-is set, the user will only be able to use the URL value in a capability if the
258
-user has that role assigned, either directly, or as a result of an implied
259
-role.
234
+is set, the user will only be able to use the access rule if the user has that
235
+role assigned, either directly, or as a result of an implied role.
260 236
 
261 237
 Chained API Calls
262 238
 -----------------
263 239
 
264
-One thing the capabilities make rather tough is chained API calls: if an API
265
-call is permitted by a capability, but the service uses the same capability
240
+One thing the access rules make rather tough is chained API calls: if an API
241
+call is permitted by an access rule, but the service uses the same access rule
266 242
 restricted token to call other services' APIs, these will fail. While it would
267
-be possible to circumvent this problem with additional capabilities to cover
243
+be possible to circumvent this problem with additional access rules to cover
268 244
 the chained calls, that would be very poor ergonomics, especially for
269 245
 operations with a large amount of chained API calls such as creating a Heat
270 246
 stack.
271 247
 
272
-To make it easier on users and services, the `allow_chained` attribute gives
273
-services blanket permission to perform chained API calls with the token
274
-resulting from the Application credential. This is implemented as follows:
248
+A future optimization of this feature will implement a toggle for access
249
+rules to give services blanket permission to perform chained API calls with the
250
+token resulting from the Application credential. This is implemented as follows:
275 251
 
276 252
 1) If `keystonemiddleware` receives a request that is permitted due to an
277
-   application credential with the `allow_chained` attribute set, it requests a
278
-   service token and adds it to the request's object's headers. Keystone only
279
-   allows setting this `allow_chained` attribute for an application credential
280
-   all capabilities' underlying URL templates have the `allow_chained`
281
-   attribute set to `True`.
253
+   application credential with this toggle set, it requests a service token and
254
+   adds it to the request's object's headers.
282 255
 
283 256
 2) Follow-up requests issued by the service will then send this service token
284 257
    along with the regular token resulting from the application credential.
285 258
 
286 259
 3) If `keystonemiddleware` encounters an application credential generated token
287
-   with `allow_chained` plus a valid service token it will ignore any
288
-   non-empty capability lists and pass the request to the service as-is.
260
+   with this toggle plus a valid service token it will ignore any
261
+   non-empty access rulelists and pass the request to the service as-is.
289 262
 
290 263
 API Examples
291 264
 ------------
@@ -301,107 +274,24 @@ follows:
301 274
 
302 275
     {
303 276
         "application_credential": {
304
-            "allow_chained": false,
305 277
             "name": "allow-metrics-logs",
306 278
             "description": "Allow submitting metrics and logs to Monasca",
307 279
             "roles": [
308 280
                 {"name": "monasca-agent"}
309 281
             ]
310
-            "capabilities": [
282
+            "access_rules": [
311 283
               {
312 284
                 "path": "/v2.0/metrics",
313
-                "substitutions": {},
314
-                "type": "POST",
315
-                "url_template": "376a83c4-c6e9-4cdf-b413-ba4880bfda4d"
285
+                "method": "POST"
316 286
               },
317 287
               {
318 288
                 "path": "/v3.0/logs",
319
-                "substitutions": {},
320
-                "type": "POST",
321
-                "url_template": "c73beef3-c982-4ed8-86d5-dd362af48614"
289
+                "method": "POST"
322 290
               }
323 291
             ]
324 292
         }
325 293
     }
326 294
 
327
-An example creation request (issued by an operator) for a URL template might
328
-look as follows:
329
-
330
-::
331
-
332
-    POST /v3/capability-templates
333
-
334
-.. code-block:: json
335
-
336
-    {
337
-        "capability_template": {
338
-            "allow_chained": true,
339
-            "role_id": "0dbbcb80-9d70-4c86-b38a-ae826e501885",
340
-            "path": "/v2.1/servers/**",
341
-            "substitutions": {},
342
-            "service": "67764758-3bdb-462e-babf-537c8fbe7bcd",
343
-            "type": "GET"
344
-        }
345
-    }
346
-
347
-Any user may discover the current list of URL through a
348
-
349
-::
350
-
351
-    GET /v3/capability-templates
352
-
353
-In response they will get a list of URL templates:
354
-
355
-.. code-block:: json
356
-
357
-    [
358
-        {
359
-          "capability_template": {
360
-              "id": "5631dd39-1451-4101-a961-bbc949624b2f",
361
-              "allow_chained": true,
362
-              "role_id": "0dbbcb80-9d70-4c86-b38a-ae826e501885",
363
-              "path": "/v2.1/servers/**",
364
-              "substitutions": {},
365
-              "service": "67764758-3bdb-462e-babf-537c8fbe7bcd",
366
-              "type": "GET"
367
-              }
368
-        },
369
-        {
370
-          "capability_template": {
371
-              "id": "cdfeecfb-752a-4370-9aaf-03751d3645b3",
372
-              "allow_chained": false,
373
-              "role_id": null,
374
-              "path": "/v2.1/servers/a13b634a-dde3-4e5d-bbcb-3c1482bcf6c8",
375
-              "substitutions": {},
376
-              "service": "67764758-3bdb-462e-babf-537c8fbe7bcd",
377
-              "type": "POST"
378
-              }
379
-        },
380
-        {
381
-          "capability_template": {
382
-              "id": "e86584c8-1a1a-4f5d-9da9-da5e265a0423",
383
-              "allow_chained": false,
384
-              "role_id": null,
385
-              "path": "/v2.0/metrics",
386
-              "substitutions": {},
387
-              "service": "1a5e983d-7ac2-4b27-a7a1-caa62a46d82a",
388
-              "type": "POST"
389
-              }
390
-        },
391
-        {
392
-          "capability_template": {
393
-              "id": "8458c208-6a91-4f54-af89-4598b972cd52",
394
-              "allow_chained": false,
395
-              "role_id": null,
396
-              "path": "/v3.0/logs",
397
-              "substitutions": {},
398
-              "service": "f6bd818d-861f-450b-a523-2e1546a06a18",
399
-              "type": "POST"
400
-              }
401
-        }
402
-    ]
403
-
404
-
405 295
 Alternatives
406 296
 ------------
407 297
 
@@ -427,11 +317,11 @@ Alternatives
427 317
    superficially similar role check in `keystonemiddleware`. There are several
428 318
    key differences, though:
429 319
 
430
-     (a) Application credential capabilities do not require a `Cambrian
320
+     (a) Application credential access rules do not require a `Cambrian
431 321
          explosion <https://en.wikipedia.org/wiki/Cambrian_explosion>`_ of
432 322
          fine-grained roles (one for every API operation of every OpenStack
433 323
          service) that must be managed by an administrator.
434
-     (b) Application credential capabilities does not require any changes to
324
+     (b) Application credential access rules does not require any changes to
435 325
          existing policy enforcement. Instead, they add an additional check
436 326
          that takes place before policy enforcement even comes into play and
437 327
          rejects requests early. Not being entangled with policy enforcement
@@ -441,25 +331,25 @@ Alternatives
441 331
      (c) The role check in `keystonemiddleware` targets administrators who want
442 332
          to create role profiles for their users, such as "give this user
443 333
          read-only access to any services' resources but without letting them
444
-         create new ones". Application credential capabilities on the other
334
+         create new ones". Application credential access rules on the other
445 335
          hand, target OpenStack services and third party applications that only
446 336
          need access to a select handful of operations such as "submit SSL
447 337
          certificates to the Magnum API for signing".
448
-     (d) Application credential capabilities do not require keystone to be the
338
+     (d) Application credential access rules do not require keystone to be the
449 339
          guardian of access control rules, since all the information needed to
450 340
          validate access is contained in the token.
451
-     (e) Unlike a policy based check, a capability based check will also work
341
+     (e) Unlike a policy based check, an access rule based check will also work
452 342
          for services that do not use `oslo.policy` such as Swift.
453 343
 
454 344
 3) One implementation detail from the previous section was discussed at length
455 345
    at the Rocky PTG: one could have chosen to match for `oslo.policy` targets
456
-   rather than URL paths in the capabilities, which would have been easier in
346
+   rather than URL paths in the access rules, which would have been easier in
457 347
    some ways. In the end we opted for url paths for the following reasons:
458 348
 
459 349
      (a) This is user facing and unlike API paths, policy targets are not
460 350
          easily discoverable by the user since there is no documentation on
461 351
          them. Moreover, policy targets are not as formalized as APIs and may
462
-         easily change over time, thus breaking existing capabilities.
352
+         easily change over time, thus breaking existing access rules.
463 353
 
464 354
      (b) URL paths can be rejected in keystonemiddleware, without involving
465 355
          `oslo.policy`, leading to a faster failure for unauthorized requests.
@@ -479,16 +369,16 @@ have various security critical aspects:
479 369
 * This change adds additional information to the token data retrieved by
480 370
   keystonemiddleware upon token validation.
481 371
 
482
-* URLs in capabilities are user-supplied strings. Care must be taken to
372
+* URLs in access rules are user-supplied strings. Care must be taken to
483 373
   guard against format string attacks in these if anything beyond character by
484 374
   character comparison takes place.
485 375
 
486
-* It might be a good idea to limit the length/number of capability rules per
376
+* It might be a good idea to limit the length/number of access rules per
487 377
   API credential to prevent denial of service against the Keystone database (by
488 378
   filling it with bogus rules) or the Keystone API (via large validation
489 379
   payloads). Another reason to introduce such a limit is the possibility to
490 380
   slow down a service by creating application credentials with a large number
491
-  of non-matching capabilities, which can be used to slow down a particular
381
+  of non-matching access rules, which can be used to slow down a particular
492 382
   service.
493 383
 
494 384
 * This change is unlikely to allow privilege escalation since it only adds
@@ -517,24 +407,9 @@ with the application credential.
517 407
 That small amount of data may not be so small during the token validation,
518 408
 though, resulting in multiple/more packets being sent in response to a
519 409
 validation request, causing congestion and/or increasing latency. This can be
520
-mitigated by limiting the number of capabilities allowed per application
410
+mitigated by limiting the number of access rules allowed per application
521 411
 credential.
522 412
 
523
-Other Deployer Impact
524
----------------------
525
-
526
-This change will introduce the following settings for Keystone:
527
-
528
-* `[application_credential]/soft_capability_quota` [Default: `5`] This setting
529
-  determines the number of entries allowed in newly created capability lists
530
-  globally. `-1` denotes an unlimited number of entries. Any existing
531
-  application credentials with more capabilities will continue to work.
532
-
533
-* `[application_credential]/hard_capability_quota` [Default: `-1`] This setting
534
-  determines the number of entries allowed in capability lists globally.  `-1`
535
-  denotes an unlimited number of entries. Any existing application credentials
536
-  with more capabilities will fail token validation.
537
-
538 413
 Developer Impact
539 414
 ----------------
540 415
 
@@ -544,9 +419,9 @@ delegate access to a user's roles according to the principle of least
544 419
 privilege.
545 420
 
546 421
 As far as the application credentials API is concerned, it will be fully
547
-backwards compatible, since specifying capabilities when creating an
548
-application credential is optional: if none are specified, the `capabilities`
549
-attribute will be `None`, leading to no capability checks being performed.
422
+backwards compatible, since specifying access rules when creating an
423
+application credential is optional: if none are specified, the `access_rules`
424
+attribute will be `None`, leading to no access rule checks being performed.
550 425
 
551 426
 Implementation
552 427
 ==============
@@ -556,24 +431,24 @@ Assignee(s)
556 431
 
557 432
 Primary assignee:
558 433
 
559
-  * Johannes Grassler <jgr-launchpad@btw23.de> jgr-launchpad
434
+  * Colleen Murphy <colleen@gazlene.net> cmurphy
560 435
 
561 436
 Other contributors:
562 437
 
563
-  * Colleen Murphy <colleen@gazlene.net> cmurphy
564
-
565 438
   * Adam Young <ayoung@redhat.com> ayoung
566 439
 
440
+  * Johannes Grassler <jgr-launchpad@btw23.de> jgr-launchpad
441
+
567 442
 Work Items
568 443
 ----------
569 444
 
570 445
 1. Extend the application credential API and database schema in Keystone to
571
-   allow for receiving and storing capability lists.
446
+   allow for receiving and storing access rule lists.
572 447
 
573
-2. Implement handling for capabilities in python-keystoneclient and
448
+2. Implement handling for access rules in python-keystoneclient and
574 449
    python-openstackclient.
575 450
 
576
-3. Extend the Keystone token validation API to capability lists upon
451
+3. Extend the Keystone token validation API to access rule lists upon
577 452
    upon token validation.
578 453
 
579 454
 4. Implement the endpoint list check in keystonemiddleware.
@@ -586,13 +461,10 @@ None
586 461
 Documentation Impact
587 462
 ====================
588 463
 
589
-* The capability related settings for application credentials need to be
464
+* The access rule related settings for application credentials need to be
590 465
   documented in the release notes and the admin guide.
591 466
 
592
-* The URL template "language" outlined in the `Permissible Path Templates`_
593
-  section needs to be documented in the Keystone admin guide.
594
-
595
-* Documentation on capabilities needs to be added to the *Application
467
+* Documentation on access rules needs to be added to the *Application
596 468
   Credentials* section of the Keystone user documentation.
597 469
 
598 470
 References
@@ -606,7 +478,7 @@ References
606 478
 
607 479
 * Spec for securing Monasca metric submission from inside VMs
608 480
   https://review.openstack.org/#/c/507110/ (would be greatly simplified by
609
-  having capabilities in application credentials)
481
+  having access rules in application credentials)
610 482
 
611 483
 * Documentation on Barbican ACLs:
612 484
   http://developer.openstack.org/api-guide/key-manager/acls.html
@@ -616,3 +488,9 @@ References
616 488
 
617 489
 * Generating a list of URL patterns for OpenStack services
618 490
   http://adam.younglogic.com/2018/03/generating-url-patterns/
491
+
492
+* Related concept for Istio:
493
+  https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1/#AccessRule
494
+
495
+* Updated design discussion:
496
+  http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003031.html

Loading…
Cancel
Save