Browse Source

Add capabilities to application credentials

This spec describes a capability list extension for
application credentials that allows their creator to restrict
their usage to a white list of capabilities, each of which
consists of HTTP methods and permitted URL paths. Any request
using the application credential must match an entry in this
list. All other requests are rejected.

Change-Id: Iffc853971e909bd3ca8829b410a7014929c8b7e6
Johannes Grassler 2 years ago
parent
commit
dfeb67c789
1 changed files with 618 additions and 0 deletions
  1. 618
    0
      specs/keystone/rocky/capabilities-app-creds.rst

+ 618
- 0
specs/keystone/rocky/capabilities-app-creds.rst View File

@@ -0,0 +1,618 @@
1
+..
2
+ This work is licensed under a Creative Commons Attribution 3.0 Unported
3
+ License.
4
+
5
+ http://creativecommons.org/licenses/by/3.0/legalcode
6
+
7
+========================================================
8
+Add Fine Grained Restrictions to Application Credentials
9
+========================================================
10
+
11
+`bp <https://blueprints.launchpad.net/keystone/+spec/whitelist-extension-for-app-creds>`_
12
+
13
+Currently Keystone application credentials are mostly unrestricted.
14
+Restrictions can only be imposed on creation of follow-up application
15
+credentials and trusts. Other than that they allow unfettered use of the roles
16
+being delegated in the project the application credential is created for. This
17
+renders application credentials questionable anywhere a least-privilege
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
20
+services would then enforce. This spec outlines an approach for storing and
21
+handling such restrictions.
22
+
23
+Problem Description
24
+===================
25
+
26
+This section uses the predecessor of application credentials, Keystone trusts,
27
+to outline a few example where unrestricted role delegation is a problem. The
28
+same problem applies to application credentials since both delegate a subset of
29
+users' roles. Only the authentication method is different (a secret for
30
+application credentials, a trustee user's username/password for trusts).
31
+
32
+Keystone trusts, have been around for quite a while now (they were introduced
33
+in the Grizzly release). Right now, trusts are used by the following projects
34
+among others (list may not be complete):
35
+
36
+* Heat: operations on behalf of the user at times when a token may have expired
37
+        already.
38
+* 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)
42
+
43
+Other projects (neutron-lbaas, Barbican) hesitate to employ trusts and
44
+application credentials since they are an all-or-nothing approach: they grant
45
+full access to all OpenStack APIs in the scope (roles in a project) they are
46
+created for. In order to provide least-privilege access, these services
47
+implement ACLs of their own (Barbican, Swift) or rely on other services' ACLs
48
+to grant limited access to resources (neutron-lbaas uses Barbican's ACLs to
49
+grant its service user access to secret containers holding SSL keys). Monasca
50
+suffers from slightly different problems: it uses Keystone to authenticate
51
+metric submission which requires Keystone credentials or an application
52
+credential. This can potentially be abused for out-of-band access to other
53
+OpenStack APIs from inside any VMs running a Monasca agent.
54
+
55
+In summary, there is a real need for fine-grained delegation of access. The
56
+implementation of Keystone application credentials as it exists right now
57
+cannot serve this need, though: an application credential can only be used to
58
+grant full access within the application credential's project/roles scope, but
59
+it cannot be used to give access limited to just one particular resource or
60
+access that only allows the creation of specific new resources, but not the
61
+modification/deletion of existing resources.
62
+
63
+With fine-grained restrictions in place, application credentials can be used to
64
+safely grant the least privilege required in the scenarios described above.
65
+This is not possible with the current role based access control solution some
66
+services use, where a special-purpose role such as Heat`s `heat_stack_user`
67
+role is merely explicitly blacklisted for all operations other than the
68
+specific one it is intended for. For this blacklisting usually only extends to
69
+the service owning this particular role and putting these restrictions in place
70
+(other services usually do not know this role is supposed to have blacklist
71
+entries for any and all of _their_ operations and thus allow unrestricted
72
+access).
73
+
74
+Proposed Change
75
+===============
76
+
77
+The approach to implementing fine-grained permissions for application
78
+credentials is two-pronged. Permission data is stored in Keystone and enforced
79
+by keystonemiddleware as follows:
80
+
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
167
+   this pattern and may not be preceded or followed by extra characters. The
168
+   template string may contain the following special wildcard templates:
169
+
170
+   * `{*}`: allows arbitrary strings (excluding the `/` character) in
171
+            capability enforcement.
172
+   * `{**}`: allows arbitrary strings (including the `/` character) in
173
+             capability enforcement.
174
+
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
+-------------------
201
+
202
+`keystonemiddleware` receives the capability list information upon token
203
+validation. It then processes each capability as follows:
204
+
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.
212
+
213
+Preventing Regressions
214
+----------------------
215
+
216
+If a Keystone API which supports this feature encounters a `keystonemiddleware`
217
+version (or 3rd party software authenticating against Keystone) that dates to
218
+before implementation of this feature there is potential for regression: while
219
+Keystone would provide the capability list upon token validation, the other
220
+side would simply ignore it - giving the requests all the permissions granted
221
+by the delegated roles. This can be prevented by treating application
222
+credentials with capabilities (i.e. a `capabilities` attribute that is not
223
+`None`) as follows):
224
+
225
+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
229
+   only succeed if this header is present. The version string will allow us to
230
+   safely extend this feature by invalidating tokens using the extended version
231
+   in situations where `keystonemiddleware` only supports an older version
232
+   of this feature.
233
+
234
+2) If there is no `Openstack-Identity-Capabilities` header in the token
235
+   validation request, token validation fails.
236
+
237
+This way we ensure that nobody erroneously assumes capabilities are being
238
+enforced in environments where outdated `keystonemiddleware` (or its equivalent
239
+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).
243
+
244
+Discoverability for URL Path Templates
245
+--------------------------------------
246
+
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.
250
+
251
+URL Templates and Roles
252
+-----------------------
253
+
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
256
+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.
260
+
261
+Chained API Calls
262
+-----------------
263
+
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
266
+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
268
+the chained calls, that would be very poor ergonomics, especially for
269
+operations with a large amount of chained API calls such as creating a Heat
270
+stack.
271
+
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:
275
+
276
+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`.
282
+
283
+2) Follow-up requests issued by the service will then send this service token
284
+   along with the regular token resulting from the application credential.
285
+
286
+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.
289
+
290
+API Examples
291
+------------
292
+
293
+An example creation request for an application credential might look as
294
+follows:
295
+
296
+::
297
+
298
+    POST /v3/users/{user_id}/application_credentials
299
+
300
+.. code-block:: json
301
+
302
+    {
303
+        "application_credential": {
304
+            "allow_chained": false,
305
+            "name": "allow-metrics-logs",
306
+            "description": "Allow submitting metrics and logs to Monasca",
307
+            "roles": [
308
+                {"name": "monasca-agent"}
309
+            ]
310
+            "capabilities": [
311
+              {
312
+                "path": "/v2.0/metrics",
313
+                "substitutions": {},
314
+                "type": "POST",
315
+                "url_template": "376a83c4-c6e9-4cdf-b413-ba4880bfda4d"
316
+              },
317
+              {
318
+                "path": "/v3.0/logs",
319
+                "substitutions": {},
320
+                "type": "POST",
321
+                "url_template": "c73beef3-c982-4ed8-86d5-dd362af48614"
322
+              }
323
+            ]
324
+        }
325
+    }
326
+
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
+Alternatives
406
+------------
407
+
408
+1) One alternative to this exists already: internal ACL implementations by
409
+   various OpenStack services. This situation is undesirable for several
410
+   reasons, some of which are:
411
+
412
+     (a) Auditability: authorization information is stored in multiple
413
+                       locations, all of which need to be checked to find out
414
+                       who is authorized to perform what operation. From an
415
+                       auditability perspective it would be preferable to have
416
+                       a central source of truth.
417
+
418
+     (b) Maintenance: when there are multiple independent implementations a lot
419
+                      of code is duplicated and bugs may be duplicated as well
420
+                      as new projects implement their own ACL system.
421
+
422
+     (c) Consistency: with multiple sources of truth, an individual service's
423
+                      ACLs may well end up overriding a cloud-wide policy
424
+                      permitting or denying an operation.
425
+
426
+2) `391624 <https://review.openstack.org/#/c/391624/>`_ proposes a
427
+   superficially similar role check in `keystonemiddleware`. There are several
428
+   key differences, though:
429
+
430
+     (a) Application credential capabilities do not require a `Cambrian
431
+         explosion <https://en.wikipedia.org/wiki/Cambrian_explosion>`_ of
432
+         fine-grained roles (one for every API operation of every OpenStack
433
+         service) that must be managed by an administrator.
434
+     (b) Application credential capabilities does not require any changes to
435
+         existing policy enforcement. Instead, they add an additional check
436
+         that takes place before policy enforcement even comes into play and
437
+         rejects requests early. Not being entangled with policy enforcement
438
+         gives us the freedom to start out with a very basic implementation and
439
+         add features as required later (as opposed to having to be feature
440
+         complete immediately).
441
+     (c) The role check in `keystonemiddleware` targets administrators who want
442
+         to create role profiles for their users, such as "give this user
443
+         read-only access to any services' resources but without letting them
444
+         create new ones". Application credential capabilities on the other
445
+         hand, target OpenStack services and third party applications that only
446
+         need access to a select handful of operations such as "submit SSL
447
+         certificates to the Magnum API for signing".
448
+     (d) Application credential capabilities do not require keystone to be the
449
+         guardian of access control rules, since all the information needed to
450
+         validate access is contained in the token.
451
+     (e) Unlike a policy based check, a capability based check will also work
452
+         for services that do not use `oslo.policy` such as Swift.
453
+
454
+3) One implementation detail from the previous section was discussed at length
455
+   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
457
+   some ways. In the end we opted for url paths for the following reasons:
458
+
459
+     (a) This is user facing and unlike API paths, policy targets are not
460
+         easily discoverable by the user since there is no documentation on
461
+         them. Moreover, policy targets are not as formalized as APIs and may
462
+         easily change over time, thus breaking existing capabilities.
463
+
464
+     (b) URL paths can be rejected in keystonemiddleware, without involving
465
+         `oslo.policy`, leading to a faster failure for unauthorized requests.
466
+
467
+Limitations
468
+-----------
469
+
470
+This proposal does not restrict the body of requests in any sort of way.
471
+
472
+Security Impact
473
+---------------
474
+
475
+This change tightens security by providing a means to restrict the permissions
476
+granted by application credentials. That being said, its implementation does
477
+have various security critical aspects:
478
+
479
+* This change adds additional information to the token data retrieved by
480
+  keystonemiddleware upon token validation.
481
+
482
+* URLs in capabilities are user-supplied strings. Care must be taken to
483
+  guard against format string attacks in these if anything beyond character by
484
+  character comparison takes place.
485
+
486
+* It might be a good idea to limit the length/number of capability rules per
487
+  API credential to prevent denial of service against the Keystone database (by
488
+  filling it with bogus rules) or the Keystone API (via large validation
489
+  payloads). Another reason to introduce such a limit is the possibility to
490
+  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
492
+  service.
493
+
494
+* This change is unlikely to allow privilege escalation since it only adds
495
+  additional failing criteria to token validation and policy enforcement. These
496
+  failing criteria need to be carefully tested for false positives, though.
497
+
498
+Notifications Impact
499
+--------------------
500
+
501
+No new notifications will be added from this API.
502
+
503
+Other End User Impact
504
+---------------------
505
+
506
+Since this changes adds extra information to application credentials, both
507
+python-keystoneclient and python-openstackclient need to be extended to handle
508
+that extra information.
509
+
510
+Performance Impact
511
+------------------
512
+
513
+The performance impact upon application credential creation is probably
514
+neglible, since all that happens is that a small amount of data is stored along
515
+with the application credential.
516
+
517
+That small amount of data may not be so small during the token validation,
518
+though, resulting in multiple/more packets being sent in response to a
519
+validation request, causing congestion and/or increasing latency. This can be
520
+mitigated by limiting the number of capabilities allowed per application
521
+credential.
522
+
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
+Developer Impact
539
+----------------
540
+
541
+This change provides developers across all OpenStack services with a means to
542
+create application credentials with fine-grained permissions, allowing them to
543
+delegate access to a user's roles according to the principle of least
544
+privilege.
545
+
546
+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.
550
+
551
+Implementation
552
+==============
553
+
554
+Assignee(s)
555
+-----------
556
+
557
+Primary assignee:
558
+
559
+  * Johannes Grassler <jgr-launchpad@btw23.de> jgr-launchpad
560
+
561
+Other contributors:
562
+
563
+  * Colleen Murphy <colleen@gazlene.net> cmurphy
564
+
565
+  * Adam Young <ayoung@redhat.com> ayoung
566
+
567
+Work Items
568
+----------
569
+
570
+1. Extend the application credential API and database schema in Keystone to
571
+   allow for receiving and storing capability lists.
572
+
573
+2. Implement handling for capabilities in python-keystoneclient and
574
+   python-openstackclient.
575
+
576
+3. Extend the Keystone token validation API to capability lists upon
577
+   upon token validation.
578
+
579
+4. Implement the endpoint list check in keystonemiddleware.
580
+
581
+Dependencies
582
+============
583
+
584
+None
585
+
586
+Documentation Impact
587
+====================
588
+
589
+* The capability related settings for application credentials need to be
590
+  documented in the release notes and the admin guide.
591
+
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
596
+  Credentials* section of the Keystone user documentation.
597
+
598
+References
599
+==========
600
+
601
+* Etherpad with original proposal from the Barcelona 2016 summit:
602
+  https://etherpad.openstack.org/p/ocata-keystone-authorization
603
+
604
+* Etherpad with refined proposal from the Rocky PTG 2018:
605
+  https://etherpad.openstack.org/p/application-credentials-rocky-ptg
606
+
607
+* Spec for securing Monasca metric submission from inside VMs
608
+  https://review.openstack.org/#/c/507110/ (would be greatly simplified by
609
+  having capabilities in application credentials)
610
+
611
+* Documentation on Barbican ACLs:
612
+  http://developer.openstack.org/api-guide/key-manager/acls.html
613
+
614
+* Documentation on Swift ACLs:
615
+  https://www.swiftstack.com/docs/cookbooks/swift_usage/container_acl.html
616
+
617
+* Generating a list of URL patterns for OpenStack services
618
+  http://adam.younglogic.com/2018/03/generating-url-patterns/

Loading…
Cancel
Save