starter-kit:compute (IV) – Managing Keystone

Now that we have a functional and running keystone is time to start populating its database with all the users, projects and tenants that we’ll be using it the day to day. First of all, another user and his virtual environment will be created to install the ‘openstackclient’. This ‘new’ CLI is an effort to have an only command line tool to interact with all the openstack services.

root@aio:~# useradd -m stack
stack@aio:~$ virtualenv venv
stack@aio:~$ source venv/bin/activate
stack@aio:~$ pip install python-openstackclient

To bootstrap keystone, there is a special TOKEN that can be used to create the initial users. We also need to specify the URL where to find the keystone service. All this data can be stored in a file, ‘tokenrc’, and sourced when needed.

export OS_TOKEN=ADMIN
export OS_URL=http://aio:35357/v2.0

The value of the initial token is located in the keystone.conf file under the [DEFAULT] group, with an initial value of ADMIN.

[DEFAULT]
 …
 #admin_token = ADMIN

Creating users, projects and roles

A project (formerly known as tenant), can have several users, and each of this users has a role within that project. It can be ‘admin’, a simple member (by default, indicated by the role ‘_member_’), or any other role we want to create. What a role can and can’t do, is specified in the ‘policy.json’ configuration file. In this example, we will create a project called ‘stack’, an admin role, and two users, one of them being the admin of the project.

(venv)stack@aio:~$ openstack project create stack
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | None |
| enabled | True |
| id | ebae83a27e7a4409aea4311543b7dadb |
| name | stack |
+-------------+----------------------------------+

(venv)stack@aio:~$ openstack role create admin
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 3a933d2b3957477b9aabf1e0f32cb388 |
| name | admin |
+-------+----------------------------------+

(venv)stack@aio:~$ openstack user create gru --project stack --password minions
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| email | None |
| enabled | True |
| id | 9be9ad60d4594c288f5b3305e84e3e63 |
| name | gru |
| project_id | ebae83a27e7a4409aea4311543b7dadb |
| username | gru |
+------------+----------------------------------+

(venv)stack@aio:~$ openstack role add --user gru --project stack admin
+-------+----------------------------------+
| Field | Value |
+-------+----------------------------------+
| id | 3a933d2b3957477b9aabf1e0f32cb388 |
| name | admin |
+-------+----------------------------------+

(venv)stack@aio:~$ openstack user create stuart --project stack --password banana
+------------+----------------------------------+
| Field | Value |
+------------+----------------------------------+
| email | None |
| enabled | True |
| id | 85a51778c59f4c66aed800f74cf3cf77 |
| name | stuart |
| project_id | ebae83a27e7a4409aea4311543b7dadb |
| username | stuart |
+------------+----------------------------------+

Although we will not need it now, it’s common to create a special project, usually called ‘service’, with one user per service deployed, like nova or glance, so each of then can authenticate and validate tokens using their own accounts.

(venv)stack@aio:~$ openstack project create service --description "Service Project"
+-------------+----------------------------------+
| Field | Value |
+-------------+----------------------------------+
| description | Service Project |
| enabled | True |
| id | 7bd37e546f4741c6bfba687f35711ae5 |
| name | service |
+-------------+----------------------------------+

Finally, we need to create a service endpoint. This will be published in the Keystone service catalog, and will help services to locate other services in the deployed cloud.

(venv)stack@aio:~$ openstack service create --name keystone \
> --description "Keystone Identity Service" \
> identity
+-------------+----------------------------------+
| Field       | Value                            |
+-------------+----------------------------------+
| description | Keystone Identity Service        |
| enabled     | True                             |
| id          | 7796b8d0e5ff4267abf3b7766c670fb9 |
| name        | keystone                         |
| type        | identity                         |
+-------------+----------------------------------+
(venv)stack@aio:~$ openstack endpoint create --region RegionOne --publicurl "http://aio:5000/v2.0" --adminurl "http://aio:35357/v2.0" --internalurl "http://aio:5000/v2.0" keystone

+--------------+----------------------------------+
| Field        | Value                            |
+--------------+----------------------------------+
| adminurl     | http://:$(admin_port)s/v2.0      |
| id           | 58081185adf94a82994d019043e3ab7e |
| internalurl  | http://:$(public_port)s/v2.0     |
| publicurl    | http://:$(public_port)s/v2.0     |
| region       | RegionOne                        |
| service_id   | 7796b8d0e5ff4267abf3b7766c670fb9 |
| service_name | keystone                         |
| service_type | identity                         |
+--------------+----------------------------------+

V2.0 vs V3 API ports

One of the differences between v2.0 and v3 API, is that in V3 there is no longer any distinction between the admin port (35357) and the public port (5000), so you can use either to manage the keystone service.

If you prefer to use V3 API through the openstackclient CLI, you need to specify the API version and the correct url of the service:

export OS_IDENTITY_API_VERSION=3
export OS_URL=http://aio:35357/v3

Advertisement