Book Image

OpenStack Orchestration

By : Adnan Ahmed Siddiqui
Book Image

OpenStack Orchestration

By: Adnan Ahmed Siddiqui

Overview of this book

This book is focused on setting up and using one of the most important services in OpenStack orchestration, Heat. First, the book introduces you to the orchestration service for OpenStack to help you understand the uses of the templating mechanism, complex control groups of cloud resources, and huge-potential and multiple-use cases. We then move on to the topology and orchestration specification for cloud applications and standards, before introducing the most popular IaaS cloud framework, Heat. You will get to grips with the standards used in Heat, overview and roadmap, architecture and CLI, heat API, heat engine, CloudWatch API, scaling principles, JeOS and installation and configuration of Heat. We wrap up by giving you some insights into troubleshooting for OpenStack. With easy-to-follow, step-by-step instructions and supporting images, you will be able to manage OpenStack operations by implementing the orchestration services of Heat.
Table of Contents (14 chapters)
OpenStack Orchestration
About the Author
About the Reviewers
Stack Group of Connected Cloud Resources

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:

  1. 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.

  2. The validation checks will fail if the stack contains any resources under deferred operations. If everything is normal, then a username/password is provided.

  3. 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 the stack owner are provided.

Keystone trusts authorization

Keystone trusts are extensions to OpenStack identity services 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 (user to be delegated, in 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 case of reaching a threshold)

Trusts authorization execution

The creation of 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 the 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 the 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.