OpenStack's Identity Management--KeyStone--A Deep Dive

What is KeyStone?

Keystone is an OpenStack project that provides the following services to other projects in the OpenStack family:

Identity

Token

Catalog

Policy

Some interesting definitions providing more depth to what seems to be already known 

Concept	Description
User	A digital representation of a person, system, or service that uses OpenStack cloud services. OpenStack Identity authentication services validate that an incoming request is being made by the user who claims to be making the call. Users have a login and may be assigned tokens to access resources. Users may be directly assigned to a particular tenant and behave as if they are contained in that tenant.
Credentials	Data that belongs to, is owned by, and generally only known by a user that the user can present to prove their identity. Examples include: A matching username and password A matching username and API key A token that was issued to you
Authentication	In the context OpenStack Identity, the act of confirming the identity of a user or the truth of a claim. OpenStack Identity confirms that an incoming request is being made by the user who claims to be making the call by validating a set of claims that the user is making. These claims are initially in the form of a set of credentials. After initial confirmation, OpenStack Identity issues the user a token, which the user can then provide to demonstrate that their identity has been authenticated when making subsequent requests.
Token	An arbitrary bit of text that is used to access resources. Each token has a scope that describes which resources are accessible with it. A token may be revoked at anytime and is valid for a finite duration. While OpenStack Identity supports token-based authentication in this release, the intention is for it to support additional protocols in the future. The intent is for it to be an integration service foremost, and not aspire to be a full-fledged identity store and management solution.
Tenant	A container used to group or isolate resources and/or identity objects. Depending on the service operator, a tenant can map to a customer, account, organization, or project.
Service	An OpenStack service, such as Compute (Nova), Object Storage (Swift), or Image Service (Glance). A service provides one or more endpoints through which users can access resources and perform operations.
Endpoint	A network-accessible address, usually described by a URL, where a service may be accessed. If using an extension for templates, you can create an endpoint template, which represents the templates of all the consumable services that are available across the regions.
Role	A personality that a user assumes when performing a specific set of operations. A role includes a set of rights and privileges. A user assuming that role inherits those rights and privileges. In OpenStack Identity, a token that is issued to a user includes the list of roles that user can assume. Services that are being called by that user determine how they interpret the set of roles a user has and to which operations or resources each role grants access. It is up to individual services such as the Compute service and Image service to assign meaning to these roles. As far as the Identity service is concerned, a role is an arbitrary name assigned by the user.

Request/Response Types

The OpenStack Identity API supports both the JSON and XML data serialization formats. The request format is specified using the Content-Type header and is required for operations that have a request body. The response format can be specified in requests using either the Accept header or adding an .xml or .jsonextension to the request URI. Note that it is possible for a response to be serialized using a format different from the request (see example below). If no response format is specified, JSON is the default. If conflicting formats are specified using both an Accept header and a query extension, the query extension takes precedence.

Format	Accept Header	Query Extension	Default
JSON	application/json	.json	Yes
XML	application/xml	.xml	No

Authentication and Authorization flow in Keystone

Below is a flow depicting the Authentication and Authorization flow using Keystone.

Keystone Up and running!

As discussed in the previous post we are mainly focused on getting the user's perspective on the component.

To be as close to a production environment as possible, we have chosen to have this running on CentOS.

Getting the Controller Node ready:-

Install CentOS

Setup Network service to start, set hostname, etc.
Sync time using with the ntp service

MySQL installed and running

OpenStack dependencies installed,

Messaging Server Qpid installed and configured

Bring the Server up and running

yum install openstack-keystone python-keystoneclient

The above will have openstack and it's dependency installed, and now hooking it up to the MySQL Database, do the following

          vi /etc/keystone/keystone.conf

         

          uncomment "connection" variable in the SQL section and set it to

                 connection = mysql://keystone:keystone_password@localhost/keystone

                   

     Using the openstack-db command we will go ahead and create the database and tables we created in our previous session.

     openstack-db --init --service keystone --password KEYSTONE_DBPASS

We hit upon an error that is "ungoogleable", please see the end of this doc for some information on that.

Now we will go ahead and create a secret token that would be shared between the Identity service and other OpenStack services. Which is done by editing the keystone.conf

and setting

admin_token = somerandom_password(no quotes)

Keystone uses PKI tokens, and we are going to now create the signing keys and certs:

          The identity service generates tokens which are cryptographically signed documents users and other services use for authentication.

          The tokens are signed using a private key while the public key is made available in an X509 certificate.

          The certificates and relevant configuration keys are automatically generated by the keystone-manage pki_setup command.

          The configuration keys relevant to PKI setup appear in the [signing] section of the /etc/keystone/keystone.conf configuration file that are relevant to the PKI setup are:

    keystone-manage pki_setup --keystone-user keystone --keystone-group keystone

post this we ensure the ownership using the below command

chown -R keystone:keystone /var/log/keystone /etc/keystone/ssl/

Post his we can enable the service to start when the system reboots or boots

    

     chkconfig openstack-keystone on

to start the service we can use

     service openstack-keystone start

Define Users, Tenants and Roles

These are used to allow access to services and endpoints.

We authenticate with the service using the Admin token we had defined earlier and the service end point is http://controller:35357/v2.0

We will now create a tenant for an administrative user and a tenant for other OpenStack Services to use, by using the command keystone tenant-create

0. keystone tenant-create --name=admin --description="Admin Tenant"
1. keystone tenant-create --name=service --description="Service Tenant"
2. 
   
3. Creating an admin user
4. keystone user-create --name=admin --pass=password --email=admin@example.com

Now we will go ahead and create a role for the user. Since its for admin, we will go ahead and create an administrative tasks role called "admin".

Any roles we create should be mapped to roles specified in the policy.json files of various OpenStack services. Which is in /etc/keystone/policy.json

keystone user-create --name=admin

    

Now we will go ahead and add the user "admin to the role "admin" and tenant "admin"

keystone user-role-add --user=admin --tenant=admin --role=admin

Define services and API endpoints

The identity service can track which OpenStack services are installed and where they are located on the network.

We will have to register each service in OpenStack installation, using commands like keystone service-create, keystone endpoint-create

1. Creating a service entry for the identity service

      keystone service-create --name=keystone --type=identity --description="Keystone Identity Service"

2. Specifying an API endpoint for the Identity service by using the returned service ID from above.

     Endpoints are nothing but usually URLs and hence we will provide URLs for

• Public API
• Internal API
• Admin API

     keystone endpoint-create \

     --service-id=the_service_id_above \

     --publicurl=http://controller:5000/v2.0 \

     --internalurl=http://controller:5000/v2.0 \

     --adminurl=http://controller:35357/v2.0

Testing Keystone now!

Create a file called openrc.sh to have all the --os-* environment variables

export OS_USERNAME=admin
export OS_PASSWORD=ADMIN_PASSexport OS_TENANT_NAME=admin
export OS_AUTH_URL=http://controller:35357/v2.0

we can now source the file using the command source openrc.sh

And run commands such as

     keystone token-get

     keystone user-list