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

On Fri, Jul 5, 2013 at 12:17 PM, Clayton Coleman <ccoleman redhat com> wrote:

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

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.

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.

Interesting.  Because I see the above as the simple part, since I don't have to deal with any of the user interaction code.

From the end user standpoint a k5login entry is just a string: username REALM

Right now we distribute the SSH keys  using a broker/node Mcollective message which specifically calls out SSH keys


      def get_add_authorized_ssh_key_job(gear, ssh_key, key_type=nil, comment=nil)
      def get_remove_authorized_ssh_key_job(gear, ssh_key, comment=nil)
      def get_fix_authorized_ssh_keys_job(gear, ssh_keys)
      def self.get_all_gears_sshkeys_impl

I'm still working on how this maps on the node, but what the node side *does* is modify the gear .ssh/authorized_keys file by adding or removing a line.

To implement comparable behavior for Kerberos on the node, you need modify the gear .k5login file (by default), adding or removing an entry: username REALM

For some additional security you can set /etc/krb5.conf/k5login_directory and place the k5login files outside the user work space.

I think this is fairly simple mechanical work.

> 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.

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.

When a user submits a principal for inclusion the broker can validate the principal against the existing usernames in the realm.  It might also just restrict the acceptable principals to those already associated with existing OpenShift users.  Without this check an OpenShift developer could add a principal which is in the realm but may not be authorized for access to the OpenShift service.

> 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).

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?

I need to be careful. When I say "without ssh" I mean "without SSH public key authentication".  All of the communications would still use SSH, but the authentication would be GSSAPI and Kerberos instead of SSH public key. 

I can imagine three settings:

1) SSH public key only
2) Kerberos only
3) EIther SSH key or Kerberos or both (I don't expect anyone will want this, but...)

Each OpenShift user will require a Kerberos principal to access their gears.  This is a comparable using SSH public key now: a user to must have at least one SSH public key to access their gears.

Without fine-grained user management the decision to grant access would still lie with the application owner, but only valid kerberos principals would actually grant access.  A user could put in a random string, but it wouldn't grant access.

> 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 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)

Yes, I thought that advanced user access controls would be more work within the broker/database and REST API.  it's not needed for the initial implementation but I suspect it will be requested soon after.

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

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.

OK, that's good to know.  Since the advanced user controls are already in the works, I'll stick with just the Kerberos logins to the node. That's a fairly constrained problem.  It can be leveraged later as needed.
> - 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

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]