How to use Openshift secrets to establish MQ client connection over SSL

Question

I'm trying to combine suggestions on how to use SSL with openshift : https://blog.openshift.com/openshift-demo-part-13-using-ssl/

with those on how to use ssl with mq:

Spring Configuration for JMS (Websphere MQ - SSL, Tomcat, JNDI, Non IBM JRE)

So I managed to modify my Spring Boot Camel app to move from connection via svrconn mq channel without SSL to one that uses SSL, by adding SSLCipherSuite property to com.ibm.mq.jms.MQConnectionFactory bean, and by adding these VM arguments to Run Configuration (as described in the second linked document):

-Djavax.net.ssl.trustStore=C:\path-to-keystore\key.jks
-Djavax.net.ssl.trustStorePassword=topsecret
-Djavax.net.ssl.keyStore=C:\path-to-keystore\key.jks
-Djavax.net.ssl.keyStorePassword=topsecret
-Dcom.ibm.mq.cfg.useIBMCipherMappings=false

And it works fine locally on embedded Tomcat server, however, I would need to deploy it to Openshift, so my first impulse was to add the same VM arguments to those that I use for Openshift deployment, that is these ones:

-Dkubernetes.master=
-Dkubernetes.namespace=
-Dkubernetes.auth.basic.username=
-Dkubernetes.auth.basic.password=
-Dkubernetes.trust.certificates=
-Dfabric8.mode=openshift

but it obviously doesn't work, for example because I don't have the same path to keystore. So I investigated it a bit, and learned that I have to use secrets, that can be defined via CLI >>oc secrets new<< command, or via Openshift console, but I don't understand how exactly to proceed. Do I have to add parameters to image, or environment variables to deployment config or something else? Somehow it has to reference the defined secrets, and it has to be named by changing each dot with underscore in its name? So, for example if I issue:

oc secrets new my-key-jks key.jks

then I have to >>Add Value from Config Map or Secret<<

JAVAX_NET_SSL_TRUSTSTORE my-key-jks key.jks

and Add Value:

COM_IBM_MQ_CFG_USEIBMCIPHERMAPPINGS false ??

I tried that, but this doesn't work, I added values to deploymentconfigs, so that I get such excerpt:

        "spec": {
            "containers": [
                {
                    "env": [
                        {
                            "name": "KUBERNETES_NAMESPACE",
                            "valueFrom": {
                                "fieldRef": {
                                    "apiVersion": "v1",
                                    "fieldPath": "metadata.namespace"
                                }
                            }
                        },
                        {
                            "name": "JAVAX_NET_SSL_TRUSTSTORE",
                            "valueFrom": {
                                "secretKeyRef": {
                                    "key": "key.jks",
                                    "name": "my-key-jks"
                                }
                            }
                        },

when I do:

  oc get dc app_name -o json

I have also created sa (serviceaccount) and assigned him as an admin to project, and assigned him to use newly created secret, I did it through Openshift console, so that I don't have oc CLI code right now. This is also somewhat relevant (but it doesn't help me much):

https://github.com/openshift/openshift-docs/issues/699

After a build, pod's status becomes >>Crash Loop Back-off<<, and >>The logs are no longer available or could not be loaded.<< Without SSL, the same app runs fine on Openshift.

Answer 1

IMHO you are misinterpreting some of the settings you specify here.

1.

The VM arguments after "-Dkubernetes.master=" you specify here I assume are meant to be given to the fabric8 maven plugin which you use for deployment. Right?

The parameters that are about authentication/certificates here are ONLY for the communication to kubernetes and NOT intended for giving keystore data to your application to use. So I think they are unrelated.

Instead you need to ensure that inside your container your app gets started with the same parameters that you use for local execution. Of course you then would have to change the parameter values to where the respective data is available inside your container.

2.

Secrets are a tool to add sensitive data to your deployment that you don't want to be baked into your application image. So for example your keystores and the keystore passwords would qualify to be injected via secret.

An alternative to providing secret data as environment variable, like you tried, is to just mount them into the filesystem which makes the secret data available as files. As your application needs the JKS as a file you could do the following.

1. In the web console on your deployment, use the link "Add config files" under section "Volumes"

2. Select the secret "my-key-jks" created before as "source".

3. Specify some path where the secret should be mounted inside your container, for example "/secret". Then click "Add".

4. You jks will then be available inside your container under path "/secret/key.jks" so your applications parameter can point to this path.