8.2.4. Authenticating Using Mutual SSL
Mutual SSL authentication, commonly referred to as x509 or two-way authentication, allows for an application developer, which is the SSL client, to authenticate to an application, which is the SSL server, and vice versa. Each side has a verification certificate, which is shared upon connection. Using mutual authentication ensures an additional level of security in your deployment, because without the approved authentication certificate a user is unable to connect to the SSL server.
Apache supports mutual SSL authentication natively in Red Hat Enterprise Linux 6; however, the SSL connection for the broker in OpenShift Enterprise 2 terminates by default on a separate Apache instance from the one that runs the broker application. Therefore, you must take special care when modifying the default configurations to securely pass the trusted
REMOTE_USER
to the broker.
Ensuring mutual SSL authentication on your OpenShift Enterprise instance requires the completion of a series of procedures, outlined below. Each procedure is for a different interaction component of your installation: the broker proxy, the broker application, and, if it has been installed, the Management Console. After the broker has been configured, developers must also configure their client tools to use mutual SSL authentication, which is covered in the OpenShift Enterprise User Guide [4].
Procedure 8.4. To Modify the Broker Proxy Configuration for Mutual SSL Authentication:
While it is possible to translate the following configuration changes to a proxy or load balancer of your choice, this procedure assumes that Apache is being used to terminate the SSL connection for the broker. The default proxy on the broker is configured by the
/etc/httpd/conf.d/000002_openshift_origin_broker_proxy.conf
file.
- Edit the
/etc/httpd/conf.d/000002_openshift_origin_broker_proxy.conf
file on the broker host and add the following lines in the<VirtualHost *:443>
block directly after theSSLProxyEngine
directive, removing any otherSSLCertificateFile
,SSLCertificateKeyFile
, andSSLCACertificateFile
directives that may have previously been set:SSLOptions +StdEnvVars SSLCertificateFile
path/to/SSL/certificate/file
SSLCertificateKeyFilepath/to/certificate/keyfile
SSLCACertificateFilepath/to/SSLCA/certificate/file
SSLVerifyClient optional SSLVerifyDepth 2 RequestHeader set X-Remote-User %{SSL_CLIENT_S_DN_CN}e env=SSL_CLIENT_S_DN_CNThese directives serve the following functions for the SSL virtual host:- The
SSLCertificateFile
,SSLCertificateKeyFile
, andSSLCACertificateFile
directives are critical, because they set the paths to the certificates. - The
SSLVerifyClient
directive set tooptional
is also critical as it accommodates certain broker API calls that do not require authentication. - The
SSLVerifyDepth
directive can be changed based on the number of certificate authorities used to create the certificates. - The
RequestHeader
directive set to the above options allows a mostly standard broker proxy to turn the CN from the client certificate subject into anX_REMOTE_USER
header that is trusted by the back-end broker. Importantly, ensure that the traffic between the SSL termination proxy and the broker application is trusted.
- Restart the broker proxy:
#
service httpd restart
Procedure 8.5. To Modify the Broker Application Configuration for Mutual SSL Authentication:
- Edit the
/var/www/openshift/broker/httpd/conf.d/openshift-origin-auth-remote-user.conf
file on the broker host to be exactly as shown:<Location /broker> # Broker handles auth tokens SetEnvIfNoCase Authorization Bearer passthrough # Console traffic will hit the local port. mod_proxy will set this header automatically. SetEnvIf X-Forwarded-For "^$" passthrough=1 # Turn the Trusted header into the Apache environment variable for the broker remote-user plugin SetEnvIf X-Remote-User "(..*)" REMOTE_USER=$1 passthrough=1 # Old-style auth keys are POSTed as parameters. The deployment registration # and snapshot-save use this. BrowserMatchNoCase ^OpenShift passthrough # Older-style auth keys are POSTed in a header. The Jenkins cartridge does # this. SetEnvIf broker_auth_key "^[A-Za-z0-9+/=]+$" passthrough=1 Allow from env=passthrough # Allow the specific requests that can passthrough and then deny everything else. The following requests can passthrough: # # * Use Bearer authentication # * Use Broker authentication tokens # * Originate from the trusted Console Order Allow,Deny </Location> # The following APIs do not require auth: # # /api # /environment # /cartridges # /quickstarts # # We want to match requests in the form of: # # /api # /api.json # /api/ # # But not: # # /api_with_auth <LocationMatch ^/broker/rest/(api|environment|cartridges|quickstarts)(\.\w+|/?|/.*)$> <IfVersion >= 2.4> Require all granted </IfVersion> <IfVersion < 2.4> Allow from all </IfVersion> </LocationMatch>
- Set the following in the
/etc/openshift/plugins.d/openshift-origin-auth-remote-user.conf
file:TRUSTED_HEADER="HTTP_X_REMOTE_USER"
- Restart the broker service for the changes to take effect:
#
service openshift-broker restart
Procedure 8.6. To Modify the Management Console Configuration for Mutual SSL Authentication:
If you have installed the optional Management Console, it must be configured before mutual SSL authentication can be used. See Section 8.9, “Management Console” first for instructions on installing the Management Console.
- Edit the
/var/www/openshift/console/httpd/conf.d/openshift-origin-auth-remote-user.conf
file on the broker host and add the following:<Location /console> # The node->broker auth is handled in the Ruby code BrowserMatch Openshift passthrough Allow from env=passthrough # Turn the Console output header into the Apache environment variable for the broker remote-user plugin SetEnvIf X-Remote-User "(..*)" REMOTE_USER=$1 Order Deny,Allow </Location>
- Set the following in the
/etc/openshift/console.conf
file:REMOTE_USER_HEADER=HTTP_X_REMOTE_USER
- Restart the Management Console service for the changes to take effect:
#
service openshift-console restart
Procedure 8.7. To Test the Mutual SSL Configuration:
- Run the following command and ensure it returns successfully:
#
curl -k https://broker.example.com/broker/rest/api
- Run the following command and ensure it returns with a
403 Forbidden
status code:#
curl -k https://broker.example.com/broker/rest/user
- Run the following commands and ensure they return successfully:
#
curl --cert path/to/certificate/file --key path/to/certificate/keyfile --cacert path/to/SSLCA/certificate/file https://broker.example.com/broker/rest/api
#curl --cert path/to/certificate/file --key path/to/certificate/keyfile --cacert path/to/SSLCA/certificate/file https://broker.example.com/broker/rest/user
Note that the above commands may need to be altered with the--key
option if your key and certificate are not located in the same PEM file. This option is used to specify the key location if it differs from your certificate file.
To test using the client tools, each application developer must first configure them to use mutual SSL authentication. See the OpenShift Enterprise User Guide [4]for instructions.