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

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

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
markllama @ irc://irc.freenod.org*lopsa

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