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

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

----- Original Message -----
> 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'll take a todo to follow up with the right folks in Keystone.  There's definitely some scenarios where that's important to the user experience (user gets access to an app and wants to git clone immediately), vs where it isn't (300 people get added to an LDAP group who have never looked at OpenShift).

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

It has - thanks for the feedback and helping raise the awareness (I now know a lot more about Keystone :)). I'm going to flush out the synopsis of this discussion in an OpenStack specific section for further work, and I'll make sure this is high on our radar.

> Thanks,
> Kevin
> ________________________________________
> 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]