Bug 1314526 - [RFE] x509 cli authentication
[RFE] x509 cli authentication
Status: NEW
Product: OpenShift Container Platform
Classification: Red Hat
Component: RFE (Show other bugs)
3.1.0
Unspecified Unspecified
high Severity medium
: ---
: ---
Assigned To: Eric Paris
Chuan Yu
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-03 15:22 EST by Eric Jones
Modified: 2018-06-23 03:01 EDT (History)
17 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
OpenShift Enterprise 3.x
Last Closed: 2018-03-12 09:54:36 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Eric Jones 2016-03-03 15:22:34 EST
- 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
Comment 2 Josep 'Pep' Turro Mauri 2016-03-07 08:44:39 EST
(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?
Comment 3 Eric Rich 2016-03-07 08:50:40 EST
(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?
Comment 4 Josep 'Pep' Turro Mauri 2016-03-07 09:00:45 EST
(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?
Comment 5 Eric Rich 2016-03-07 09:54:22 EST
(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.
Comment 7 Taylor Biggs 2016-03-07 15:48:52 EST
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
Comment 8 Josep 'Pep' Turro Mauri 2016-03-07 16:36:24 EST
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.
Comment 12 Eric Rich 2018-03-12 09:54:36 EDT
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.
Comment 21 Simo Sorce 2018-05-03 10:42:25 EDT
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 ?

Note You need to log in before you can comment on or make changes to this bug.