[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 1:21 PM, Clayton Coleman <ccoleman redhat com> wrote:


On Jul 5, 2013, at 1:11 PM, Mark Lamourine <markllama gmail com> wrote:




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


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


SNIP
 
> 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
>
> origin-server/plugins/msg-broker/mcollective/lib/openshift/mcollective_application_container_proxy.rb
>
>       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

The set of operations to make this all work correctly, transactionally, and completely (and have ops be able to fix it up if something goes wrong) is not something I would want to just duplicate by copy/paste.  Instead, the question that has to be answered in order to justify the duplication is "why are krb5logins per user DIFFERENT than an SSH key"?  I'm already slogging through group and team membership propagation, which needs to ensure all of this is updated correctly for sets of users.  If in the future we decide to simplify the propagation of key changes (for instance, to track a user/key version flag and then only propagate the version # of a user's key state down to the node, then have the node fetch the user's current keys) then I don't want to have two parallel code paths that are subtly different.

Well first is that they have to be treated differently on the node.  Other than that, they're just strings of a different type.  If the database can distinguish user strings for SSH public key and k5login by setting a new type value, then they *aren't* different.

They will need user interface additions to the console and CLI so that users aren't confused "paste ssh key here vs type k5 principal here" but logically everywhere else but on the node they would be the same.

On the node they *must* be treated differently if only because the SSHD and pam_krb5/sssd expect the values to be in different places and to have different formats which would conflict in horrible ways if they were mashed together.

Yes - that's either a new set of mcollective endpoints, or a type based plugin to the node to handle key propagation in two ways, ssh public key vs. principal.

Another potential wrinkle is that the user's default principal should be provisioned on user creation.  It's possible but not clean today. 

Ultimately the modeling decisions revolve around the following questions

1) is this tied to an Openshift user account

Yes
 
2) do you support multiple principals per user

Initially yes (because they're the same as SSH keys and we don't have fine-grained user controls or validation)
 
3) is the principal discoverable automatically / an implicit property of the user,

I think this depends on context. When a value is initially presented to the OpenShift broker either for user creation or the addition of
a principal to an existing user account, the human user must know the name of the principal to be added.

When the human user who is associated with a principal tries to access a gear they must run kinit to get their initial ticket for login sessions.  From there SSH (properly configured to use GSSAPI to OpenShift node/gears) will authenticate without a password on each login attempt until the user's kerberos ticket expires or is revoked.
 
or a choice the user always has to make

Unless the registration web site for the OpenShift installation is also kerberized, the user, on registration, will have to present their principal (username REALM, or possibly username[ REALM] if only one realm exists).  When adding a new principal to an OpenShift user, they will have to present the principal string.
 
4) are there potentially different ways to treat the same principal on each gear across different customer deployments (krb5login file vs. ???)

Each login mechanism for a gear is distinct, and they are controlled by PAM and sssd.

If there are multiple OpenShift installations in an organization and bound to a single Kerberos realm, then it would be possible (without entry time validation or login time group membership checks) for any user with a valid principal in the realm to be added to any existing OpenShift services bound to the realm and they would be granted access.

 
5) are there "keys" aside from principals that will also be potentially settable on each user.

Currently only SSH public key and Kerberos that I am aware of.  Linking the node authentication to something like OAuth and/or LDAP might allow additional authentication mechanisms but they would not necessarily require changes on the node itself when a user authentication changes.  For these, the node would be configured to check the remote service for access requests and the remote service would respond based on the credentials presented.

Eventually it should be possible to place the k5login information for each gear into an LDAP database so that pushing files around to nodes will no longer be needed. On the other hand, it makes the LDAP database service a point of failure distinct from the nodes (though SSSD can do caching of both Krb5 and LDAP information if requested).

 
6) is the distribution mechanism to the nodes identical (vs how they are used on the nodes)

That remains to be seen, though right now I see no conceptual difference between SSH keys and k5login principals.  They're both sets of strings associated with a node/gear and provided from user information on the broker. 


Given the answers above, the decision about whether ssh_key in the broker is currently not generic enough (the root object should be a key for use with ssh) can be answered.

 

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

Is that a remote call to the realm?  How expensive is it?

I'd have to look it up.  I'm still working on concept.
 
> It might also just
> restrict the acceptable principals to those already associated with
> existing OpenShift users.

Without an index on the principals in mongo, this operation won't scale.


Would it be terrible to index the user information?
 
> 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.

Aren't there scenarios where a customer has an automated service machine that has no knowledge of openshift, but maintains all production systems?  That service machine principal wouldn't have anything to do with openshift - just with the gears.


Exactly.  It would be impossible (without some validation) to prevent an authorized OpenShift user from granting gear access to a user who might have a company approved principal but who is not authorized (by policy) to access OpenShift gears.

Since the goal is to give an organization better control of gear access, this would eventually have to be fixed. 
 
>
>
> >
> > > 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
> > 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



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