MQ

In this article, we shall discuss the MQ TLS certificate management when used in a Kubernetes cluster using Helm. It is a specific case for AWS EKS, but basic principle remains the same even for Azure.

Prerequisites:

• A ready EKS cluster
• MQ certificate and key along with signer certificates (if using a CA signed cert)
• Helm installed and access configured to the EKS cluster from your machine

When deploying MQs in an EKS cluster, TLS is a major consideration. IBM provides Helm charts for the deployment of a queue manager on a Kubernetes cluster

https://github.com/ibm-messaging/mq-helm/tree/main/charts/ibm-mq/templates

Here, in the values.yaml file in the pki section, we have to provide the pki information as below:

        pki:
          keys: 
          - name: ibmwebspheremqqmgr
            secret:
              secretName: ibmmqsecret
              items:
                - tls.key
                - tls.crt
                - signer1.crt
                - signer2.crt
                - signer3.crt

In order for the above deployment to be successful, we have to ensure that the secret containing this information exists beforehand. And since this is confidential information, keeping it in Git is not a good idea. 

We can make use of AWS Systems Manager Parameter Store for storing this information and then deploying it in our EKS cluster through a simple Helm chart. Just enter the certificate information (base64 encoded format) into the AWS console. We will be doing all of this in the eu-west-1 region where our EKS cluster should also exist.

Create the needed parameters as below:

Now that this is done, we are ready to create and deploy our Helm chart in our EKS cluster. 

In a new directory called mq-certificates, create the below files:

Chart.yaml

apiVersion: v1
name: root
version: 1.0.0

values.yaml

spec:
  mqTlsCrt: ref+awsssm://dev/tlscrt?region=eu-west-1
  mqTlsKey: ref+awsssm://dev/tlskey?region=eu-west-1
  signer1: ref+awsssm://dev/signer1?region=eu-west-1
  signer2: ref+awsssm://dev/signer2?region=eu-west-1
  signer3: ref+awsssm://dev/signer3?region=eu-west-1

Create a directory "templates" and inside it a file

ibmmqsecret.yaml

apiVersion: v1
data:
  tls.crt: {{ .Values.spec.mqTlsCrt }}
  tls.key: {{ .Values.spec.mqTlsKey }}
  signer1.crt: {{ .Values.spec.signer1 }}
  signer2.crt: {{ .Values.spec.signer2 }}
  signer3.crt: {{ .Values.spec.signer3 }}
kind: Secret
metadata:
  name: ibmmqsecret
  namespace: ibm-mq
type: kubernetes.io/tls

Now we can deploy our secret using this Helm chart onto our EKS cluster and then deploy the MQ using its Helm chart. 

helm install mq-secret ./mq-certificates

Your MQ secret is now deployed in the cluster, and you can proceed with the deployment of the MQ queue manager. In the future when you need to renew the certificate, just update the values in AWS Systems Manager Parameter store and deploy the Helm release once again, for the new values to take effect, followed by a rolling update of the MQ pods. This will result in the certificate being renewed.