Keystone Data Model

Data Model

Keystone was designed from the ground up to be amenable to multiple styles of backends and as such many of the methods and data types will happily accept more data than they know what to do with and pass them on to a backend.

There are a few main data types:

• User: has account credentials, is associated with one or more tenants
• Tenant: unit of ownership in openstack, contains one or more users
• Role: a first-class piece of metadata associated with many user-tenant pairs.
• Token: identifying credential associated with a user or user and tenant
• Extras: bucket of key-value metadata associated with a user-tenant pair.
• Rule: describes a set of requirements for performing an action.

While the general data model allows a many-to-many relationship between Users and Tenants and a many-to-one relationship between Extras and User-Tenant pairs, the actual backend implementations take varying levels of advantage of that functionality.

Keystone Service Backends

Service Backends

Each of the services can configured to use a backend to allow Keystone to fit a variety of environments and needs. The backend for each service is defined in the keystone.conf file with the key driver under a group associated with each service.

A general class under each backend named Driver exists to provide an abstract base class for any implementations, identifying the expected service implementations. The drivers for the services are:

• keystone.identity.core.Driver
• keystone.token.core.Driver

If you implement a backend driver for one of the keystone services, you’re expected to subclass from these classes. The default response for the defined apis in these Drivers is to raise a keystone.service.TokenController.

KVS Backend

A simple backend interface meant to be further backended on anything that can support primary key lookups, the most trivial implementation being an in-memory dict.

Supports all features of the general data model.

SQL Backend

A SQL based backend using SQLAlchemy to store data persistently. The keystone-manage command introspects the backends to identify SQL based backends when running “db_sync” to establish or upgrade schema. If the backend driver has a method db_sync(), it will be invoked to sync and/or migrate schema.

PAM Backend

Extra simple backend that uses the current system’s PAM service to authenticate, providing a one-to-one relationship between Users and Tenants with the root User also having the ‘admin’ role.

Templated Backend

Largely designed for a common use case around service catalogs in the Keystone project, a Catalog backend that simply expands pre-configured templates to provide catalog data.

Example paste.deploy config (uses $ instead of % to avoid ConfigParser’s interpolation):

[DEFAULT]
catalog.RegionOne.identity.publicURL = http://localhost:$(public_port)s/v2.0
catalog.RegionOne.identity.adminURL = http://localhost:$(public_port)s/v2.0
catalog.RegionOne.identity.internalURL = http://localhost:$(public_port)s/v2.0
catalog.RegionOne.identity.name = 'Identity Service'

LDAP Backend

The LDAP backend stored Users and Tenents in separate Subtrees. Roles are recorded as entries under the Tenants.

keystone endpoint系列api

endpoint-create     Create a new endpoint associated with a service
endpoint-delete     Delete a service endpoint
endpoint-get           Find endpoint filtered by a specific attribute or service type
endpoint-list           List configured service endpoints

endpoint-create

keystone endpoint-create [--region <endpoint-region>]  \
                                             --service-id <service-id> \ 
                                             [--publicurl <public-url>] \
                                             [--adminurl <admin-url>] \
                                             [--internalurl <internal-url>]

endpoint-delete

endpoint-get

endpoint-list