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.> 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,
> 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
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 questions1) is this tied to an Openshift user account
2) do you support multiple principals per user
3) is the principal discoverable automatically / an implicit property of the user,
or a choice the user always has to make
4) are there potentially different ways to treat the same principal on each gear across different customer deployments (krb5login file vs. ???)
5) are there "keys" aside from principals that will also be potentially settable on each user.
6) is the distribution mechanism to the nodes identical (vs how they are used on the nodes)
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.Is that a remote call to the realm? How expensive is it?
> 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
> 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.
I'd have to look it up. I'm still working on concept.> It might also justWithout an index on the principals in mongo, this operation won't scale.
> restrict the acceptable principals to those already associated with
> existing OpenShift users.
Would it be terrible to index the user information?> Without this check an OpenShift developer couldAren'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.
> add a principal which is in the realm but may not be authorized for access
> to the OpenShift service.
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