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 

ConceptDescription
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.
FormatAccept HeaderQuery ExtensionDefault
JSONapplication/json.jsonYes
XMLapplication/xml.xmlNo

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

  1. keystone tenant-create --name=admin --description="Admin Tenant"
  2. keystone tenant-create --name=service --description="Service Tenant"

  4. Creating an admin user
  5. 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


Popular posts from this blog

Learning OpenStack - The Easy Way

-
Image
Dear Friends, Our Dream has come true! It takes 9 months for a mother to bring another life. That is the amount of time it has taken me to demystify the otherwise terse and abstract cloud computing concepts. And thanks to Packt Publishing I for helping me impart this knowledge in the most engaging way. The Full video course is out you can get more details about it here . You can get more details about the course here without registering. The Overview video is out for all. It was a tough negotiation with publisher to give out this valuable video for free I hope that it will get you started on your "Infrastructure as Code" journey. Three points I would like to share, which might help you are:- People are watching us! Packt publishing approached me watching the screencasts I had posted on Youtube. (Which until then I was certain that nobody was watching). Good news is Video course royalty is 3 times that of a book! Bad news is because its 3 times the...
Read more

Vagrant on steroids

-
Image
Source This is our life when we are working on automating some really complicated machine building and provisioning procedures. I.e. while developing the playbooks in Ansible, or CookBooks in Chef or manifests in Puppet. It is not easy to fail faster and fix early as the script might have to download all the dependencies again and again. Adding to all the odds, it could be that the dependencies are being downloaded on a low bandwidth. Even though Vagrant makes bringing up VM and their management faster, the provisioning (using Ansible, Chef or Puppet or etc) might take inordinately long times when it involves, and it usually does involve downloading packages on the VMs. And it gets painful when you have to download a full stack of several libraries to test your VM. To help overcome this issue, we can use the following to cache the dependencies and test the configuration scripts or recipes faster, the following should set you up (assuming you have vagrant already installe...
Read more