Revision as of 01:13, 22 February 2012

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

BigCo has a shiny new OpenStack cloud deployment, and wants to allow 2 different development teams to access and manage their resources. Each team has two dedicated people, and there are two people that float across both teams. They want to set up all the users and groups into Keystone so that:

• GroupA user A1, A2, Z1, and Z2 can all access and manipulate resources owned by group A
• GroupB user B1, B2, Z1, and Z2 can all access and manipulate resources owned by group B
• Resources in question are volumes, virtual machines, and floating IP addresses

Keystone constructs:

• 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.

User Story: Service Catalog

BigCo wants to provide a service catalog to each of the users listed above with their relevant API endpoints created to match their identity stored in Keystone. For example, the user Jill wants to log into the dashboard using her credentials (stored in keystone), and be able to get the URI endpoints to use in command line or GUI clients.

• 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:

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

User Story: Basic RBAC (role based access controls)

BigCo has an openstack deployment, being used by 2 development teams and managed by a separate operations team. They want to set up the operations team to be able to manipulate all resources within the OpenStack deployment, and limit the development team's users to only manipulating their own volumes and virtual machines. They also want to limit network operations (setting and changing floating IP addresses) to only their operations team.

• 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

User story: Adding users to an OpenStack instance for BigCo

Jill is an administrator for the OpenStack environment at BigCo. She's been asked to bulk load a division of people into a proof of concept/prototype setup (Identity is being backed by DB). In doing so, she has a list of usernames that should all be added, to be broken up into groups of multiple tenants by a later task.

• Allow Jill to upload the list and bulk create users without identifying tenants for those users a priori

User Story: extension to support multiple openstack clusters with a single instance of Keystone

BigCo wants to run two separate OpenStack clusters with a single instance of keystone. BigCo wants to be able to identify these clusters within a single instance of keystone, and make role responses contingent on which cluster is asking - i.e. they have a Dev Cloud and a Prod Cloud. Fredford has "admin" access to Nova in devcloud, but not in ProdCloud.

(This is the HP-IDM-EXTENSION)

JESSE TO ADD ONE IN HERE

we need to add one about adding an experimental/third party service - and supporting it without giving it complete power to do everythign (eg if we send it a user token, they can send it to all the other services and act as the user) [6:44pm] Vanchester joined the chat room. [6:44pm] anotherjesse: (service = new cloud service to the catalog) [6:44pm] heckj: For some of the fundamental changes that were originally planned in essex, there were side-effects that I don't think were clearly communicated to all the other projects (nova, glance, swift, horizon). My goal is to have a basis to do that at the summit, talking in concrete terms [6:45pm] heckj: anotherjesse: can you add that in to the wiki page? [6:45pm] anotherjesse: sure [6:45pm] heckj: or send me an email with the details, and I can pester you until I understand and I'll add it [6:45pm] anotherjesse: it is in the folsom summit topics as "Trust & Service"

See Also

• KeystoneFolsomSummitTopics
• Keystone-Essex-Federated-Token