Bug 1038853

Summary:	Facilitate SSL Mutual Auth (Client certs) configuration per-app
Product:	OpenShift Container Platform	Reporter:	Keith Robertson <kroberts>
Component:	RFE	Assignee:	jofernan
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	high	Docs Contact:
Priority:	high
Version:	3.0.0	CC:	agoldste, ansilva, aweiteka, bleanhar, bretm, dgregor, dvarga, erich, jkaur, jkeck, jmoran, jstrong, libra-onpremise-devel, lmeyer, lphiri, nicholas_schuetz
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-08-18 12:52:44 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:
Bug Depends On:
Bug Blocks:	1038857, 1042924

Description Keith Robertson 2013-12-05 23:58:58 UTC

Description of problem:
Due to the fact that Openshift terminates SSL connections at the node level and not at the gear level, SSL mutual authentication is impossible without additional user level controls to the node level Apache VirtualHost for a particular gear.  This defect requests that these controls be re-exposed via the OSE admin console in the 'SSL Certificate' section of the administrator console.

Openshift users need the ability to set SSLVerifyClient[1] to either 'optional' or 'required' for their particular gear.  Having this control will cause the Apache proxy at the node to *request* from the client its x509 certificate.  This certificate will then be inserted into a custom HTTP header argument (i.e. x-forwarded-ssl-client-cert) by the OSE Apache node level proxy.  

Code already exists in in Openshift[2] for the 'x-forwarded-ssl-client-cert', but it is a noop without the associated SSLVerifyClient mod_ssl directive.

[1] http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslverifyclient
[2] https://github.com/openshift/origin-server/blob/master/plugins/frontend/apache-mod-rewrite/httpd/frontend-mod-rewrite-https-template.erb

Version-Release number of selected component (if applicable):
1.2 and 2.0

How reproducible:
always

Steps to Reproduce:
SSL mutual auth is impossible without the ability to set this variable.


Expected results:
SSL mutual auth is configurable per-gear.

Comment 2 Luke Meyer 2013-12-13 17:54:59 UTC

Created a trello card for this feature (includes blocked bugs) - https://trello.com/c/m98XJLY1/140-request-and-validate-client-certificates

The current way to implement this would be to install and configure the rubygem-openshift-origin-frontend-apache-vhost frontend on your nodes, which creates individual vhost confs in /var/lib/openshift/.httpd.d per gear. An administrator can then hand-edit these confs as desired, keeping in mind that they will be re-created from scratch (and thus changes lost) if the gear is moved.

Comment 3 Luke Meyer 2013-12-13 17:59:53 UTC

I should also note that the apache-vhost frontend only covers the standard 80/443 ports - websockets ports at 8000/8443 and port-proxy ports aren't really amenable to hand-editing. So this workaround has a number of drawbacks.

Comment 11 Luke Meyer 2014-05-13 15:46:34 UTC

*** Bug 1038857 has been marked as a duplicate of this bug. ***

Comment 12 Luke Meyer 2014-05-13 15:50:50 UTC

*** Bug 1042924 has been marked as a duplicate of this bug. ***

Comment 13 Luke Meyer 2014-05-13 15:51:38 UTC

Marking related bugs as duplicates. SSLVerifyDepth and SSLCACertificateFile would also need to be configurable as part of this solution.

Comment 16 Brenton Leanhardt 2015-08-18 12:52:44 UTC

This is now possible with OpenShift Enterprise 3.0.  Simply create a Route via the API and set 'passthrough' TLS.  The connection with be terminated by the Pod (or Gear in 2.x terminology).  Certificates can be injected in to Pods through the Secrets API.

https://docs.openshift.com/enterprise/3.0/architecture/core_concepts/routes.html#passthrough-termination

Comment 17 Jaspreet Kaur 2015-09-10 10:36:10 UTC

*** Bug 1259223 has been marked as a duplicate of this bug. ***