Hide Forgot
Title: Adding a Kerberos Principal SSH Key [OSE Admin Guide] Title: Creating a Specific SSH Key Type [OSE User Guide] Title: Kerberos Authentication [OSE Deploy Guide] Describe the issue: 1) The OSE Admin Guide's "Adding a Kerberos Principal SSH Key" section does not provide context regarding OpenShift/Active Directory interoperability or the legwork it would take to be able to use this feature in general. In the absence of a reference architecture, an overview of OpenShift/AD use cases particularly within the context of adding Kerberos SSH keys would be helpful. It also doesn't really need to mention rhc commands since that procedure is for users. https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/2/html-single/Administration_Guide/index.html#Adding_a_Kerberos_Principal_SSH_Key 2) Likewise, the OSE User Guide's "Creating a Specific SSH Key Type" section doesn't need to mention any of the /etc/openshift/broker.conf or /etc/krb5.conf information because that is admin-specific. https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/2/html-single/User_Guide/index.html#Creating_a_Specific_SSH_Key_Type 3) The OSE Deploy Guide's "Kerberos Authentication" section should have the Important box removed as the following is no longer true: "Only user/password authentication is supported at this time. True Kerberos ticket-based authentication will be available with client support of GSSAPI negotiation." https://access.redhat.com/site/documentation/en-US/OpenShift_Enterprise/2/html-single/Deployment_Guide/index.html#Kerberos_Authentication
Created attachment 882758 [details] Mail thread Mark-Brice Folks - just wanted to update the bug. I've added my conversations with Brice. It's up to you to decide whether or not you need the configuration details but I'm including them just in case you do. I've also tried to clarify a few points about Kerberos, Active Directory,e tc. as appropriate. I've included the broker config file (/var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf) and how it would be modified for use with Kerberos (mod_auth_kerb.so) to talk to AD. Please note that this requires the use of a keytab file and I have not configured this with OpenShift and confirmed it in the lab. I have configured keytabs like this in an earlier version (v1.4) of the RHEL-AD Reference Architecture (pgs. 62-64) so it should behave identically. I have configured OpenShift to use keytabs with IdM using this broker config file so in theory there is no reason OpenShift brokers (as RHEL clients) wouldn't work with it. I'll attach v1.4 of the Refrence Architecturte as a folllow up. -m
Created attachment 882760 [details] RHEL-AD Reference Architecture - v1.4 Attaching for reference purposes. Pages 62-64 detail how to configure Kerberos service principal (SPN) on Windows/AD side and then use as a RHEL keytab.
Mark, apologies for the delay on this. I've been distracted and also been trying to get the thumbs up that we're heading in the right direction. I'm currently trying to find a way to test this process for accuracy. I have a few things I can do, but if you have a way you can suggest to me I'd be all ears. B
Brice, The original context was for three separate but somewhat related issues: 1. Adding a Kerberos Principal SSH Key [OSE Admin Guide] 2. Creating a Specific SSH Key Type [OSE User Guide] 3. Kerberos Authentication [OSE Deploy Guide] I don't see 1. above in the Admin Guide link above but I do see 1. and 2. in the User Guide (sectuon 3.2.3.1) so is that the correct context for them? If so, then is the goal to be able to use these against an existing AD environment or just to demonstrate in general how they would be used? Here are a some things to think about - this can impact how you would want to test these out: - SSH keys: These are typically created on a local host then copied to the remote host(s) that you want to access. If you have a lot of remotes hosts then this can be cumbersome. In looking at the text description in the User Guide (section 3.2.2) it appears that the context is basically pretty generic and geared towards RHC clients. AD has nothing to do with this but if you want bring AD into the picture then this is where keytabs come into play and those are configured as I mentioned earlier and as documented in the Reference Architecture. With IdM you can centrally store the keys so that all the IdM domain members have access to the (public part) of the key which eliminates the need to create the key locally and then copy out to all of remote hosts. For each host to be able to use the keys they must be clients of the IdM domain. *** To Test*** - create local key, copy to an OSE broker or node as documented: $ rhc sshkey add KeyName KeyPath - Key Types: As far as SSH key types, this is fairly new and started with the work Mark Lamourine did last year to have a Kerberos Principal be used as an SSH key type. Jordan Liggit on the OSE team handled the back-end OSE portion. To use this, you have to have an existing Kerberos realm in place - this could be provided by AD, IdM or any Kerberos server supporting Kerberos clients and Kerberos Single Sign-On (SSO) capabilities. *** To Test *** - create local key, copy to an OSE broker or node as documented: $ rhc sshkey add KeyName --type KeyType --content KeyContent ...or if a Kerberos realm is in place ... $ rhc sshkey add KeyName --type krb5-principal --content Principal Example: $ rhc sshkey MyKey --type krb5-principal --content user btw - KeyPath is optional (default is $HOME/.k5login - Kerberos Auth: This is already detailed in the included the broker config file (/var/www/openshift/broker/httpd/conf.d/). Keep in mind that this does not have to authenticate to Kerberos on AD, it could be any Kerberos server but obviously you must have Kerberos in place. *** To Test *** Configure openshift-origin-auth-remote-user.conf on broker as per attached thread. Brice - I hope this is more helpful. If you need more clarity let me know. Perhaps we can just set up a time for a phone chat early morning/late evening to accomodate our time zones. -m
Closing this BZ. The focus of the documentation team is going to shift from OpenShift v2 to v3, and only the remaining v2 doc BZs that feature actual errors in the docs will be worked on. If there are any oppositions for any specific BZs, please contact me or the docs team. Specifically, the majority of the work for this BZ has been updated, and released sometime in the past. Links can be found in Comment 3 above.