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
|
.. _orchestration-auth-model:
=================================
Orchestration authorization model
=================================
The Orchestration authorization model defines the
authorization process for requests during deferred operations.
A common example is an auto-scaling group update. During
the auto-scaling update operation, the Orchestration service
requests resources of other components (such as servers from
Compute or networks from Networking) to extend or reduce the
capacity of an auto-scaling group.
The Orchestration service provides the following authorization models:
* Password authorization
* OpenStack Identity trusts authorization
Password authorization
~~~~~~~~~~~~~~~~~~~~~~
The Orchestration service supports password authorization.
Password authorization requires that a user pass a
username and password to the Orchestration service. Encrypted
password are stored in the database, and used for deferred
operations.
Password authorization involves the following steps:
#. A user requests stack creation, by providing a token and
username and password. The Dashboard or
python-heatclient requests the token on the user's behalf.
#. If the stack contains any resources that require deferred
operations, then the orchestration engine fails its validation
checks if the user did not provide a valid username/password.
#. The username/password are encrypted and stored in the Orchestration
database.
#. Orchestration creates a stack.
#. Later, the Orchestration service retrieves the credentials and
requests another token on behalf of the user. The token is not
limited in scope and provides access to all the roles of the stack
owner.
OpenStack Identity trusts authorization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A trust is an OpenStack Identity extension that enables delegation,
and optionally impersonation through the OpenStack Identity service.
The key terminology is *trustor* (the user delegating) and
*trustee* (the user being delegated to).
To create a trust, the *trustor* (in this case, the user creating the
stack in the Orchestration service) provides the OpenStack Identity service
with the following information:
* The ID of the *trustee* (who you want to delegate to, in this case,
the Orchestration service user).
* The roles to be delegated. Configure roles through
the ``heat.conf`` file. Ensure the configuration contains whatever
roles are required to perform the deferred operations on the
user's behalf. For example, launching an OpenStack Compute
instance in response to an auto-scaling event.
* Whether to enable impersonation.
The OpenStack Identity service provides a *trust ID*,
which is consumed by *only* the trustee to obtain a
*trust scoped token*. This token is limited in scope,
such that the trustee has limited access to those
roles delegated. In addition, the trustee has effective impersonation
of the trustor user if it was selected when creating the trust.
For more information, see :keystone-doc:`Identity management trusts
<user/trusts.html>`.
Trusts authorization involves the following steps:
#. A user creates a stack through an API request (only the token is
required).
#. The Orchestration service uses the token to create a trust
between the stack owner (trustor) and the Orchestration
service user (trustee). The service delegates a special role (or roles)
as defined in the *trusts_delegated_roles* list in the
Orchestration configuration file. By default, the Orchestration
service sets all the roles from trustor available for trustee.
Deployers might modify this list to reflect a local RBAC policy.
For example, to ensure that the heat process can access only
those services that are expected while impersonating a stack owner.
#. Orchestration stores the encrypted *trust ID* in the Orchestration
database.
#. When a deferred operation is required, the Orchestration service
retrieves the *trust ID* and requests a trust scoped token which
enables the service user to impersonate the stack owner during
the deferred operation. Impersonation is helpful, for example,
so the service user can launch Compute instances on
behalf of the stack owner in response to an auto-scaling event.
Authorization model configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Initially, the password authorization model was the
default authorization model. Since the Kilo release, the
Identity trusts authorization model is enabled for the Orchestration
service by default.
To enable the password authorization model, change the following
parameter in the ``heat.conf`` file:
.. code-block:: ini
deferred_auth_method=password
To enable the trusts authorization model, change the following
two parameters in the ``heat.conf`` file.
Specify the authentication method for the deferred Orchestration actions.
This parameter triggers creating *trust ID* and stores it
in the Orchestration database:
.. code-block:: ini
deferred_auth_method=trusts
Allow reauthentication with the trust scoped token issued
by using the stored *trust ID* for long running tasks:
.. code-block:: ini
reauthentication_auth_method=trusts
To specify the trustor roles that it delegates to trustee during
authorization, specify the ``trusts_delegated_roles`` parameter
in the ``heat.conf`` file. If ``trusts_delegated_roles`` is not
defined, then all the trustor roles are delegated to trustee.
.. note::
The trustor delegated roles must be pre-configured in the
OpenStack Identity service before using them in the Orchestration service.
|
