Keystone Use Cases

This is tracking use cases to drive future development of Keystone API and implementations.

User Story: Basic separation of individual from owned resources

Separation of individuals from ownership of resources such that an individual can interact with resources owned by "separate" groupings.
- In V2, the key constructs there are Users, Tenants, and Roles to link the two.
- Tokens are authenticated by user credentials through Keystone, and include metadata that is shared with the service to make permission choices.
Expose service APIs for a given user
- (i.e. craft Swift and related API endpoints for a specific user/tenant) - Swift API endpoints have tenant & userid in the URI (others too?)

Two Open Questions:

Is there a use case around supporting a user without a tenant?
Is there a use case around having a tenant without any users?

User Story: Basic RBAC (role based access controls)

Enable role based access
- (see http://etherpad.openstack.org/canhaz for discussion)
- ROLE - A group that a user can be in, which gives them privileges - combination of user+tenant from identity above
- ACTION - Doing something - this is specific to a service
- CAPABILITY - An action that's been granted to a role (role+action)
- for an example set of actions wrapped into a policy set, see https://github.com/openstack/nova/blob/master/etc/nova/policy.json

User Story: Private Cloud + RAX Cloud Files

BigCo needs a global private cloud. Instead of deploying multi-region cloud files, they would prefer to use Rackspace Cloud Files. Their cloud has shared authentication with their existing enterprise systems (Keystone backends to AD - see stories below). They want to add to their cloud's service catalog an entry for rackspace cloud files and use their existing authentication.

(In the stories "windows" means a windows desktop with central AD authentication)

User story: Windows + Dashboard / API

Jill arrives at work and logs into his desktop with his corporate username/password, and sees an email that the private cloud is now available. She clicks the link and it takes him to a sign-on page. She enters his corporate username/password and it lets him in. After exploring the features, she is ready to start using the cloud.

User story: Windows + Virtual Machine

Jill decides to launch a Windows VM. After a few minutes later she clicks "Open Remote Desktop" and her RDP viewer opens the windows desktop. She is able to use her corporate username/password to login to the virtual machine and access all corporate resources.

Technical Assumptions:

cloud management layer and VMs have access to corporate AD/LDAP
corporation has an existing AD/LDAP that will need to be integrated
cloud & VMs only need (minimal) read access to LDAP/AD
- check if the username/password is correct
- list all tenants for a user (groups the user is a member of)
- list all roles for the user/tenant (for cloud permissions)

Phase A: LDAP Identity Backend

1) LDAP Simple

document how to setup a cloud so that keystone and linux VMs use a shared LDAP
any LDAP user is able to login to VM (independent of tenant that created it)

2) LDAP Tenant

linux guest agent pulls tenant information from metadata
only users in that tenant (group in LDAP) can login to the server

3) LDAP Tenant + Cloud Operator

cloud operator can configure an addition LDAP group that is allowed admin access
additional group is exposed via metadata, guest agent adds admin group

4) LDAP Simple + Windows

windows image setup to authenticate against LDAP (same as 1 except windows guest)

5) LDAP Tenant + Windows

similar to 2 except with Windows Image

Phase B: AD Backend

1) AD Simple

active directory backend for Keystone (light)
windows image that is hardcoded to use the AD

2) AD join Domain

in addition to authentication against an AD, register against the AD

3) AD Tenant

in addition to registering against the AD, restrict access to only those users who a member of the tenant (similar to A.2 but with AD+Windows)

4) AD Tenant + Cloud Operator

in additional to B.3, an admin tenant is added (similar to A.3)

5) AD Tenant + Cloud Operator + Linux

similar to 4 except linux image that delegates to AD

KeystoneUseCases