-
Notifications
You must be signed in to change notification settings - Fork 3
/
using.html.md.erb
77 lines (49 loc) · 4.89 KB
/
using.html.md.erb
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
---
title: Using IBM® MQ Advanced for Developers for VMware Tanzu
owner: Partners
---
<strong><%= modified_date %></strong>
This topic describes how to use IBM MQ Advanced for Developers for VMware Tanzu.
## <a id='using'></a> Using IBM MQ Advanced for Developers for VMware Tanzu
### Accessing the MQ Web Console
The MQ Advanced for Developers image includes the MQ web server. The web server runs the web console, and the MQ REST APIs. By default, the MQ server deployed by this chart is accessible via a `ClusterIP` [Service](https://kubernetes.io/docs/concepts/services-networking/service/), which is only accessible from within the Kubernetes cluster.
If you want to access the web console from a web browser, then you need to select a different type of Service. For example, a `NodePort` service will expose the web console port on each worker node.
### Supplying certificates to be used for TLS
The `pki.trust` and `pki.keys` allow you to supply details of Kubernetes secrets that contain TLS certificates. By doing so the TLS certificates will be imported into the container at runtime and MQ will be configured to use them. You can supply both Certificiates which contain only a public key and certificiates that contain both public and private keys.
If you supply invalid files or invalid YAML objects then the container will terminate with an appropriate termination message. The next 2 sections will detail the requirements for supplying each type of certificate.
#### Supplying certificates which contain the public and private keys
When supplying a Kubernetes secret that contains a certificate files for both the public and private key you must ensure that the secret contains a file that ends in `.crt` and a file that ends in `.key` named the same. For example: `tls.crt` and `tls.key`. The extension of the file denotes whether the file is the public key (`.crt`) or the private key (`.key`) and must be correct. If your certificate has been issued by a Certificate Authority, then the certificate from the CA must be included as a seperate file with the `.crt` extension. For example: `ca.crt`.
The format of the YAML objects for `pki.keys` value is as follows:
```YAML
- name: mykeys
secret:
secretName: mykeysecret
items:
- tls.key
- tls.crt
- ca.crt
```
or alternatively in a single line you can supply the following: `- name: mykeys, secret: {secretName: mykeysecret, items: [tls.key, tls.crt, ca.crt]}`
`name` must be set to a lowercase alphanumeric value and will be used as the label for the certificate in the keystore and queue manager.
`secret.secretName` must match the name of a Kubernetes secret that contains the TLS certificates you wish to import
`secret.items` must list the TLS certificate files contained in `secret.secretName` you want to import.
To supply the YAML objects when deploying via Helm you should use the following: `--set pki.keys[0].name=mykeys,pki.keys[0].secret.secretName=mykeysecret,pki.keys[0].secret.items[0]=tls.key,pki.keys[0].secret.items[1]=tls.crt,pki.keys[0].secret.items[2]=ca.crt`
If you supply multiple YAML objects then the queue manager will use the first object choosen by the label name alphabetically. For example if you supply the following labels: `alabel`, `blabel` and `clabel`. The queue manager and MQ Console will use the certificate with the label `alabel` for it's identity. In this queue manager this can be changed by running the MQSC command: `ALTER QMGR CERTLABL('<new label>')`.
#### Supplying certficates which contain only the public key
When supplying a Kubernetes secret that contains a certificate file with only the public key you must ensure that the secret contains files that have the extension `.crt`. For example: `tls.crt` and `ca.crt`.
The format of the YAML objects for `pki.trust` value is as follows:
```YAML
- secret:
secretName: mycertificate
items:
- tls.crt
```
or alternatively in a single line you can supply the following: `- secret: {secretName: mycertificate, items: [tls.crt]}`
`secret.secretName` must match the name of a Kubernetes secret that contains the TLS certificates you wish to add.
`secret.items` must list the TLS certificate files contained in `secret.secretName` you want to add.
To supply the YAML objects when deploying via Helm you should use the following: `--set pki.trust[0].secret.secretName=mycertificate,pki.trust[0].secret.items[0]=tls.crt`
If you supply multiple YAML objects then all of the certificates specified will be added into the queue managers and MQ Console Truststore.
### Useful Links
* [IBM MQ Version 9.1 documentation](https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.helphome.v91.doc/WelcomePagev9r1.htm)
* [Configuring the IBM MQ Console and REST API](https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.con.doc/q128300_.htm)
* [Configuring IBM MQ](https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.con.doc/q015120_.htm)