glance/doc/source/authentication.rst

Glance Authentication With Keystone

Glance may optionally be integrated with Keystone. Setting this up is relatively straightforward, as the Keystone distribution includes the necessary middleware. Once you have installed Keystone and edited your configuration files, newly created images will have their owner attribute set to the tenant of the authenticated users, and the is_public attribute will cause access to those images for which it is false to be restricted to only the owner.

Note

The exception is those images for which owner is set to null, which may only be done by those users having the Admin role. These images may still be accessed by the public, but will not appear in the list of public images. This allows the Glance Registry owner to publish images for beta testing without allowing those images to show up in lists, potentially confusing users.

Configuring the Glance servers to use Keystone

Keystone is integrated with Glance through the use of middleware. The default configuration files for both the Glance API and the Glance Registry use a single piece of middleware called unauthenticated-context, which generates a request context containing blank authentication information. In order to configure Glance to use Keystone, the authtoken and context middlewares must be deployed in place of the unauthenticated-context middleware. The authtoken middleware performs the authentication token validation and retrieves actual user authentication information. It can be found in the Keystone distribution.

Configuring Glance API to use Keystone

Configuring Glance API to use Keystone is relatively straight forward. The first step is to ensure that declarations for the two pieces of middleware exist in the glance-api-paste.ini. Here is an example for authtoken:

[filter:authtoken]
paste.filter_factory = keystone.middleware.auth_token:filter_factory
auth_host = 127.0.0.1
auth_port = 35357
auth_protocol = http
admin_user = glance_admin
admin_tenant_name = service_admins
admin_password = password1234

The actual values for these variables will need to be set depending on your situation. For more information, please refer to the Keystone documentation on the auth_token middleware, but in short:

• Those variables beginning with auth_ point to the Keystone Admin service. This information is used by the middleware to actually query Keystone about the validity of the authentication tokens.
• The admin auth credentials (admin_user, admin_tenant_name, admin_password) will be used to retrieve an admin token. That token will be used to authorize user tokens behind the scenes.

Finally, to actually enable using Keystone authentication, the application pipeline must be modified. By default, it looks like:

[pipeline:glance-api]
pipeline = versionnegotiation unauthenticated-context apiv1app

Your particular pipeline may vary depending on other options, such as the image cache. This must be changed by replacing unauthenticated-context with authtoken and context:

[pipeline:glance-api]
pipeline = versionnegotiation authtoken context apiv1app

Configuring Glance Registry to use Keystone

Configuring Glance Registry to use Keystone is also relatively straight forward. The same middleware needs to be added to glance-registry-paste.ini as was needed by Glance API; see above for an example of the authtoken configuration.

Again, to enable using Keystone authentication, the appropriate application pipeline must be selected. By default, it looks like:

[pipeline:glance-registry-keystone]
pipeline = authtoken context registryapp

To enable the above application pipeline, in your main glance-registry.conf configuration file, select the appropriate deployment flavor by adding a flavor attribute in the paste_deploy group:

[paste_deploy]
flavor = keystone

Note

If your authentication service uses a role other than admin to identify which users should be granted admin-level privileges, you must define it in the admin_role config attribute in both glance-registry.conf and glance-api.conf.

Sharing Images With Others

It is possible to allow a private image to be shared with one or more alternate tenants. This is done through image memberships, which are available via the members resource of images. (For more details, see glanceapi.) Essentially, a membership is an association between an image and a tenant which has permission to access that image. These membership associations may also have a can_share attribute, which, if set to true, delegates the authority to share an image to the named tenant.

Configuring the Glance Client to use Keystone

Once the Glance API and Registry servers have been configured to use Keystone, you will need to configure the Glance client (bin/glance) to use Keystone as well. Like the other OpenStack projects, this is done through a common set of environment variables. These credentials may may alternatively be specified using the following switches to the bin/glance command:

OS_USERNAME=<USERNAME>, -I <USERNAME>, --os_username=<USERNAME>

User name used to acquire an authentication token

OS_PASSWORD=<PASSWORD>, -K <PASSWORD>, --os_password=<PASSWORD>

Password used to acquire an authentication token

OS_TENANT_NAME=<TENANT_NAME> -T <TENANT_NAME>, --os_tenant_name=<TENANT_NAME>

Tenant name

OS_AUTH_URL=<AUTH_URL>, -N <AUTH_URL>, --os_auth_url=<AUTH_URL>

Authentication endpoint

OS_REGION_NAME=<REGION_NAME>, -R <REGION_NAME>, --os_region_name=<REGION_NAME>

Used to select a specific region while authenticating against Keystone

Or, if a pre-authenticated token is preferred, the following option allows the client-side interaction with keystone to be bypassed (useful if a long sequence of commands is being scripted):

OS_TOKEN=<TOKEN>, -A <TOKEN>, --os_auth_token=<TOKEN>

User's authentication token that identifies the client to the glance server. This is not an admin token.

In general the command line switch takes precedence over the corresponding OS* environment variable, if both are set.