Main menu

Pages

Identity Service in Openstack (Keystone)

Identity Service in Openstack (Keystone)

Openstack Identity service (keystone)


Keystone, the Identity service, manages the authentication and authorization infrastructure for the  OpenStack Platform. It keeps track of users and their permitted activities.

Supports multiple forms of authentication:
  • User name and password
  • Central directory (IPA)
  • Token-based authentication
  • AWS-style logins (Amazon Web Services)

Identity Service Components

Token: A token is a randomly generated string of characters used to authenticate resource access.

User: A user is a consumer or administrator entity. It can log in and maybe assigned tokens for access to specific resources. Users can belong to multiple projects.

Project: A project is a unit of ownership that contains one or more users. You can look at projects as logical groups that are used to define users' privileges and scopes. Projects are sometimes referred to as tenants, particularly in the output for certain commands.

Credentials: Credentials consist of a user name and password, a user name and API key, or a Keystone authentication token.

Service: A service is a task-specific engine that provides an infrastructure function. It describes an OpenStack component and contains a name and topic that describes the type of service. Keystone is a service.

Service catalog: A service catalog is a selection of available OpenStack services with their API endpoint addresses.

Role: A role is a set of rights and privileges that can be assigned to a user.

Endpoint: An endpoint is a network-accessible address, usually described by URL, where a service is accessed. The location consists of a network address, the API for contacting the service, and any variable parameters that modify the service invocation, such as a dynamically passed user or project ID. For example, the Keystone service provides two endpoints: admin API, which listens at port 35357, and public API, which listens at port 5000.

Users and Projects:

A user is granted a role in a project. A user can have roles in multiple projects. Without a role in a project, a user cannot create or consume any virtual resources in that project. Users have associated information such as a name and password. In addition to your human users, you must define a user for each cataloged service—for example, the keystone user for the Identity service.
A project is simply a grouping of OpenStack resources. All virtual resources created in OpenStack must exist in a project. Projects are generally used to segregate resources. Quota controls are available to limit the following resources in each project:
  • The number of volumes that can be created
  • The total size of all volumes within a project, measured in gigabytes
  • The number of instances that may be launched
  • The number of processor cores that may be allocated
  • The floating IP addresses are assigned to any instance when it launches so that the instance has consistent publicly accessible IP addresses
  • Fixed IP addresses are assigned to the same instance each time it boots. These addresses can be publicly or privately accessible. Typically private IP addresses are used for management purposes.

Service Catalog:

The Identity service provides a central catalog of services and endpoints running in a particular OpenStack cloud. The catalog acts as a service directory for other OpenStack components. Each endpoint is assigned the following:
  • Admin URL is an administrative URL used only by the Identity service and is different from the Public URL, which is used by all other services.
  • Internal URL is the URL of an internal-facing endpoint for the service. internal URL is typically the same as public URL.
  • Public URL is the URL of the public-facing endpoint for the service.
  • Region is the location in which the service exists. By default, if no region is specified, the RegionOne location is used.

Keystone authentication process:

  1. A user decides to launch an instance. User credentials are sent to Keystone, which creates a temporary token and sends a generic catalog.
  2. The user requests all projects. Keystone sends the temporary token and list of projects to the user.
  3. Keystone provides the user with a list of services.
  4. The user sends credentials with the desired project, and Keystone sends back a list of available services and a project token. The user determines the correct endpoint to launch the instance and provides the project token to that service.
  5. The service asks Keystone to verify the user’s project token and confirm permission to use the service.
  6. Keystone provides additional information and the token.
  7. Keystone verifies that the token belongs to the user and that it matches the user’s request, then authorizes the user’s access to the project and service. The service validates the request against its own policy.
  8. The service executes the request and creates the instance.
  9. The service reports the status back to the user, telling the user that the instance has been created and where the user can reach the instance.

reactions