[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

RE: Direction on authentication, groups, and authorization in OpenShift

If you are almost done, then yeah, I totally understand where you are coming from. I didn't know you were that close. I was more suggesting not to have to implement new stuff yourselves. Longer term it still maybe be beneficial to share code though.

I am not a developer on Keystone, so I don't know everything about it. I've been working on my own project that I implemented something similar to keystone for, but am finding more and more features in keystone that make me want to ditch what I wrote and just use keystone. So I have been paying somewhat close attention to it. PKI scaling is one big one. Once it has delegations and scope restricting it will be so far out ahead that it will be way to much effort to implement myself and will be much easier just replace everything with Keystone.

I'm not sure where keystone stands on their plans for when those new features would be added. I just know someone posted that to the mailing list and mentioned some of the features were already done. Digging through their blueprint tracker might show where they are at better.

For the roll notification stuff, I don't think they have any events, but I could be wrong. I am pretty sure they support getting them from LDAP though and support assigning directly through LDAP which would make that feature difficult. Is it really that bad if synchronization is slightly delayed in that case? Yeah, having a manual trigger to force the event would be slightly annoying but if it means other systems could automatically update LDAP and unless you needed it right away, things would just work (TM) it may be worth the tradeoff.

I'm not sure exactly what role defining at which levels they support currently. At least long term, I think of Swift Containers being a similar thing to OpenShift Apps:
User -> Tenant -> Swift Container X
User -> Tenant/Domain -> OpenShift App Y

If they don't have permissions/delegations down to that level currently, they will need them eventually.

Anyway, it sounds like you have a good handle on all of this stuff. Its been a very interesting discussion.

From: Clayton Coleman [ccoleman redhat com]
Sent: Wednesday, July 24, 2013 1:19 PM
To: Fox, Kevin M
Cc: Openshift Dev
Subject: Re: Direction on authentication, groups, and authorization in OpenShift

----- Original Message -----
> The Keystone guys are committed to making it scale to the same magnitude
> OpenShift needs. Rackspace is running it today on a huge cloud. So getting
> it to scale shouldn't be an issue. :)
> You are right about delegation and limiting scope. They are working on it now
> though:
> http://adam.younglogic.com/2013/07/a-vision-for-keystone/
> Getting those remaining bits into keystone will be easier then writing the
> whole thing from scratch though.

The only bits left for us to implement at this point are the final details of permissions, as well as the user experience around membership management.  Everything else has already been implemented previously, or is already in final rev code.  That said, things that we *don't* really want to implement are complex LDAP synchronization (unless it proves required for token propagation to managed resources) or a full OAuth stack.  What's the timeframe for the RBAC work and scopes?

> I see what you are saying about getting a list of all apps a user has access
> too. But that is going to be a very hard to scale query one way or another.
> If you get a DB or something to help you do the query, then you just run
> into a hard to scale DB.

We've tested the DB queries for membership at millions of records and tens of millions of memberships, and we were still in the sub 3ms query range.  It's not a terribly difficult problem once the membership is materialized because we're going direct to a very simple mongoid in-memory index - the bulk of the work there is when you have to keep membership in sync between two systems.  For OpenShift, we expect lists of memberships to be in the hundreds, so that's a tractable problem.

> I think the OpenStack guys just side step the issue
> by having you select a tenant first before listing everything related to the
> tenant. This allows you to scale out servers by sharding across tenants. As
> a user, I don't really mind having to select a tenant first.

Maybe I'm missing how tenants are subdivided - given the concepts on the keystone documentation I was mapping a single tenant to a single domain or application, and users would be members of each tenant they have access to.  Is that not the resource mapping that keystone expects?  If not, what's the intermediate concept for resource (or is it part of the role definition)?

> It really sounds like to me that that two projects have very similar and
> complementary requirements/end goals here.

I think the discussion has certainly shown that the mapping is pretty close.  I think we'd like to boot this up in the next sprint or two within our model, but given the parallels having the checks and mappings be easily abstractable to a keystone underlying domain model makes sense, and is something we can look at over the course of the fall.

One more thought - OpenShift needs to know when membership in a resource changes in order to propagate security tokens to the various containers under its control.  Does Keystone offer an event stream for changes to tenants that can be subscribed to?  If not, then all interactions have to be through the OpenShift API and the underlying tenant has to be off limits for admin manipulation (although we could expose key propagation as a user/admin action if necessary to recover in those cases).  That's a fairly annoying mapping problem as well.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]