Example: Configuring a queue manager with mutual TLS authentication

This example deploys a queue manager by using the IBM® MQ Operator. Mutual TLS is used for authentication, to map from a TLS certificate to an identity in the queue manager.

1. Create a pair of certificates as described in Creating a self-signed PKI using OpenSSL.
2. Create a config map containing MQSC commands and an INI file
   Create a Kubernetes ConfigMap containing the MQSC commands to create a new queue and a SVRCONN channel, and to add a channel authentication record that allows access to the channel.
   Ensure that you are in the namespace you created earlier (see Before you begin), then enter the following YAML by using the command line, or optionally by using the Red Hat® OpenShift® web console if you are using a Red Hat OpenShift cluster.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: example-tls-configmap
   data:
     example-tls.mqsc: |
       DEFINE CHANNEL('MTLS.SVRCONN') CHLTYPE(SVRCONN) SSLCAUTH(REQUIRED) SSLCIPH('ANY_TLS13_OR_HIGHER') REPLACE
       SET CHLAUTH('MTLS.SVRCONN') TYPE(SSLPEERMAP) SSLPEER('CN=*') USERSRC(NOACCESS) ACTION(REPLACE)
       SET CHLAUTH('MTLS.SVRCONN') TYPE(SSLPEERMAP) SSLPEER('CN=example-app1') USERSRC(MAP) MCAUSER('app1') ACTION(REPLACE)
       SET AUTHREC PRINCIPAL('app1') OBJTYPE(QMGR) AUTHADD(CONNECT,INQ)
       DEFINE QLOCAL('EXAMPLE.QUEUE') REPLACE 
       SET AUTHREC PROFILE('EXAMPLE.QUEUE') PRINCIPAL('app1') OBJTYPE(QUEUE) AUTHADD(BROWSE,PUT,GET,INQ)
     example-tls.ini: |
       Service:
           Name=AuthorizationService
           EntryPoints=14
           SecurityPolicy=UserExternal

   The MQSC defines a channel called MTLS.SVRCONN and a queue called EXAMPLE.QUEUE. The channel is configured to allow access only to clients which present a certificate with a "common name" of example-app1. This is the common name used in one of the certificates created in Step 1. Connections on this channel with this common name are mapped to a user ID of app1, which is authorized to connect to the queue manager, and to access the example queue. The INI file enables a security policy which means that the app1 user ID does not need to exist in an external user registry — it exists only as a name in this configuration.
3. Deploy the queue manager
   Create a new queue manager using custom resource YAML. Ensure you are in the namespace you created before you began this task.

   Note that the example-qm-tls Secret was created in Step 1, and the example-tls-configmap ConfigMap was created in Step 2.

   Note: The following YAML uses an IBM MQ Advanced license, though you can also use an IBM MQ license. For more information, see Configuring Queue Managers with IBM MQ license annotations by using the IBM MQ Operator.

   Important: If you accept the IBM MQ Advanced license agreement, change accept: false to accept: true. See mq.ibm.com/v1beta1: Current license versions for details on the license.

   Example QueueManager for Red Hat OpenShift

   Deploy your queue manager with the following configuration, using the command line or using the Red Hat OpenShift web console.

   apiVersion: mq.ibm.com/v1beta1
   kind: QueueManager
   metadata:
     name: exampleqm
   spec:
     license:
       accept: false
       license: L-CXDB-XTZ9J8
       use: Production
     queueManager:
       name: EXAMPLEQM
       mqsc:
       - configMap:
           name: example-tls-configmap
           items:
           - example-tls.mqsc
       ini:
       - configMap:
           name: example-tls-configmap
           items:
           - example-tls.ini
       storage:
         queueManager:
           type: ephemeral
     version: 10.0.0.0-r1
     pki:
       keys:
         - name: default
           secret:
             secretName: example-qm-tls
             items:
               - tls.key
               - tls.crt
               - ca.crt

   Example QueueManager for Amazon EKS

   Deploy your queue manager with the following configuration on an Amazon EKS cluster.

   apiVersion: mq.ibm.com/v1beta1
   kind: QueueManager
   metadata:
     name: exampleqm
   spec:
     license:
       accept: false
       license: L-CXDB-XTZ9J8
       use: Production
     queueManager:
       name: EXAMPLEQM
       mqsc:
       - configMap:
           name: example-tls-configmap
           items:
           - example-tls.mqsc
       ini:
       - configMap:
           name: example-tls-configmap
           items:
           - example-tls.ini
       storage:
         queueManager:
           type: ephemeral
       route:
         enabled: false
       metrics:
         serviceMonitor:
           enabled: false
     version: 10.0.0.0-r1
     pki:
       keys:
         - name: default
           secret:
             secretName: example-qm-tls
             items:
               - tls.key
               - tls.crt
               - ca.crt
     web:
       enabled: false
       route:
         enabled: false

   spec.queueManager.route.enabled, spec.queueManager.metrics.serviceMonitor.enabled, and spec.web.route.enabled are set to false because these are Red Hat OpenShift specific features that are enabled by default. These features must be disabled explicitly on Amazon EKS.

4. Confirm that the queue manager is running
   The queue manager is now being deployed. Confirm it is in Running state before proceeding. For example:

   • For deployments on the Red Hat OpenShift Container Platform:

     oc get qmgr exampleqm
     

   • For deployments on Amazon EKS:

     kubectl get qmgr exampleqm

5. Test the connection to the queue manager
   To confirm the queue manager is configured for mutual TLS communication, follow the steps in the appropriate link for your platform:

   • Red Hat OpenShift: Testing a mutual TLS connection to a queue manager from your laptop for Red Hat OpenShift
   • Amazon EKS: Testing a mutual TLS connection to a queue manager from a client application on your laptop for Amazon EKS