6.7 KiB
Configuring Services to work with Keystone
nova-api-paste middleware_architecture
Once Keystone is installed and running (see configuration), services need
to be configured to work with it. To do this, we primarily install and
configure middleware for the OpenStack service to handle authentication
tasks or otherwise interact with Keystone.
In general: * Clients making calls to the service will pass in an authentication token. * The Keystone middleware will look for and validate that token, taking the appropriate action. * It will also retrive additional information from the token such as user name, id, tenant name, id, roles, etc...
The middleware will pass those data down to the service as headers.
More details on the architecture of that setup is described in middleware_architecture
Setting up credentials
Admin Token
For a default installation of Keystone, before you can use the REST
API, you need to define an authorization token. This is configured in
keystone.conf file under the section
[DEFAULT]. In the sample file provided with the keystone
project, the line defining this token is
[DEFAULT] admin_token = ADMIN
This configured token is a "shared secret" between keystone and other openstack services (for example: nova, swift, glance, or horizon), and will need to be set the same between those services in order for keystone services to function correctly.
Setting up tenants, users, and roles
You need to minimally define a tenant, user, and role to link the tenant and user as the most basic set of details to get other services authenticating and authorizing with keystone. See doc:configuration for a walk through on how to create tenants, users, and roles.
Setting up services
Defining Services
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.
Here's how we define the services:
keystone-manage service create name=nova service_type=compute description="Nova Compute Service"
keystone-manage service create name=ec2 service_type=ec2 description="EC2 Compatibility Layer"
keystone-manage service create name=glance service_type=image description="Glance Image Service"
keystone-manage service create name=keystone service_type=identity description="Keystone Identity Service"
keystone-manage service create name=swift service_type=object-store description="Swift Service"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.
Setting Up Middleware
Keystone Auth-Token Middleware
The Keystone auth_token middleware is a WSGI component that can be inserted in the WSGI pipeline to handle authenticating tokens with Keystone.
Configuring Nova to use Keystone
To configure Nova to use Keystone for authentication, the Nova API service can be run against the api-paste file provided by Keystone. This is most easily accomplished by setting the --api_paste_config flag in nova.conf to point to examples/paste/nova-api-paste.ini from Keystone. This paste file included references to the WSGI authentication middleware provided with the keystone installation.
When configuring Nova, it is important to create a admin service
token for the service (from the Configuration step above) and include
that as the key 'admin_token' in the nova-api-paste.ini. See the
documented nova-api-paste file for references.
Configuring Swift to use Keystone
Similar to Nova, swift can be configured to use Keystone for authentication rather than it's built in 'tempauth'.
Add a service endpoint for Swift to Keystone
Configure the paste file for swift-proxy (/etc/swift/swift-proxy.conf)
Reconfigure Swift's proxy server to use Keystone instead of TempAuth. Here's an example `/etc/swift/proxy-server.conf`:
[DEFAULT] bind_port = 8888 user = <user> [pipeline:main] pipeline = catch_errors cache keystone proxy-server [app:proxy-server] use = egg:swift#proxy account_autocreate = true [filter:keystone] use = egg:keystone#tokenauth auth_protocol = http auth_host = 127.0.0.1 auth_port = 35357 admin_token = 999888777666 delay_auth_decision = 0 service_protocol = http service_host = 127.0.0.1 service_port = 8100 service_pass = dTpw cache = swift.cache [filter:cache] use = egg:swift#memcache set log_name = cache [filter:catch_errors] use = egg:swift#catch_errors
Note that the optional "cache" property in the keystone filter allows any service (not just Swift) to register its memcache client in the WSGI environment. If such a cache exists, Keystone middleware will utilize it to store validated token information, which could result in better overall performance.
- Restart swift
- Verify that keystone is providing authentication to Swift
Use swift to check everything works (note: you currently have to create a container or upload something as your first action to have the account created; there's a Swift bug to be fixed soon):
$ swift -A http://127.0.0.1:5000/v1.0 -U joeuser -K secrete post container
$ swift -A http://127.0.0.1:5000/v1.0 -U joeuser -K secrete stat -v
StorageURL: http://127.0.0.1:8888/v1/AUTH_1234
Auth Token: 74ce1b05-e839-43b7-bd76-85ef178726c3
Account: AUTH_1234
Containers: 1
Objects: 0
Bytes: 0
Accept-Ranges: bytes
X-Trans-Id: tx25c1a6969d8f4372b63912f411de3c3bWarning
Keystone currently allows any valid token to do anything with any account.