The orchestration service for OpenStack

5 min read

This article by Adnan Ahmed, the author of the book, OpenStack Orchestration, will discuss the orchestration service for OpenStack.

(For more resources related to this topic, see here.)

Orchestration is a main feature provided and supported by OpenStack. It is used to orchestrate cloud resources, including applications, disk resources, IP addresses, load balancers, and so on.

Heat contains a template engine that supports text files, where cloud resources are defined. These text files are defined in a special format compatible with Amazon CloudFormation. A new OpenStack native standard has also been developed for providing templates for orchestration called HOT (Heat Orchestration Template).

Heat provides two types of clients; namely, a command-line client and a web-based client integrated into OpenStack dashboard.

The orchestration project (Heat) itself is composed of several subcomponents. These subcomponents are listed as follows:

  • Heat
  • Heat engine
  • Heat API
  • Heat API-CFN

Heat uses the term stack to define a group of services, resources, parameters inputs, constraints, and dependencies. A stack can be defined using a text file; however, the important point is to use the correct format. The JASON format used by AWS Cloud Formation is also supported by Heat.

Heat workflow

Heat provides two types of interfaces, including a web-based interface integrated into the OpenStack dashboard, and also a command-line interface (CLI), which can be used from inside a Linux shell.

The interfaces use the Heat API to send commands to the Heat engine via the messaging service (for example, Rabbit MQ). A metering service such as the Ceilometer or CloudWatch API is used to monitor the performance of resources in the stack. These monitoring/metering services are used to trigger actions upon reaching a certain threshold. An example of this could be automatically launching a redundant web server behind a load balancer when the CPU load on the primary web server reaches above 90 percent.

The orchestration authorization model

The Heat component of OpenStack uses an authorization model composed of mainly two types:

  • Password-based authorization
  • Authorization-based on OpenStack identity trusts

This process is known as orchestration authorization.

Password authorization

In this type of authorization, a password is expected from the user. This password must match with the password stored in a database by the Heat engine in an encrypted form.

The following are the steps used to generate a username/password:

  • A request is made to the Heat engine for a token or an authorization password. Normally, the Heat command-line client or the dashboard is used.
  • The validation checks will fail if the stack contains any resources under deferred operations. If everything is normal, then a username/password is provided.
  • The username/password are stored in the database in encrypted form.

In some cases, the Heat engine, after obtaining the credentials, requests another token on the user’s behalf, and thereafter, access to all the roles of stack owner are provided.

Keystone trusts authorization

Keystone trusts are extensions to the OpenStack identity service that are used for enabling delegation of resources. The trustor and the trustee are the two delegates used in this method. The trustor is the user who delegates and the trustee is the user who is being delegated. The following information from the trustor is required by the identity service to delegate a trustee:

  • The ID of the trustee (the user to be delegated, in the case of Heat, it will be the Heat user)
  • The roles to be delegated (The roles are configured using the Heat configuration file. For example, to launch a new instance to achieve auto-scaling in the case of reaching a threshold)

Trusts authorization execution

The creating a Stack via an API request step can be followed to execute a trust-based authorization.

A token is used to create a trust between the stack owner (the trustor) and the Heat service user (also known as trustee in this case). A special role is delegated. This role must be predefined in the trusts_delegated-roles list inside the heat.conf file.

By default, all the available roles for trustor are set to be available for the trustee if it is not modified using a local RBAC policy.

This trust ID is stored in an encrypted form in the database. This trust ID is retrieved from the database when an operation is required.

Authorization model configuration

Heat used to support the password-based authorization until the Kilo version of OpenStack was released. Using the kilo version of OpenStack, the following changes can be made to enable trusts-based authorization in the Heat configuration file:

  • Default setting in heat.conf:
  • To be replaced to enable trusts-based authentication:
  • The following parameter need to be set to specify trustor roles:
    trusts_delegated_roles =

As mentioned earlier, all available roles for trustor will be assigned to the trustee if no specific roles are mentioned in the heat.conf file.

Stack domain users

The Heat stack domain user is used to authorize a user to carry out certain operations inside a virtual machine.

Agents running inside virtual machine instances are provided with metadata. These agents repot and share the performance statistics of the VM on which they are running.

They use this metadata to apply any changes or some sort of configuration expressed in the metadata.

A signal is passed to the Heat engine when an event is completed successfully or with failed status. A typical example could be to generate an alert when the installation of an application is completed on a specific virtual machine after its first reboot.

Heat provides features for encapsulating all the stack-defined users into a separate domain. This domain is usually created to store the information related to the Heat service. A domain admin is created, which is used by Heat for the management of the stack-domain users.


In this article, we learned that Heat is the orchestration service for OpenStack. We learned about the Heat authorization models, including password authorization, keystone trust authorization, and how these models work. For more information on OpenStack, you can visit:


Resources for Article:

Further resources on this subject:


Please enter your comment!
Please enter your name here