2
Understanding the OpenStack Ecosystem: Core Projects

WHAT'S IN THIS CHAPTER?                   

• How the different OpenStack components work together and how authentication works within the infrastructure
• A look at how a compute instance is composed and the different hypervisors supported in OpenStack
• How data is stored in the infrastructure and understanding the differences between Block Storage and Object Storage
• How instance templates and snapshots are created and where they are stored
• The different ways to manage your OpenStack resources: GUI versus CLI versus APIs
• How the network is designed in OpenStack and the different network components available and exposed through the APIs

At this point, you have an understanding of why cloud computing is important to application developers, and a general overview of OpenStack. In this chapter, you will learn the core services in more detail. These are the services most critical to running an application-compute, network, and storage. You will also learn about the management services to make those possible, such as the identity service, which allows you to authenticate in order to create your applications.

Sometimes, it may seem that the descriptions in this chapter go into more detail than you need to run an application. However, you can think of these features as tools and building blocks. You need to have a solid understanding of what is possible, so you can see new ways to build flexible, scalable, and robust applications (see Figure 2.1).

Figure 2.1  

IDENTITY

The identity service within OpenStack, named Keystone, is responsible for authentication, authorization and accounting (AAA) and currently implements and provides the OpenStack Identity API.

The main goal of this identity service is to process and validate authentication and authorization requests, then return an "authentication token," which is used to authenticate the user against the APIs and can be used to contact the other services of an OpenStack infrastructure. These services can be discovered using the catalog returned in the authentication response (detailed later in this chapter).

Keystone currently implements two versions of the Identity API (v2, v3). The second version has been used for years and is still mainly used today in the different libraries and clients supporting OpenStack. The third version is quite recent and provides a more pluggable and flexible design, allowing using multiple authentication mechanisms (the original "password" method, but moreover well-known and used mechanisms, such as OAuth or SAML2), and the ability to combine these methods in a single request.

This last Identity API has a multi-tenant design and has simple resources:

• Region: an OpenStack infrastructure that optionally may have sub-regions
• Service with Endpoints: an OpenStack registered service in Keystone that can have zero, one, or multiple endpoints to reach this one (e.g. public, internal, admin)
• Domain: a container for the users, groups, and projects
• Project (known as "Tenant" in the second version of the API): owning a set of OpenStack resources
• User: a single API consumer, which should have really restricted authorizations in your application
• Group: a collection of different users of the same domain
• Role: an authorization that a user or a group of users can obtain on a project or a domain

All of these resources can be managed using the Identity Admin API, which is available as a create, read, update, and delete (CRUD) RESTful API.

Using Tokens and Re-Authentication

The authentication against the different OpenStack services is based on tokens provided by the identity service (Keystone) or configured in the service itself (e.g. admin tokens).

A token provided by an identity service is an arbitrary string that contains the User identity and optionally an authorization called scope. The authorization attached to this token grants access to a Project or a Domain, allowing you to access Project or Domain-related resources.

You can easily create a token using the Identity API with the method POST /auth/tokens with a user identity and the wanted scope:

Token Identities

When requesting a new token, the identity parameter will contain the used authentication mechanisms. Here is an example using password. The unique identifier of the user is used here, however it is possible to use the username if the domain is explicitly specified.

Scoped and Non-Scoped Tokens

If specified in the request, the authorization scope must contain the project identifier or the domain identifier.

If a scope has been provided in the token creation request, the Identity API will return a catalog containing the different OpenStack services that can be used by the user with the token and the roles granted to this user.