92 lines
2.9 KiB
ReStructuredText
92 lines
2.9 KiB
ReStructuredText
Keystone *Light*
|
|
================
|
|
|
|
*Always Smooth*
|
|
|
|
Keystone Light is a re-interpretation of the Keystone project that provides
|
|
Identity, Token and Catalog services for use specifically by projects in the
|
|
OpenStack family.
|
|
|
|
|
|
----------
|
|
Data Model
|
|
----------
|
|
|
|
Keystone Light 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
|
|
* **Token**: identifying credential associated with a user or user and tenant
|
|
* **Extras**: bucket of key-values associated with a user-tenant pair, typically used to define roles.
|
|
|
|
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.
|
|
|
|
|
|
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.
|
|
|
|
|
|
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'
|
|
|
|
|
|
---------------
|
|
Keystone Compat
|
|
---------------
|
|
|
|
While Keystone Light takes a fundamentally different approach to its services
|
|
from Keystone, a compatibility layer is included to make switching much easier
|
|
for projects already attempting to use Keystone.
|
|
|
|
The compatibility service is activated by defining an alternate application in
|
|
the paste.deploy config and adding it to your main pipeline::
|
|
|
|
[app:keystone]
|
|
paste.app_factory = keystonelight.keystone_compat:app_factory
|
|
|
|
|
|
-----------
|
|
Still To Do
|
|
-----------
|
|
|
|
* Dev and testing setups would do well with some user/tenant/etc CRUD, for the
|
|
KVS backends at least.
|
|
* Fixture loading functionality would also be killer tests and dev.
|
|
* LDAP backend.
|
|
* Keystone import.
|
|
* Admin-only interface
|