2c) Principals would need to be distributed to applications when changed - this is easily the most complex part of the process. Looking at the model, the broker assumes that ssh keys are all the same, and the node accepts the (name, type, value) tuple via an event. If we instead modelled the k5login as a different type of key, and then made the broker terminology more generic to match (instead of add_ssh_key, becomes add_user_key, etc), then the changes would be much reduced.
----- Original Message -----
> 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
The big question is - is the effect of a user adding a "krb5login" type key to their account EXACTLY the same as adding an SSH public key - i.e., are the same expectations from the user persective in place.
If you can do this, you need only minor changes below.
How and where would they control this? Can you describe what sort of control is needed, and how OpenShift could figure that out? I don't see a difference between this and key type validation.
> 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.
Does each OpenShift user have a single krb5login? Typically it's the application owner's responsibility to make the correct decision about who has access to an app at the SSH level. How would service/machine accounts access an app via SSH?
> 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).
This is covered in a different epic and is outside the scope of this work for sure. However, anything done for this epic should attempt to cleanly delinate the responsibility between REST API access to an account (covered by the broker model) and SSH access to a gear (covered by SSH public keys today, + krb logins)
> 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.
The second case will have its own pep, this one needs more clarification on the control topic above, then a short writeup. I don't think it needs a PEP, as long as you can adequately constrain the scope of the changes to match an existing model. If we're adding a new conceptual resource (logins) in parallel to ssh keys, I think there needs to be a strong justification.
> 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
> dev mailing list
> dev lists openshift redhat com
dev mailing list
dev lists openshift redhat com