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:

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)

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: Adding users to an OpenStack instance from BigCo's directory

Jill is an administrator for an OpenStack environment at BigCo. She's been asked to enable Dept A, B, C, and D for the OpenStack environment. All the members of Division X can be determined by an LDAP query against BigCo's directory containing a list of departments. All members of will need to log in with their corporate credentials. Jill doesn't have any update authority to the corporate directory.

Allow Jill to specify allowed users by some form of directory query
Allow users to login with directory credentials, but assume that the directory is not updatable in any way from OpenStack (all additional metadata that needs to be stored, much be done in a seperate OpenStack store).

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 could also be viewed as different roles in different service endpoints on Keystone - so Fredford has "admin" access to Nova in devloud, but "just a regular guy" access to the production Glance instance.

(This is part of what is intended with the HP-IDM-EXTENSION)

User Story: Allow groups of permissions to be assigned across sets of tenants

BigCo has a large installation of OpenStack with multiple clusters of Nova, and potentially a single instance of Keystone. Various departments in BigCo are tenants, and a few people provide administrative assistance for the Cloud services to those departments. BigCo wants to be able to assign permissions to sets of those departments so that a single user or group of users (Mark, Jill, and Aspen, for example) can provide administration across several tenants(endpoints and groups of resources), without having to be assigned to every tenant and given a role associated with each Tenant.

(This is part of what is intended with the HP-IDM-EXTENSION)

User Story: service acting on behalf of a user to another service

(vishy) here is the problem I'm trying to solve:

As an admin, I want to trigger a resize for a user (within Nova) or a block-migration command. At some point that command has to interact with external services, in this case glance. So if i need to access that tenant's images, I need a token that is valid for that tenant. (currently logged as https://bugs.launchpad.net/keystone/+bug/949467)

User Story: Multi-factor authentication

BigCo has a big OpenStack private cloud. BigCo has an R&D division with resources in a separate tenant from other BigCo resources. To gain access to BigCo R&D resources, an employee needs to provide more than just one set of credentials.R&D employees that only supply 1 set of credentials can still access BigCo non-R&D resources. The additional sets of credentials needed to access R&D resources could involve a hardware token, push-notification approval, SMS texts with pins, or even voice approval.

As an enterprise using OpenStack, I would expect Keystone support the notion of a half-token - a token that isn't fully authenticated but could still allow access to some services/resources that only require the credentials I supplied.

User story: Role based endpoint URLs filtering

BigCo doesn't want “internal” and “admin” endpoints URLs are publicly available, thus BigCo needs filtering the URL endpoints depending on the user role. e.g.: userA as member of tenantA will get just the public endpoints URL, userB as service admin of tenantB will get all the endpoints URLs.

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"

KeystoneUseCases

Contents