Bug 1314526
| Summary: | [RFE] x509 cli authentication | ||
|---|---|---|---|
| Product: | OpenShift Container Platform | Reporter: | Eric Jones <erjones> |
| Component: | RFE | Assignee: | Eric Paris <eparis> |
| Status: | CLOSED WONTFIX | QA Contact: | Chuan Yu <chuyu> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.1.0 | CC: | aos-bugs, awestbro, bbeaudoi, cshereme, degts, erich, erjones, jokerman, jpullen, mbarrett, mjahangi, mmccomas, mrogers, pep, snalawad, ssorce, tbiggs |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: |
OpenShift Enterprise 3.x
|
|
| Last Closed: | 2019-06-12 11:58:16 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
(In reply to Eric Jones from comment #0) > - What is the nature and description of the request? > Customer is looking for the ability to use passwordless > authentication means, like x509 certificates and underlying keys, with the > "oc" command to get a token. This is already possible, no? https://docs.openshift.com/enterprise/3.1/architecture/additional_concepts/authentication.html#api-authentication Requests to the OpenShift API are authenticated using the following methods: - OAuth Access Tokens - X.509 Client Certificates This is e.g. what the default installation uses to let the "root" [system] user authenticate as [openshift] "system:admin" using a client certificate. You can configure your oc client to use x509 certificates instead of tokens: $ oc config set-credentials -h Sets a user entry in kubeconfig Specifying a name that already exists will merge new fields on top of existing values. Client-certificate flags: --client-certificate=certfile --client-key=keyfile ... I guess that the question here is if we can control which [CA] certificates are involved in the verification of these client certificates, i.e. if the additional certificates that you can configure: https://docs.openshift.com/enterprise/3.1/install_config/certificate_customization.html can also be used to verify client certificates. Have we tested if this is not the case? (In reply to Josep 'Pep' Turro Mauri from comment #2) > (In reply to Eric Jones from comment #0) > > - What is the nature and description of the request? > > Customer is looking for the ability to use passwordless > > authentication means, like x509 certificates and underlying keys, with the > > "oc" command to get a token. > > This is already possible, no? > > > https://docs.openshift.com/enterprise/3.1/architecture/additional_concepts/ > authentication.html#api-authentication > > Requests to the OpenShift API are authenticated using the following > methods: > - OAuth Access Tokens > - X.509 Client Certificates > Are you saying this is possible today? > > Have we tested if this is not the case? If so can you provide an example of how to get this configuration working? (In reply to Eric Rich from comment #3) > Are you saying this is possible today? It certainly works with the internal certs. > If so can you provide an example of how to get this configuration working? On a default install: # cat /etc/origin/master/admin.kubeconfig Does that not work when there are additional namedCertificates? (In reply to Josep 'Pep' Turro Mauri from comment #4) > (In reply to Eric Rich from comment #3) > > Are you saying this is possible today? > > It certainly works with the internal certs. > > > If so can you provide an example of how to get this configuration working? > > On a default install: > > # cat /etc/origin/master/admin.kubeconfig > > Does that not work when there are additional namedCertificates? This relates to http://post-office.corp.redhat.com/archives/openshift-sme/2016-February/msg00082.html we should ask Jordan if this is possible today and if we should move this to a docs bug. Hi All, Just wanted to clarify a bit - we aren't using internal certs. There are separate certificates for authentication that shoot requests over to the agency-wide authentication mechanism (loosely based on RH Directory Server) that we've implemented an HTTP proxy to intercept and pass-through using browser X509 certificates. For this purpose, it works great! https://docs.openshift.com/enterprise/3.1/install_config/configuring_authentication.html#RequestHeaderIdentityProvider However, these same folks need access to the CLI via the "oc" command. Currently, even if everything is working, "oc login" or whichever command prompts for a username and password no matter how the authentication goes. It's entirely possible that I'm overlooking a document somewhere, or this simply is functionality that needs to be documented. Please let us know! Thanks, Taylor Taylor, I think you didn't miss anything - I missed the identity mapping side of things: while the API server and the oc client support ssl certs, they expect identities to be set in a particular way. This works for built-in users like system:admin but is not generic enough for general purpose use. The request still stands and maps to the trello card pointed in comment #0. Apologies for the noise here. This bug has been identified as a dated (created more than 3 months ago) bug. This bug has been triaged (has a trello card linked to it), or reviewed by Engineering/PM and has been put into the product backlog, however this bug has not been slated for a currently planned release (3.9, 3.10 or 3.11), which cover our releases for the rest of the calendar year. As a result of this bugs age, state on the current roadmap and PM Score (being below 70), this bug is being Closed - Differed, as it is currently not part of the products immediate priorities. Please see: https://docs.google.com/document/d/1zdqF4rB3ea8GmVIZ7qWCVYUaQ7-EexUrQEF0MTwdDkw/edit for more details. Is using Cers/Smartcards via PKINIT (and then use GSSAPI to log into OCP) or against Keycloack (via the forthcoming External Oauth server option) be a reasonable way to address this need ? With the introduction of OpenShift 4, Red Hat has delivered or roadmapped a substantial number of features based on feedback by our customers. Many of the enhancements encompass specific RFEs which have been requested, or deliver a comparable solution to a customer problem, rendering an RFE redundant. This bz (RFE) has been identified as a feature request not yet planned or scheduled for an OpenShift release and is being closed. If this feature is still an active request that needs to be tracked, Red Hat Support can assist in filing a request in the new JIRA RFE system, as well as provide you with updates as the RFE progress within our planning processes. Please open a new support case: https://access.redhat.com/support/cases/#/case/new Opening a New Support Case: https://access.redhat.com/support/cases/#/case/new As the new Jira RFE system is not yet public, Red Hat Support can help answer your questions about your RFEs via the same support case system. |
- What is the nature and description of the request? Customer is looking for the ability to use passwordless authentication means, like x509 certificates and underlying keys, with the "oc" command to get a token. - Why do you need this? (List the business requirements here) The customer requires x509 certificates as their Single-Sign-On solution, which can only verify these certificates. - How would the customer like to achieve this? (List the functional requirements here) Today the customer achives this through the use of a wrapper script to 'oc'. The script uses the configuration provided in https://docs.openshift.com/enterprise/3.1/install_config/configuring_authentication.html#RequestHeaderIdentityProvider to allow for x509 authentication to Apache. The scrip then simply request a token using a REST call (and the curl command line tool) to get an authentication token and use this in the oc login process: OC_TOKEN=$(curl --cert ${CERT} --key ${KEY} -k -v -XGET -H "X-Csrf-Token: 1" "https://${SERVER}/challenging-proxy/oauth/authorize?response_type=token&client_id=openshift-challenging-client" 2>&1 | grep Location | awk -F\# '{print $2}' | sed s/access_token=// | awk -F\& '{print $1}') oc --token=$OC_TOKEN --server=${3}:8443 login - For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. oc configuration file should allow for configuration options that allow a user to specify a public and private key, or PKI pair (pkcs12 formatted file) to be used for authentication. oc binary should allow for configuration options that allow a user to specify a public and private key, or PKI pair (pkcs12 formatted file) to be used for authentication. - Is there already an existing RFE upstream or in Red Hat Bugzilla? No, but there are engineering trackers to such work to be completed: https://trello.com/c/q09n338W/581-as-a-cli-user-i-can-log-in-using-a-x509-client-certificate - List any affected packages or components. oc - Would the customer be able to assist in testing this functionality if implemented? Likely