Latest revision as of 23:30, 17 February 2013

Keystone Folsom Summit Topics

What we're doing with Middleware - does it reside in Keystone, each project, etc.

• 12:16 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com ) ]hello sir, some things have been landing in middleware in the keystone project lately, especially for glance - will these changes have to be re-done as ksl lands?
• 12:55 [freenode] [msg(westmaas)] not if you do them in th ksl project ;) port the changes you want over right now in http://github.com/termie/keystonelight
• 12:56 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] is middleware going to move out of ksl?
• 12:57 [freenode] [msg(westmaas)] probably at some point, but when they do they will be copied out of the ksl project, (i expect)
• 12:58 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] kk
• 12:58 [freenode] [msg(westmaas)] we haven't committed to doing them all yet
• 12:58 [freenode] [msg(westmaas)] though i think nova is currently already doing it
• 12:58 [freenode] [(westmaas ~ westmaas@184-106-186-202.static.cloud-ips.com )] yeah it is
• 13:01 [freenode] [msg(westmaas)] just talked it over with vish, we have a pretty decent plan for what to do with the middleware, actuals
• 13:02 [freenode] [msg(westmaas)] thoughts are thin: we put some base-class for middleware into keystoneclient that can be subclassed wby the project middleware, and then the project middlewares do specific stuff
• 13:04 [freenode] [msg(westmaas)] this will allow us a little bit of flexibility if something small changes or we want to add some default behaviors

How to allow for/enable multifactor authentication -

• pluggable backend for multiple authN sources (ex: mobile authN from verisign but SMS done through Telesign) -
• Potential out-of-box integration with WikiD - an opensrouce MFA provider-
• allowing MFA for different tenants/users. Ex: Access to tenant A requires 3 authN but tenant B requires 2. User Jane requires 3 authN but user test_service requires 1.

Catalog crud

• right now, catalog is template/config file based in keystone/redux - catalogs are handed back with a user once authenticated, because the tenantID is embedded into URI for some of the services (SWIFT, I'm looking at you) - there's also some use cases related to wanting to hide endpoints from some users - i.e. if you're not an admin, don't return the admin endpoints.Endpoints in general need to have a general discussion from the point of view of use cases, then re-examine the API to figure out how to support it.

Federation

• Huge topic - means lots of things to lots of people. We need get a sense of what the needs are from the community, and then wrangle this down into something where we can prototype and start small - getting something done in the folsom timeframe for expansion as we drive the project forward.

Trust & Service

• the trust zone of an openstack cloud is currently all services receive a token that can use it against other services. It would be preferable to add services without requiring they receive a re-usable token.

Default tenant

• DO we even allow a user to be created without a tenant - and if so, how do we handle the "free floating user" issue when that case does occur (assuming they're separate entities on some backend systems)currently nova EC2 keys are handed out to a user - not a user-tenant pair, so they are theoretically usable by a user regardless of the tenant owning the VM that the user is accessing/messin' with

RBAC

• Are the essex requirements for RBAC still the same? Did anything change? We didn't deliver this in Essex, so it's even more needed for Folsom

PKI

• Certain deployment environments require PKI. How can Keystone accommodate (or generally move towards accommodating) this?

Service relationships

• A volume service may be associated with an explicit compute service. There is no way to explicitly indicate this relationship via the service catalog today. Type and names can be duplicated according to the contract and expanding a URL type for a relationship seems like over-kill. There needs to be a collection or grouping of services to indicate which ones play well with each other.