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



Alex: that's actually a very different problem to the one I'm trying to solve, really.

We have people who object to the fact that an OpenShift user can add an SSH public key which will grant access for an unknown person to the contents of all of the registered user's applications and gears.  They want to be able to restrict access to only users who have valid individual K5 principals.  Ideally they will want to log individual access so that it can be traced back in the event of a compromise.

You're talking about something different.  You want to grant access to members of a group by subverting the logins by individual principals.

If I understand correctly, your users present their own principal which is authenticated, and then checked (using your own version of kuserok() ) for membership in an AFS group.

What you're talking about isn't even an OpenShift auth mechanism so much as replacing part of the standard krb5 auth mechanisms.

If that suits your purposes, that's fine but generally OpenShift uses standard mechanisms for everything it can. I'll have to think about standard ways to grant login access to authenticated members of a group.

- Mark


On Fri, Jul 5, 2013 at 12:47 PM, Alex Chernyakhovsky <achernya mit edu> wrote:
Basically. We create a unix user for each shared account, and patch
the kuserok() function to call our own program that handles
authorization. It's morally equivalent to adding the individual
principals of all the group members to the k5login, except it's
automatically updated when the group membership database changes.
That's the primary reason I'm advocating for something pluggable,
because we don't get push notifications of such changes.

Sincerely,
-Alex

On Fri, Jul 5, 2013 at 12:30 PM, Clayton Coleman <ccoleman redhat com> wrote:
> 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
>>

_______________________________________________
dev mailing list
dev lists openshift redhat com
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev



--
----
Mark Lamourine <markllama gmail com>
Dad, Hubbie, Software Developer, System Administrator, Road Cyclist

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