[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?


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.


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

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