openstack/openstack-manuals
Code Issues Proposed changes

[Admin-guide-cloud] Sentence level edit for Orchestration

Browse Source 
Improved grammar by adding articles, subj/verb agreement
consistency for the Orchestration authorization model page.

Change-Id: I7b032768dc87762b43fe4f713699645f86cc1124
Implements: blueprint user-guides-reorganised
This commit is contained in:
Linette
2015-10-26 11:13:11 -05:00
parent 417c24a887
commit 33e2c27386
1 changed files with 75 additions and 72 deletions
Download Patch File Download Diff File Expand all files Collapse all files

147
doc/admin-guide-cloud/source/orchestration-auth-model.rst
View File

@@ -5,131 +5,134 @@ Orchestration authorization model
================================= =================================
Orchestration authorization model defines the process of authorization The Orchestration authorization model defines the
that orchestration module uses to authorize requests during so called authorization process for requests during deferred operations.
deferred operations. The typical example of such operation is A common example is an auto-scaling group update. During
autoscaling group update when Orchestration requests other components the operation, the Orchestration service requests resources
(OpenStack Compute, Openstack Networking or others) to extend (reduce) of other components (such as servers from Compute or networks
capacity of autoscaling group. from Networking) to extend or reduce the capacity of an
auto-scaling group.
Currently, Orchestration provides two kinds of authorization models: The Orchestration service provides the following authorization models:
* Password authorization, * Password authorization
* Authorization with OpenStack Identity trusts. * OpenStack Identity trusts authorization
Password authorization Password authorization
~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~
Password authorization is the initial authorization model that was The Orchestration service supports password authorization.
supported by Orchestration module. This kind of authorization requires Password authorization requires that a user pass a
from a user to pass a password to Orchestration. Orchestration stores username/password to the service. The Orchestration service
the encrypted password in the database and uses it for deferred stores the encrypted password in the database and uses it
operations. for deferred operations.
The following steps are executed for password authorization: Password authorization involves the following steps:
#. User requests a stack creation, providing a token and #. A user requests stack creation, by providing a token and
username/password (python-heatclient or OpenStack dashboard username/password. The Dashboard or
normally requests the token for you). python-heatclient requests the token on the user's behalf.
#. If the stack contains any resources marked as requiring deferred #. If the stack contains any resources that require deferred
operations, orchestration engine will fail validation checks if no operations, then the orchestration engine fails its validation
username/password is provided. checks if the user did not provide a valid username/password.
#. The username/password are encrypted and stored in the Orchestration #. The username/password are encrypted and stored in the Orchestration
DB. database.
#. Stack creation is completed. #. The stack is created.
#. At some later stage, Orchestration retrieves the credentials and #. Later, the Orchestration service retrieves the credentials and
requests another token on behalf of the user. The token is not 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 limited in scope and provides access to all the roles of the stack
owner. owner.
Keystone trusts authorization OpenStack Identity trusts authorization
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A trust is an OpenStack Identity extension that provides a method A trust is an OpenStack Identity extension that enables delegation,
to enable delegation, and optionally impersonation via OpenStack and optionally impersonation through the OpenStack Identity service.
Identity. The key terminology is *trustor* (the user delegating) and The key terminology is *trustor* (the user delegating) and
*trustee* (the user being delegated to). *trustee* (the user being delegated to).
To create a trust, the *trustor* (in this case, the user creating the To create a trust, the *trustor* (in this case, the user creating the
stack in Orchestration module) provides OpenStack Identity with the stack in the Orchestration service) provides the OpenStack Identity service
following information: with the following information:
* The ID of the *trustee* (who you want to delegate to, in this case, * The ID of the *trustee* (who you want to delegate to, in this case,
the Orchestration module user). the Orchestration service user).
* The roles to be delegated (configurable via the ``heat.conf``, but * The roles to be delegated. The roles are configurable through
it needs to contain whatever roles are required to perform the the ``heat.conf`` file, but it must contain whatever roles
deferred operations on the users behalf, for example, launching an are required to perform the deferred operations on the user's behalf.
OpenStack Compute instance in response to an AutoScaling event). For example, launching an OpenStack Compute instance in response
to an auto-scaling event.
* Whether to enable impersonation. * Whether to enable impersonation.
OpenStack Identity then provides a trust_id, which can be consumed by Then, the OpenStack Identity service provides a *trust id*,
*only* the trustee to obtain a *trust scoped token*. This token is which is consumed by *only* the trustee to obtain a
limited in scope such that the trustee has limited access to those *trust scoped token*. This token is limited in scope,
roles delegated, along with effective impersonation of the trustor such that the trustee has limited access to those
user if it was selected when creating the trust. More information is roles delegated. In addition, the trustee has effective impersonation
available in the :ref:`Identity management <identity_management>` of the trustor user if it was selected when creating the trust.
For more information, see the :ref:`Identity management <identity_management>`
section. section.
The following steps are executed for trusts authorization: Trusts authorization involves the following steps:
#. User creates a stack via an API request (only the token is #. A user creates a stack through an API request (only the token is
required). required).
#. Orchestration uses the token to create a trust between the stack #. The Orchestration service uses the token to create a trust
owner (trustor) and the Orchestration module user (trustee), between the stack owner (trustor) and the Orchestration
delegating a special role (or roles) as defined in the service user (trustee). The service delegates a special role (or roles)
*trusts_delegated_roles* list in the Orchestration configuration as defined in the *trusts_delegated_roles* list in the
file. By default, Orchestration module sets all the roles from Orchestration configuration file. By default, the Orchestration
trustor available for trustee. Deployers may modify this list to service sets all the roles from trustor available for trustee.
reflect local RBAC policy, for example, to ensure the heat process Deployers might modify this list to reflect a local RBAC policy.
can only access those services expected while impersonating a For example, to ensure that the heat process can access only
stack owner. those services that are expected while impersonating a stack owner.
#. Orchestration stores the encrypted *trust id* in the Orchestration #. Orchestration stores the encrypted *trust id* in the Orchestration
DB. database.
#. When a deferred operation is required, Orchestration retrieves the #. When a deferred operation is required, the Orchestration service
*trust id* and requests a trust scoped token which enables the retrieves the *trust id* and requests a trust scoped token which
service user to impersonate the stack owner for the duration of enables the service user to impersonate the stack owner during
the deferred operation, for example, to launch some OpenStack the deferred operation. Impersonation is helpful, for example,
Compute instances on behalf of the stack owner in response to an so the service user can launch Compute instances on
AutoScaling event. behalf of the stack owner in response to an auto-scaling event.
Authorization model configuration Authorization model configuration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Password authorization model had been the default authorization model Initially, the password authorization model was the
enabled for the Orchestration module before the Kilo release. Since default authorization model. Since the Kilo release, the
the Kilo release, the trusts authorization model has been enabled by Identity trusts authorization model is enabled for the Orchestration
default. service by default.
To enable the password authorization model, the following change To enable the password authorization model, change the following
should be made in ``heat.conf``: parameter in the ``heat.conf`` file:
.. code-block:: ini .. code-block:: ini
deferred_auth_method=password deferred_auth_method=password
To enable the trusts authorization model, the following change should To enable the trusts authorization model, change the following
be made in ``heat.conf``: parameter in the ``heat.conf`` file:
.. code-block:: ini .. code-block:: ini
deferred_auth_method=trusts deferred_auth_method=trusts
To specify the trustor roles that it delegates to trustee during To specify the trustor roles that it delegates to trustee during
authorization, the ``trusts_delegated_roles`` parameter should be authorization, specify the ``trusts_delegated_roles`` parameter
specified in ``heat.conf``. If ``trusts_delegated_roles`` is not in the ``heat.conf`` file. If ``trusts_delegated_roles`` is not
defined, then all the trustor roles are delegated to trustee. defined, then all the trustor roles are delegated to trustee.
.. note:: .. note::
The trustor delegated roles should be pre-configured in the The trustor delegated roles must be pre-configured in the
OpenStack Identity before using it in the Orchestration module. OpenStack Identity service before using them in the Orchestration service.