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

Re: Kerberos 5 authentication for gear access (ssh and ssh+git) - Should this get a PEP?



So you need the group information transferred to the gears to be associated with the unix user?

----- Original Message -----
> Hi,
> 
> I'm one of the people working on a prototype deployment of OpenShift
> at MIT, and we'd be very interested in kerberos authentication to the
> gears. We currently have an interesting model where our non-openshift
> webservers actually don't look at k5logins, but instead look at a
> membership list of principals to authenticate users to group
> resources. It so happens that this membership list is an AFS group,
> but that's not strictly relevant in this case. I would like to
> encourage a design that allows easily managing group-shared resources
> if possible. Automatically managed k5logins would likely be adequate,
> but I'd hope we could come up with something a bit more pluggable.
> Unlike an SSH key, which can be shared amongst users, a kerberos
> principal really isn't sharable.
> 
> Sincerely,
> -Alex
> 
> 
> On Fri, Jul 5, 2013 at 12:06 PM, Mark Lamourine <markllama redhat com> wrote:
> > I'm starting to look at what it would take to allow the use of Kerberos
> > authentication for application developer access to gears (ssh and git).
> > Currently this access control is provided by SSH public key.
> >
> >
> > Here's a list of the areas that I think will need changes to make it work:
> >
> > 1) node:
> > 1a) accept message to place/remove k5login values for node/gear
> > 1b) selinux policy rules to allow the node agent to manage k5login entries
> >
> > 2) broker:
> > 2a) generate message to place/remote k5login values for node/gear
> > 2b) associate kerberos principals with OpenShift user
> >
> > 3) console: manage kerberos principals for OpenShift User
> >
> > 4) cli (rhc): manage kerberos principals for OpenShift User
> >
> > For any of this to work the broker, nodes and client hosts would all be
> > required to participate in a common Kerberos Realm.
> >
> > The idea is to use the
> >
> > Note that currently SSH keys are associated with an OpenShift user.  Each
> > OpenShift user may have any number of SSH keys.  All of the user's SSH
> > keys are pushed to all gears owned by that user whenever the user changes
> > the key set (add/remove).  Usually this means that the registered
> > OpenShift user has granted access by some other unknown user to all of
> > their gears.
> >
> > This may be acceptable as a first step but I suspect that service
> > implementers who want Kerberos will also want to control which Kerberos
> > principals can be added. THey will want to be able to validate the
> > principals as they are added and restrict them to known existing values
> > (ie, registered OpenShift users).  They will also want to be able to grant
> > access at a finer grain than "give use A access to all of user B's apps
> > and gears".
> >
> > This will require the addition of more nuanced user management in the
> > database, the broker, console and in the rhc CLI commands.
> >
> > This second case can be handled separately from the initial work, I think.
> >
> > Given the scope of the changes, does the warrant a formal PEP (or two) for
> > design of the behavior and implementation?
> >
> > - Mark
> >
> > --
> > Mark Lamourine <markllama redhat com>
> > Sr. Software Developer, Cloud Engineering
> > Red Hat, 314 Littleton Road, Westford MA 01886
> > Voice: +1 978 392 1093
> > http://people.redhat.com/~mlamouri
> > markllama @ irc://irc.freenod.org*lopsa
> >
> > _______________________________________________
> > dev mailing list
> > dev lists openshift redhat com
> > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 
> _______________________________________________
> dev mailing list
> dev lists openshift redhat com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
> 


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