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
// 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.
//
// SPDX-License-Identifier: Apache-2.0
//! Identity User Access Credentials commands
use ;
use AsyncOpenStack;
use crate::;
/// Application Credentials
///
/// Application credentials provide a way to delegate a user’s authorization to an application
/// without sharing the user’s password authentication. This is a useful security measure,
/// especially for situations where the user’s identification is provided by an external source,
/// such as LDAP or a single-sign-on service. Instead of storing user passwords in config files, a
/// user creates an application credential for a specific project, with all or a subset of the role
/// assignments they have on that project, and then stores the application credential identifier
/// and secret in the config file.
///
/// Multiple application credentials may be active at once, so you can easily rotate application
/// credentials by creating a second one, converting your applications to use it one by one, and
/// finally deleting the first one.
///
/// Application credentials are limited by the lifespan of the user that created them. If the user
/// is deleted, disabled, or loses a role assignment on a project, the application credential is
/// deleted.
///
/// Application credentials can have their privileges limited in two ways. First, the owner may
/// specify a subset of their own roles that the application credential may assume when getting a
/// token for a project. For example, if a user has the member role on a project, they also have
/// the implied role reader and can grant the application credential only the reader role for the
/// project:
///
/// ```json
///
/// "roles": [ {"name": "reader"} ]
///
/// ```
///
/// Users also have the option of delegating more fine-grained access control to their application
/// credentials by using access rules. For example, to create an application credential that is
/// constricted to creating servers in nova, the user can add the following access rules:
///
/// ```json
///
/// "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:
///
/// ```json
///
/// "access_rules": [ { "path": "/v2.1/servers/*/ips", "method": "GET", "service": "compute" } ]
///
/// ```
///
/// or equivalently:
///
/// ```json
///
/// "access_rules": [ { "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:
///
/// ```json
///
/// "access_rules": [ { "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, for example:
///
/// ```json
///
/// "access_rules": [ { "id": "abcdef" } ]
///
/// ```
/// Supported subcommands