Before you begin
Review the pre-installation planning sections in Installing the Event Gateway.
Creating TLS certificates for the Event Gateway
Two options are available for configuring TLS on your operator-managed Event Gateway:
- Specify the CA certificate and key for your gateway. When you specify the CA certificate, the Event Endpoint Management operator automatically generates and maintains the server certificate that secures your gateway endpoint.
- Specify the server certificate, the server certificate key, and the CA certificate for your gateway.
Creating a self-signed CA certificate with cert-manager
The best way to create and manage TLS certificates is to use cert-manager. Cert-manager creates TLS certificates based on a YAML definition, stores them in Kubernetes secrets, and automatically renews them before they expire. Cert-manager supports integration with external public signers, and can also create self-signed certificates.
On Kubernetes, install the cert-manager community operator. Cert-manager is included on Red Hat OpenShift.
The Event Gateway YAML files that the Event Endpoint Management UI creates includes the definitions of a self-signed certificate and issuer.
If you want to create externally-signed certificates with cert-manager, see the cert-manager documentation.
Generating a CA certificate with OpenSSL
For test and demonstration purposes, you can create a CA certificate and key with the following OpenSSL commands:
openssl genrsa -out tls.key 2048
openssl req -new -x509 -key tls.key -days 730 -out tls.crt
Important: It is recommended to use cert-manager to create and manage your certificates. Do not use this example certificate in production environments.
Supplying your own server certificate and key
If you already have a server certificate that you want to use, then create a Kubernetes secret that contains this certificate, along with its key and CA certificate.
The Subject Alternative Names (SANs) in your certificate must include the path to all the hostnames that are used for your Event Gateway. You can use a wildcard SAN entry, for example: *.<CLUSTER_API> - where <CLUSTER_API> is derived from the URL of your OpenShift Container Platform cluster. If the URL is https://console-openshift-console.apps.clusterapi.com/ then <cluster api> is apps.clusterapi.com.
If your certificate is not signed by a well-known public CA chain, then you must provide the full signing chain.
-
Create a file called
custom-gateway-cert.yamland paste in the following contents:apiVersion: v1 data: ca.crt: <base64 encoded CA certificate> tls.crt: <base64 encoded server certificate> tls.key: <base64 encoded key> metadata: name: custom-gateway-cert kind: Secret type: kubernetes.io/tls -
Apply the file to create the Kubenetes secret in the same namespace where your Event Gateway is to be deployed:
kubectl -n <namespace> apply -f custom-gateway-cert.yaml
Operator-managed Event Gateway installation steps
- In the navigation pane, click Administration > Event Gateways.
- Click Add gateway.
- Select the Operator-managed deployment tile, then click Next.
-
Provide the configuration details for your gateway, then click Next.
- Gateway group: Create or specify an existing gateway group for your new gateway.
- Gateway ID: Provide an ID for your new gateway that is unique within the gateway group.
- Replicas: The number of Kubernetes replicas of the gateway pod to create.
- Copy the generated custom resource YAML to two separate files:
<gateway name>-gateway_cr_original.yaml<gateway name>-gateway_cr.yaml
Important: Keep the
<gateway name>-gateway_cr_original.yamlfile in a safe location and do not edit it. To remove write permissions to avoid accidental updates to this file, you can runchmod a-w <filename>. -
Update the
<gateway name>-gateway_cr.yamlfile and setspec.license.accepttotrue. -
(Optional) To create a gateway using wildcard routes, update
<gateway name>-gateway_cr.yamlas follows:spec: ... listeners: - groups: - endpoint: host: wildcard.<group-name>.<listener-name>-<instance-name>-<namespace>.<clusterDomain> name: <group-name> type: WILDCARD name: <listener-name> port: <port> tls: certificateType: WILDCARDNote: Wildcard routes are not enabled by default in OpenShift Container Platform. See wildcard policy to enable wildcard routes in your Ingress Controller.
Note: Wildcard hostnames on operator-managed gateways are supported only in OpenShift Container Platform.
-
Configure TLS certificates. The following TLS configuration options are available:
-
Use the default self-signed certificate that is generated by the Event Endpoint Management operator. No action is required, continue to step 8.
-
If you want Event Endpoint Management to generate leaf certificates from your own CA certificate, then update
<gateway name>-gateway_cr.yamlas follows:In the custom resource section, define the
tlsproperty inspec.listeners[listener]to refer to a Kubernetes secret that contains your CA certificate:spec: listeners: - name: listener tls: caSecret: secretName: "<Kubernetes secret that contains your root CA certificate and key pair>" -
If already have a Kubernetes secret that contains your own server certificate and you want to use this secret, or if you have an existing gateway instance in the same namespace and you want to use the same secret, then update
<gateway name>-gateway_cr.yamlas follows:In the custom resource section, define the
tlsproperty inspec.listeners[listener]to refer to your server certificate:spec: listeners: - name: listener tls: certificateType: "WILDCARD|EXPLICIT" # "The type of certificate to generate: 'wildcard' for a single wildcard certificate (*.example.com), or 'explicit' for a single certificate with explicit hostnames as SANs. secretName: "<Kubernetes secret that contains your CA and server certificate and key>" key: "tls.key" serverCertificate: "tls.crt" caCertificate: "ca.crt"If your Kubernetes secret does not use the key names
tls.key,tls.crt, andca.crt, then updatetls.key,tls.serviceCertificate, andtls.caCertificateto match the key names that you use in your secret. For example, if your Kubernetes secret is:apiVersion: v1 kind: Secret metadata: name: custom-tls-certs data: certKey: <BASE64_KEY> serverCert: <BASE64_CERT> caCert: <BASE64_CA_CERT>then update
spec.listeners[listener].tlsto specify these key names:spec: listeners: - name: listener tls: ... key: "certKey" serverCertificate: "serverCert" caCertificate: "caCert"Important: If you do not supply a CA certificate in the secret that is referenced by
spec.listeners[listener].tls.secretNameand use it fromspec.listeners[listener].tls.caCertificate, then users cannot download the gateway certificate from the Event Endpoint Management UI catalog page.
-
-
If you are deploying an operator-managed gateway on other Kubernetes platforms, then add the
spec.listeners[].groups[].endpointsection to your<gateway name>-gateway_cr.yamlfile:spec: listeners: - name: <listener-name> groups: - name: <group-name> endpoint: host: my-gateway.example.comFor more information about the
endpointsproperty, see configuring ingresses. -
Replace any other placeholder variables in the YAML.
-
Create a backup of the updated
<gateway name>-gateway_cr.yamlfile, in addition to the<gateway name>-gateway_cr_original.yamlfile. -
To install the Event Gateway through the OpenShift Container Platform web console, complete the following steps:
a. Log in to the OpenShift Container Platform web console using your login credentials.
b. Click the + (Quick create) icon in the upper-right.
c. Select Import YAML.
d. Set Project to the namespace where you want to install the Event Gateway.
e. Paste in the contents of your updated
<gateway name>-gateway_cr.yamlfile.h. Click Create to start the Event Gateway installation process.
-
To install the Event Gateway by using the CLI, run the following commands:
kubectl -n <gateway namespace> apply -f <gateway name>-gateway_cr.yaml -
Return to the Event Gateways page to monitor the status of the new Event Gateway. When the gateway is registered, the status reports Running.
- Complete the gateway verification checks.