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
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
|
..
Copyright 2018 SUSE Linux GmbH
All Rights Reserved.
Licensed under the Apache License, Version 2.0 (the "License"); you may
not use this file except in compliance with the License. You may obtain
a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
License for the specific language governing permissions and limitations
under the License.
.. _application_credentials:
=======================
Application Credentials
=======================
Users can create application credentials to allow their applications to
authenticate to keystone. Users can delegate a subset of their role assignments
on a project to an application credential, granting the application the same or
restricted authorization to a project. With application credentials,
applications authenticate with the application credential ID and a secret string
which is not the user's password. This way, the user's password is not embedded
in the application's configuration, which is especially important for users
whose identities are managed by an external system such as LDAP or a
single-signon system.
See the `Identity API reference`_ for more information on authenticating with
and managing application credentials.
.. _`Identity API reference`: https://docs.openstack.org/api-ref/identity/v3/index.html#application-credentials
Managing Application Credentials
================================
Create an application credential using python-openstackclient:
.. code-block:: console
$ openstack application credential create monitoring
+--------------+----------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------+
| description | None |
| expires_at | None |
| id | 26bb287fd56a41f8a577c47f79221187 |
| name | monitoring |
| project_id | e99b6f4b9bf84a9da27e20c9cbfe887a |
| roles | Member anotherrole |
| secret | PJXxBFGPOLwdl3PA6tSivJT9S4RpWhLcNZH2gXzCoxX1C2cnZsj2_Xmfw-LE7Wc-NwuJEYoHcG0gQ5bjWwe-bg |
| unrestricted | False |
+--------------+----------------------------------------------------------------------------------------+
The only required parameter is a name. The application credential is created for
the project to which the user is currently scoped with the same role assignments
the user has on that project. Keystone will automatically generate a secret
string that will be revealed once at creation time. You can also provide your
own secret, if desired:
.. code-block:: console
$ openstack application credential create monitoring --secret securesecret
+--------------+----------------------------------+
| Field | Value |
+--------------+----------------------------------+
| description | None |
| expires_at | None |
| id | bc257241e21747768c83fb9806af392d |
| name | monitoring |
| project_id | e99b6f4b9bf84a9da27e20c9cbfe887a |
| roles | Member anotherrole |
| secret | securesecret |
| unrestricted | False |
+--------------+----------------------------------+
The secret is hashed before it is stored, so the original secret is not
retrievable after creation. If the secret is lost, a new application credential
must be created.
If none are provided, the application credential is created with the same role
assignments on the project that the user has. You can find out what role
assignments you have on a project by examining your token or your keystoneauth
session:
.. code-block:: python
>>> mysession.auth.auth_ref.role_names
[u'anotherrole', u'Member']
If you have more than one role assignment on a project, you can grant your
application credential only a subset of your role assignments if desired. This
is useful if you have administrator privileges on a project but only want the
application to have basic membership privileges, or if you have basic membership
privileges but want the application to only have read-only privileges. You
cannot grant the application a role assignment that your user does not already
have; for instance, if you are an admin on a project, and you want your
application to have read-only access to the project, you must acquire a
read-only role assignment on that project yourself before you can delegate it to
the application credential. Removing a user's role assignment on a project will
invalidate the user's application credentials for that project.
.. code-block:: console
$ openstack application credential create monitoring --role Member
+--------------+----------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------+
| description | None |
| expires_at | None |
| id | 5d04e42491a54e83b313aa2625709411 |
| name | monitoring |
| project_id | e99b6f4b9bf84a9da27e20c9cbfe887a |
| roles | Member |
| secret | vALEOMENxB_QaKFZOA2XOd7stwrhTlqPKrOdrXXM5BORss9u3O6GT-w_HYCPaZbtg96sDPCdtzVARZLpgUOY_g |
| unrestricted | False |
+--------------+----------------------------------------------------------------------------------------+
An alternative way to limit the application credential's privileges is to use
:ref:`access_rules`.
You can provide an expiration date for application credentials:
.. code-block:: console
$ openstack application credential create monitoring --expiration '2019-02-12T20:52:43'
+--------------+----------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------+
| description | None |
| expires_at | 2019-02-12T20:52:43.000000 |
| id | 4ea8c4a84f7b4c65a3d84460be9cd1f7 |
| name | monitoring |
| project_id | e99b6f4b9bf84a9da27e20c9cbfe887a |
| roles | Member anotherrole |
| secret | _My16dlySn6jr7pGvBxjcMrmPA0MCpYlkKWs3gpY3-Ybk05yt2Hh83uMdTLPWlFeh8lOXajIAVHrQaBQ06iz5Q |
| unrestricted | False |
+--------------+----------------------------------------------------------------------------------------+
By default, application credentials are restricted from creating or deleting
other application credentials and from creating or deleting trusts. If your
application needs to be able to perform these actions and you accept the risks
involved, you can disable this protection:
.. warning::
Restrictions on these Identity operations are deliberately imposed as a
safeguard to prevent a compromised application credential from regenerating
itself. Disabling this restriction poses an inherent added risk.
.. code-block:: console
$ openstack application credential create monitoring --unrestricted
+--------------+----------------------------------------------------------------------------------------+
| Field | Value |
+--------------+----------------------------------------------------------------------------------------+
| description | None |
| expires_at | None |
| id | 0a0372dbedfb4e82ab66449c3316ef1e |
| name | monitoring |
| project_id | e99b6f4b9bf84a9da27e20c9cbfe887a |
| roles | Member anotherrole |
| secret | ArOy6DYcLeLTRlTmfvF1TH1QmRzYbmD91cbVPOHL3ckyRaLXlaq5pTGJqvCvqg6leEvTI1SQeX3QK-3iwmdPxg |
| unrestricted | True |
+--------------+----------------------------------------------------------------------------------------+
.. _access_rules:
Access Rules
============
In addition to delegating a subset of roles to an application credential, you
may also delegate more fine-grained access control by using access rules.
.. note::
Application credentials with access rules require additional configuration
of each service that will use it. See below for details.
If application credentials with access rules are required, an OpenStack
service using keystonemiddleware to authenticate with keystone, needs to
define ``service_type`` in its configuration file. Following is an example for the
cinder V3 service:
.. code-block:: ini
[keystone_authtoken]
service_type = volumev3
For other OpenStack sevices, their types can be obtained using the OpenStack
client. For example:
.. code-block:: console
$ openstack service list -c Name -c Type
+-----------+-----------+
| Name | Type |
+-----------+-----------+
| glance | image |
| cinderv3 | volumev3 |
| cinderv2 | volumev2 |
| keystone | identity |
| nova | compute |
| neutron | network |
| placement | placement |
+-----------+-----------+
.. note::
Updates to the configuration files of a service require restart of the appropriate
services for the changes to take effect.
In order to create an example application credential that is constricted to creating
servers in nova, the user can add the following access rules:
.. code-block:: console
openstack application credential create scaler-upper --access-rules '[
{
"path": "/v2.1/servers",
"method": "POST",
"service": "compute"
}
]'
The ``"path"`` attribute of application credential access rules uses a wildcard
syntax to make it more flexible. For example, to create an application
credential that is constricted to listing server IP addresses, you could use
either of the following access rules:
::
[
{
"path": "/v2.1/servers/*/ips",
"method": "GET",
"service": "compute"
}
]
or equivalently:
::
[
{
"path": "/v2.1/servers/{server_id}/ips",
"method": "GET",
"service": "compute"
}
]
In both cases, a request path containing any server ID will match the access
rule. For even more flexibility, the recursive wildcard ``**`` indicates that
request paths containing any number of ``/`` will be matched. For example:
::
[
{
"path": "/v2.1/**",
"method": "GET",
"service": "compute"
}
]
will match any nova API for version 2.1.
An access rule created for one application credential can be re-used by
providing its ID to another application credential. You can list existing access
rules:
.. code-block:: console
$ openstack access rule list
+--------+---------+--------+---------------+
| ID | Service | Method | Path |
+--------+---------+--------+---------------+
| abcdef | compute | POST | /v2.1/servers |
+--------+---------+--------+---------------+
and create an application credential using that rule:
.. code-block:: console
$ openstack application credential create scaler-upper-02 \
--access-rules '[{"id": "abcdef"}]'
Using Application Credentials
=============================
Applications can authenticate using the application_credential auth method. For
a service using keystonemiddleware to authenticate with keystone, the
auth section would look like this:
.. code-block:: ini
[keystone_authtoken]
auth_url = https://keystone.server/identity/v3
auth_type = v3applicationcredential
application_credential_id = 6cb5fa6a13184e6fab65ba2108adf50c
application_credential_secret= glance_secret
You can also identify your application credential with its name and the name or
ID of its owner. For example:
.. code-block:: ini
[keystone_authtoken]
auth_url = https://keystone.server/identity/v3
auth_type = v3applicationcredential
username = glance
user_domain_name = Default
application_credential_name = glance_cred
application_credential_secret = glance_secret
Rotating Application Credentials
================================
A user can create multiple application credentials with the same role
assignments on the same project. This allows the application credential to be
gracefully rotated with minimal or no downtime for your application. In
contrast, changing a service user's password results in immediate downtime for
any application using that password until the application can be updated with
the new password.
.. note::
Rotating application credentials is essential if a team member who has
knowledge of the application credential identifier and secret leaves the team
for any reason. Rotating application credentials is also recommended as part
of regular application maintenance.
Rotating an application credential is a simple process:
#. Create a new application credential. Application credential names must be
unique within the user's set of application credentials, so this new
application credential must not have the same name as the old one.
#. Update your application's configuration to use the new ID (or name and user
identifier) and the new secret. For a distributed application, this can be
done one node at a time.
#. When your application is fully set up with the new application credential,
delete the old one.
Frequently Asked Questions
==========================
Why is the application credential owned by the user rather than the project?
----------------------------------------------------------------------------
Having application credentials be owned by a project rather than by an
individual user would be convenient for cases where teams want applications to
continue running after the creating user has left the team. However, this would
open up a security hole by which the creating user could still gain access to
the resources accessible by the application credential even after the user is
disabled. Rather than relying on the application credential persisting after
users are disabled, it is recommended to proactively rotate the application
credential to another user prior to the original creating user being disabled.
|
