Creating the service tenant and service users
Now that the service endpoints are created, we can configure them so that our other OpenStack services can utilize them. To do this, each service is configured with a username and password within a special service
tenant. Configuring each service to have its own username and password allows for greater security, troubleshooting, and auditing within our environment. When setting up a service to use the OpenStack Identity service for authentication and authorization, we specify these details in their relevant configuration file. Each service itself has to authenticate with keystone
in order for it to be available within OpenStack. Configuration of that service is then done using these credentials. For example, for glance
, we specify the following lines in /etc/glance/glance-registry.conf
, when used with OpenStack Identity service, which matches what we created previously:
[keystone_authtoken] identity_uri = https://192.168.100.200:35357 admin_tenant_name = service admin_user = glance admin_password = glance insecure = True
Tip
The use of insecure = True
here is only required as self-signed certificates are used throughout this book. In production, we would use issued certificates and omit this option in our configs.
Getting ready
We will be using the keystone
client to operate Keystone. If the python-keystoneclient
tool isn't available, follow the steps described at http://bit.ly/OpenStackCookbookClientInstall.
Ensure that we have our environment set correctly to access our OpenStack environment for administrative purposes:
export OS_TENANT_NAME=cookbook export OS_USERNAME=admin export OS_PASSWORD=openstack export OS_AUTH_URL=https://192.168.100.200:5000/v2.0/ export OS_NO_CACHE=1 export OS_KEY=/vagrant/cakey.pem export OS_CACERT=/vagrant/ca.pem
Tip
You can use the controller
node if no other machines are available on your network, as this has the python-keystoneclient
and the relevant access to the OpenStack environment. If you are using the Vagrant environment, issue the following command to get access to the Controller:
vagrant ssh controller
How to do it...
To configure an appropriate service
tenant, carry out the following steps:
- Create the
service
tenant as follows:keystone tenant-create \ --name service \ --description "Service Tenant" \ --enabled true
This produces output similar to what is shown as follows:
+-------------+----------------------------------+ | Property | Value | +-------------+----------------------------------+ | description | Service Tenant | | enabled | True | | id | 8e77d9c13e884bf4809077722003bba0 | | name | service | +-------------+----------------------------------+
- Record the ID of the service tenant so that we can assign service users to this ID:
SERVICE_TENANT_ID=$(keystone tenant-list \ | awk '/\ service\ / {print $2}')
- For each of the services in this section, we will create the user accounts to be named the same as the services and set the password to be the same as the service name too. For example, we will add a user called
nova
with a passwordnova
in theservice
tenant by using the user-create option:keystone user-create \ --name nova \ --pass nova \ --tenant_id $SERVICE_TENANT_ID \ --email nova@localhost \ --enabled true
The preceding code will produce an output similar to what is shown here:
+----------+----------------------------------+ | Property | Value | +----------+----------------------------------+ | email | nova@localhost | | enabled | True | | id | 50ea356a4b6f4cb7a9fa22c1fb08549b | | name | nova | | tenantId | 42e5c284de244e3190e12cc44fbbbe62 | | username | nova | +----------+----------------------------------+
- We then repeat this for each of our other services that will use OpenStack Identity service:
keystone user-create \ --name glance \ --pass glance \ --tenant_id $SERVICE_TENANT_ID \ --email glance@localhost \ --enabled true keystone user-create \ --name keystone \ --pass keystone \ --tenant_id $SERVICE_TENANT_ID \ --email keystone@localhost \ --enabled true keystone user-create \ --name neutron \ --pass neutron \ --tenant_id $SERVICE_TENANT_ID \ --email neutron@localhost \ --enabled true keystone user-create \ --name cinder \ --pass cinder \ --tenant_id $SERVICE_TENANT_ID \ --email cinder@localhost \ --enabled true
- We can now assign these users the
admin
role in theservice
tenant. To do this, we use theuser-role-add
option after retrieving the user ID of thenova
user. For example, to add the admin role to thenova
user in theservice
tenant, we use the following code:# Get the nova user id NOVA_USER_ID=$(keystone user-list \ | awk '/\ nova\ / {print $2}') # Get the admin role id ADMIN_ROLE_ID=$(keystone role-list \ | awk '/\ admin\ / {print $2}') # Assign the nova user the admin role in service tenant keystone user-role-add \ --user $NOVA_USER_ID \ --role $ADMIN_ROLE_ID \ --tenant_id $SERVICE_TENANT_ID
- We then repeat this for our other service users,
glance
,keystone
,neutron
, andcinder
:# Get the glance user id GLANCE_USER_ID=$(keystone user-list \ | awk '/\ glance\ / {print $2}') # Assign the glance user the admin role in service tenant keystone user-role-add \ --user $GLANCE_USER_ID \ --role $ADMIN_ROLE_ID \ --tenant_id $SERVICE_TENANT_ID # Get the keystone user id KEYSTONE_USER_ID=$(keystone user-list \ | awk '/\ keystone\ / {print $2}') # Assign the keystone user the admin role in service tenant keystone user-role-add \ --user $KEYSTONE_USER_ID \ --role $ADMIN_ROLE_ID \ --tenant_id $SERVICE_TENANT_ID # Get the cinder user id NEUTRON_USER_ID=$(keystone user-list \ | awk '/\ neutron \ / {print $2}') # Assign the neutron user the admin role in service tenant keystone user-role-add \ --user $NEUTRON_USER_ID \ --role $ADMIN_ROLE_ID \ --tenant_id $SERVICE_TENANT_ID # Get the cinder user id CINDER_USER_ID=$(keystone user-list \ | awk '/\ cinder \ / {print $2}') # Assign the cinder user the admin role in service tenant keystone user-role-add \ --user $CINDER_USER_ID \ --role $ADMIN_ROLE_ID \ --tenant_id $SERVICE_TENANT_ID
How it works...
Creation of the service
tenant, which is populated with the services required to run OpenStack, is no different from creating any other users on our system that require the admin
role. We create the usernames and passwords and ensure that they exist in the service
tenant with the admin
role assigned to each user. We then use these credentials when configuring the services to authenticate with the OpenStack Identity service.
Tip
Downloading the example code
You can download the example code files for this book at https://github.com/OpenStackCookbook/OpenStackCookbook. All the support files are available here.