Converts section_orchestration_auth-model.xml to RST
This patch: - adds a translated orchestration_auth-model.rst to the openstack-manuals/doc/admin-guide-cloud-rst/source; - adds an _identity_management header markup to the identity_management.rst file (to refer to it in other files); - corrects several grammar and punctuation mistakes. Change-Id: Icd9110de71397cab1e8f30ff813562b4e2911765 Implements: blueprint reorganise-user-guides
This commit is contained in:
Olena Logvinova
@@ -1,3 +1,5 @@
|
||||
.. _identity_management:
|
||||
|
||||
===================
|
||||
Identity management
|
||||
===================
|
||||
|
||||
141
doc/admin-guide-cloud-rst/source/orchestration-auth-model.rst
Normal file
141
doc/admin-guide-cloud-rst/source/orchestration-auth-model.rst
Normal file
@@ -0,0 +1,141 @@
|
||||
.. _orchestration-auth-model:
|
||||
|
||||
.. highlight: ini
|
||||
:linenothreshold: 3
|
||||
|
||||
:orphan:
|
||||
|
||||
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.
|
||||
|
||||
Currently, Orchestration provides two kinds of authorization models:
|
||||
|
||||
* Password authorization,
|
||||
|
||||
* Authorization with OpenStack Identity trusts.
|
||||
|
||||
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 following steps are executed for password authorization:
|
||||
|
||||
#. User requests a stack creation, providing a token and
|
||||
username/password (python-heatclient or OpenStack dashboard
|
||||
normally requests the token for you).
|
||||
|
||||
#. If the stack contains any resources marked as requiring deferred
|
||||
operations, orchestration engine will fail validation checks if no
|
||||
username/password is provided.
|
||||
|
||||
#. The username/password are encrypted and stored in the Orchestration
|
||||
DB.
|
||||
|
||||
#. Stack creation is completed.
|
||||
|
||||
#. At some later stage, Orchestration 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 is a new authorization method available
|
||||
since the IceHouse release.
|
||||
|
||||
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
|
||||
*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:
|
||||
|
||||
* The ID of the *trustee* (who you want to delegate to, in this case,
|
||||
the Orchestration module 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).
|
||||
|
||||
* 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>`
|
||||
section.
|
||||
|
||||
The following steps are executed for trusts authorization:
|
||||
|
||||
#. User creates a stack via 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.
|
||||
|
||||
#. Orchestration stores the encrypted *trust id* in the Orchestration
|
||||
DB.
|
||||
|
||||
#. 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.
|
||||
|
||||
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.
|
||||
|
||||
To enable the password authorization model, the following change
|
||||
should be made in ``heat.conf``:
|
||||
|
||||
.. code-block:: ini
|
||||
|
||||
deferred_auth_method=password
|
||||
|
||||
To enable the trusts authorization model, the following change should
|
||||
be made in ``heat.conf``:
|
||||
|
||||
.. 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
|
||||
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.
|
||||
@@ -38,14 +38,20 @@ Orchestration can be accessed via the CLI, and using RESTful queries.
|
||||
Orchestration module provides both an OpenStack-native REST API and a
|
||||
CloudFormation-compatible Query API. Orchestration is also integrated
|
||||
with OpenStack dashboard in order to launch stacks from templates
|
||||
through a web-interface.
|
||||
through a web interface.
|
||||
|
||||
For more details on how to use Orchestration module command-line, see
|
||||
`OpenStack Command-Line Interface Reference`_.
|
||||
For more details on how to use Orchestration module through a command
|
||||
line, see `OpenStack Command-Line Interface Reference`_.
|
||||
|
||||
.. Links
|
||||
.. _`OpenStack Command-Line Interface Reference`: http://docs.openstack.org/cli-reference
|
||||
|
||||
.. include:: orchestration-auth-model.rst
|
||||
|
||||
.. toctree::
|
||||
:hidden:
|
||||
|
||||
orchestration-auth-model.rst
|
||||
|
||||
.. TODO (OL) Convert and include the below sections
|
||||
include: orchestration/section_orchestration-auth-model.xml
|
||||
include: orchestration/section_orchestration-stack-domain-users.xml
|
||||
include: orchestration/section_orchestration-stack-domain-users.xml
|
||||
|
||||
Reference in New Issue
Block a user