Difference between revisions of "KeystoneUseCases"
| Line 2: | Line 2: | ||
= Keystone Use Cases = | = 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 | ||
| + | |||
| + | = See Also = | ||
| + | * [[KeystoneFolsomSummitTopics]] | ||
| + | * Keystone-Essex-Federated-Token | ||
Revision as of 18:50, 17 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
- 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
See Also
- KeystoneFolsomSummitTopics
- Keystone-Essex-Federated-Token
