To configure the OpenStack services with service users, we need to create a tenant for all the services, and then users for each of the services. We then assign those service users an Admin role on the service tenant. This allows them to validate tokens - and authenticate and authorize other user requests.
Create a tenant for the services, typically named 'service' (however, the name can be whatever you choose):
keystone tenant-create --name=service
This returns a UUID of the tenant - keep that, you'll need it when creating the users and specifying the roles.
Create service users for nova, glance, swift, and quantum (or whatever subset is relevant to your deployment):
keystone user-create --name=nova \
--pass=Sekr3tPass \
--tenant_id=[the uuid of the tenant] \
[email protected]
Repeat this for each service you want to enable. Email is a required field in keystone right now, but not used in relation to the service accounts. Each of these commands will also return a UUID of the user. Keep those to assign the Admin role.
For adding the Admin role to the service accounts, you'll need to know the UUID of the role you want to add. If you don't have them handy, you can look it up quickly with:
keystone role-list
Once you have it, assign the service users to the Admin role. This is all assuming that you've already created the basic roles and settings as described in the configuration section:
keystone user-role-add --tenant_id=[uuid of the service tenant] \
--user=[uuid of the service account] \
--role=[uuid of the Admin role]
Keystone also acts as a service catalog to let other OpenStack systems know where relevant API endpoints exist for OpenStack Services. The OpenStack Dashboard, in particular, uses this heavily - and this must be configured for the OpenStack Dashboard to properly function.
The endpoints for these services are defined in a
template, an example of which is in the project as the file
etc/default_catalog.templates. When
keystone uses a template file backend, then changes made to
the endpoints are kept in memory and don't persist if you
restart the service or reboot the machine. Use the SQL
backend when deploying a system for production.
Keystone supports two means of defining the services, one is the catalog template, as described above - in which case everything is detailed in that template.
The other is a SQL backend for the catalog service, in which case after keystone is online, you need to add the services to the catalog:
keystone service-create --name=nova \
--type=compute \
--description="Nova Compute Service"
keystone service-create --name=ec2 \
--type=ec2 \
--description="EC2 Compatibility Layer"
keystone service-create --name=glance \
--type=image \
--description="Glance Image Service"
keystone service-create --name=keystone \
--type=identity \
--description="Keystone Identity Service"
keystone service-create --name=swift \
--type=object-store \
--description="Swift Service"
