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



A friend at the Consortium just pointed out that this will be
available in 1.12, and links to
http://k5wiki.kerberos.org/wiki/Projects/Local_authentication_pluggable_interface

Sincerely,
-Alex


On Fri, Jul 5, 2013 at 1:13 PM, Mark Lamourine <markllama gmail com> wrote:
>
>
>
> On Fri, Jul 5, 2013 at 1:07 PM, Alex Chernyakhovsky <achernya mit edu>
> wrote:
>>
>> That is true, our current strategy is does subvert krb5's kuserok.
>> We've talked to the Kerberos Consortium about this, and they're
>> working on (perhaps have already released? I need to check) pluggable
>> providers for kuserok(). I think I would propose a version of krb5
>> authentication that checks e.g., an LDAP database managed by
>> openshift, so we then don't have to distribute files to all the gears
>> and worry about synchronization for the users. If the pluggable
>> kuserok() already exists, that seems like the most straightforward
>> solution.
>
>
> Actually, the possiblity of putting the k5login list for each gear into LDAP
> has been discussed.  There's no serious work yet but I suspect I'll end up
> looking at that once the initial integration is done.
>
> - Mark
>
>>
>>
>> Sincerely,
>> -Alex
>>
>> On Fri, Jul 5, 2013 at 1:00 PM, Mark Lamourine <markllama gmail com>
>> wrote:
>> > 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
>
>
>
>
> --
> ----
> 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]