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