Add orchestration section into admin guide
Add articles about heat orchestration engine to the guide. The articles contain information about common goal of the heat and authorization model used in Heat. Change-Id: I8bf80a7b6b7425525cedf4cfad769f1ac8ee4cde Co-Authored-By: Steven Hardy <shardy@redhat.com>
This commit is contained in:
kairat_kushaev
parent
293f9a9a58
commit
d185092b21
@ -54,7 +54,11 @@
|
|||||||
in the Telemetry chapter. The tables
|
in the Telemetry chapter. The tables
|
||||||
contain the release information for all
|
contain the release information for all
|
||||||
collected meters regarding to when they
|
collected meters regarding to when they
|
||||||
were introduced in the module.
|
were introduced in the module. In addition,
|
||||||
|
the Orchestration chapter has been added to
|
||||||
|
the guide. It describes in details
|
||||||
|
Orchestration module available in OpenStack
|
||||||
|
since Havana release.
|
||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
@ -170,5 +174,6 @@
|
|||||||
<xi:include href="ch_networking.xml"/>
|
<xi:include href="ch_networking.xml"/>
|
||||||
<xi:include href="ch_telemetry.xml"/>
|
<xi:include href="ch_telemetry.xml"/>
|
||||||
<xi:include href="ch_database.xml"/>
|
<xi:include href="ch_database.xml"/>
|
||||||
|
<xi:include href="ch_orchestration.xml"/>
|
||||||
<xi:include href="../common/app_support.xml"/>
|
<xi:include href="../common/app_support.xml"/>
|
||||||
</book>
|
</book>
|
||||||
|
|||||||
44
doc/admin-guide-cloud/ch_orchestration.xml
Normal file
44
doc/admin-guide-cloud/ch_orchestration.xml
Normal file
@ -0,0 +1,44 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<chapter xmlns="http://docbook.org/ns/docbook"
|
||||||
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
|
version="5.0"
|
||||||
|
xml:id="ch_admin-openstack-orchestration">
|
||||||
|
<title>Orchestration</title>
|
||||||
|
<para>Orchestration is an orchestration engine that provides possibility
|
||||||
|
to launch multiple composite cloud applications based on templates in
|
||||||
|
the form of text files that can be treated like code. A native
|
||||||
|
Heat Orchestration Template (HOT) format is evolving, but it also
|
||||||
|
endeavours to provide compatibility with the AWS CloudFormation template
|
||||||
|
format, so that many existing CloudFormation templates can be launched
|
||||||
|
on OpenStack.</para>
|
||||||
|
<section xml:id="section_orchestration-introduction">
|
||||||
|
<title>Introduction</title>
|
||||||
|
<para>Orchestration is a tool for orchestrating clouds that
|
||||||
|
automatically configures and deploys resources in stacks.
|
||||||
|
Such deployments can be simple — like deploying WordPress on Ubuntu
|
||||||
|
with an SQL back-end. And they can be quite complex, like launching
|
||||||
|
a group of servers that autoscale: starting and stopping based on
|
||||||
|
realtime CPU loading information from Telemetry module.</para>
|
||||||
|
<para>Orchestration stacks are defined with templates, which are
|
||||||
|
non-procedural documents describing tasks in terms of resources,
|
||||||
|
parameters, inputs, constraints and dependencies. When
|
||||||
|
Orchestration module was originally introduced, it worked with
|
||||||
|
AWS CloudFormation templates, which are in JSON format.</para>
|
||||||
|
<para>Now, Orchestration also executes HOT (Heat Orchestration
|
||||||
|
Template) templates, written in YAML: a terse notation that loosely
|
||||||
|
follows Python/Ruby-type structural conventions (colons, returns,
|
||||||
|
indentation) so it’s more easily to write, parse, grep, generate with
|
||||||
|
tools, and maintain with source-code management systems.</para>
|
||||||
|
<para>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 launching stacks from
|
||||||
|
templates through web-interface.</para>
|
||||||
|
<para>For more details how to use Orchestration module command-line see
|
||||||
|
<link xlink:href="http://docs.openstack.org/cli-reference/content/">
|
||||||
|
OpenStack Command line interface reference</link>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<xi:include href="orchestration/section_orchestration-auth-model.xml"/>
|
||||||
|
</chapter>
|
||||||
@ -0,0 +1,153 @@
|
|||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<section xmlns="http://docbook.org/ns/docbook"
|
||||||
|
xmlns:xi="http://www.w3.org/2001/XInclude"
|
||||||
|
xmlns:xlink="http://www.w3.org/1999/xlink"
|
||||||
|
version="5.0"
|
||||||
|
xml:id="section_orchestration-auth-model">
|
||||||
|
<title>Orchestration authorization model</title>
|
||||||
|
<para>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 heat requests another components
|
||||||
|
(nova, neutron or others) to extend (reduce) capacity of autoscaling
|
||||||
|
group.</para>
|
||||||
|
<para>At the current moment, Orchestration provides two kinds of
|
||||||
|
authorization models:</para>
|
||||||
|
<para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>Password authorization.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Authorization with OpenStack Identity trusts.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
<section xml:id="section_orchestration-password-authorization">
|
||||||
|
<title>Password authorization</title>
|
||||||
|
<para>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 database and uses it for deferred
|
||||||
|
operations.</para>
|
||||||
|
<para>The following steps are executed for password authorization:</para>
|
||||||
|
<para>
|
||||||
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>User requests stack creation, providing a token and
|
||||||
|
username/password (python-heatclient or OpenStack dashboard
|
||||||
|
normally requests the token for you).</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>If the stack contains any resources marked as requiring
|
||||||
|
deferred operations orchestration engine will fail validation
|
||||||
|
checks if no username/password is provided.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>The username/password are encrypted and stored in the
|
||||||
|
orchestration DB.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Stack creation is completed.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>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
|
||||||
|
roles of the stack owner.</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="section_orchestration-keystone-trusts-authorization">
|
||||||
|
<title>Keystone trusts authorization</title>
|
||||||
|
<para>OpenStack Identity trusts is the new authorization method available
|
||||||
|
since IceHouse release.</para>
|
||||||
|
<para>Trusts are an OpenStack Identity extension, which provide a method to
|
||||||
|
enable delegation, and optionally impersonation via OpenStack
|
||||||
|
Identity. The key terminology is <emphasis>trustor</emphasis>
|
||||||
|
(the user delegating) and <emphasis>trustee</emphasis>
|
||||||
|
(the user being delegated to).</para>
|
||||||
|
<para>To create a trust, the <emphasis>trustor</emphasis>(in this case
|
||||||
|
the user creating the stack in Orchestration module) provides
|
||||||
|
OpenStack Identity with the following information:</para>
|
||||||
|
<para>
|
||||||
|
<itemizedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>The ID of the <emphasis>trustee</emphasis>(who you want to
|
||||||
|
delegate to, in this case the Orchestration service user).
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>The roles to be delegated(configurable via the
|
||||||
|
<filename>heat.conf</filename>, but it needs to contain whatever
|
||||||
|
roles are required to perform the deferred operations on the
|
||||||
|
users behalf, e.g launching a OpenStack Compute instance in
|
||||||
|
response to an AutoScaling event).</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Whether to enable impersonation.</para>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
<para>OpenStack Identity then provides a trust_id, which can be consumed by
|
||||||
|
the trustee (and <emphasis>only</emphasis> the trustee) to obtain a
|
||||||
|
<emphasis>trust scoped token</emphasis>. 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 Identity management section.</para>
|
||||||
|
<para>The following steps are executed for trusts authorization:</para>
|
||||||
|
<para>
|
||||||
|
<orderedlist>
|
||||||
|
<listitem>
|
||||||
|
<para>User creates a stack via an API request (only the token is
|
||||||
|
required).</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Orchestration uses the token to create a trust between
|
||||||
|
the stack owner (trustor) and the heat service user (trustee),
|
||||||
|
delegating a special role (or roles) as defined in the
|
||||||
|
<emphasis>trusts_delegated_roles</emphasis> list in the
|
||||||
|
heat configuration file. By default heat sets all roles from
|
||||||
|
trustor available for trustee. Deployers may modify this list to
|
||||||
|
reflect local RBAC policy, e.g to ensure the heat process can
|
||||||
|
only access those services expected while impersonating
|
||||||
|
a stack owner.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>Orchestration stores the encrypted
|
||||||
|
<emphasis>trust id</emphasis> in the Orchestration DB.</para>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<para>When a deferred operation is required, Orchestration
|
||||||
|
retrieves the <emphasis>trust id</emphasis>, and requests a
|
||||||
|
trust scoped token which enables the service user to impersonate
|
||||||
|
the stack owner for the duration of the deferred operation, e.g
|
||||||
|
to launch some OpenStack Compute instances on behalf of
|
||||||
|
the stack owner in response to an AutoScaling event.</para>
|
||||||
|
</listitem>
|
||||||
|
</orderedlist>
|
||||||
|
</para>
|
||||||
|
</section>
|
||||||
|
<section xml:id="section_orchestration-authorization-model-configuration">
|
||||||
|
<title>Authorization model configuration</title>
|
||||||
|
<para>Password authorization model had been the default authorization
|
||||||
|
model enabled for Orchestration module before Kilo release. Since Kilo
|
||||||
|
release trusts authorization model has been enabled by default.</para>
|
||||||
|
<para>To enable password authorization model the following change should
|
||||||
|
be made in <filename>heat.conf</filename>:</para>
|
||||||
|
<programlisting language="ini">deferred_auth_method=password</programlisting>
|
||||||
|
<para>To enable trusts authorization model the following change should be
|
||||||
|
made in <filename>heat.conf</filename>:</para>
|
||||||
|
<programlisting language="ini">deferred_auth_method=trusts</programlisting>
|
||||||
|
<para>To specify trustor roles that will be delegated to trustee during
|
||||||
|
authorization <literal>trusts_delegated_roles</literal> parameter
|
||||||
|
should be specified in <filename>heat.conf</filename>. If
|
||||||
|
<literal>trusts_delegated_roles</literal> is not defined then all
|
||||||
|
trustor roles will be delegated to trustee. Please pay attention that
|
||||||
|
trust delegated roles should be pre-configured in OpenStack Identity
|
||||||
|
before using it in Orchestration module.</para>
|
||||||
|
</section>
|
||||||
|
</section>
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user