How to enable HTTPS and SSL termination in a Quarkus app
When it comes to the container world, it is common to have an application deployed to a cluster that needs to be secured. In this article, I will show you how to enable HTTPS and SSL termination for a Quarkus application that is running in Red Hat OpenShift.
Create the secret
First, we will need a paired key and certificate. If you do not have any available, you can use the following command to create a development-only key and certificate:
~ openssl req -newkey rsa:2048 -new -nodes -x509 -days 3650 -keyout key.pem -out cert.pem
This will create two files (key.pem and cert.pem) that we need to inject into our pods to make them available to the Quarkus application. This can easily be achieved using secrets and volumes by following these steps:
- Create a key/value secret in the Create Key/Value Secret dialog box.
- Add two keys, one for the file cert.pem and one for the key.pem, as shown in Figure 1.
Once created, add the secret to the application’s workload as shown in Figure 2.
We now add it as a volume with a mount path of our choice. This will mount and add both the cert and the key files to all application pods.
Everything you need to grow your career.
With your free Red Hat Developer program membership, unlock our library of cheat sheets and ebooks on next-generation application development.SIGN UP
Once the secret has been added to the workload, we’ll need to set up some environment variables in order to enable HTTPS and for Quarkus to expose the proper port. The most important parts of the configuration are the environment variables referring to the SSL certificate. For more information about options available when configuring SSL in Quarkus see this section of the Quarkus HTTP Reference Guide.
Figure 3 shows an example of the resulting configuration.
With this configuration, we’re redirecting all of the insecure requests, and we’re telling Quarkus to use the key and the certificate (that we have mounted in the previous step) into the pods.
Now our Quarkus application should be exposing port 8443 for HTTPS. If we go to the application logs, we should see a message like the following:
Exposing the app to the real world
Great, the Quarkus application is now exposing the proper port and accepting connections through HTTPS. At this point, we can consider the Quarkus work done. However, if we don’t expose our app to the external world, this is useless.
In order to make our app available externally, we are going to need a service and a route. A service serves as an internal load balancer. It identifies a set of replicated pods in order to proxy the connections it receives to them. Services are assigned an IP address and port that, when accessed, proxy to an appropriate backing pod.
A service uses a label selector to find all of the running containers that provide a certain network service on a certain port. Here’s a service example:
apiVersion: v1 kind: Service metadata: generateName: test-ssl-apicurioregistry-service- namespace: default spec: selector: app: test-ssl-apicurioregistry ports: - protocol: TCP port: 8443 targetPort: 8443
An OpenShift route is a way to expose a service by giving it an externally-reachable host name. For more information on how to create or manage secured routes, see the Secured Routes section of the OpenShift documentation.
Here’s a secured route example:
apiVersion: v1 kind: Route metadata: name: secured-registry namespace: default spec: to: kind: Service name: test-ssl-apicurioregistry-service-mjdzd weight: 100 port: targetPort: 8443 tls: termination: passthrough insecureEdgeTerminationPolicy: Redirect wildcardPolicy: None
Check the configuration
We can easily check our configuration using the OpenShift client:
➜ ~ oc get routes NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD secured-registry secured-registry-default.apps.carnalca.ipt.integrations.rhmw.io test-ssl-apicurioregistry-service-mjdzd 8443 passthrough/Redirect None
➜ ~ oc get svc test-ssl-apicurioregistry-service-mjdzd NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE test-ssl-apicurioregistry-service-mjdzd ClusterIP 172.30.122.25 8443/TCP 21h
In this article, I showed you how to secure the traffic of a Quarkus application. From the Quarkus properties to the OpenShift resources, you have seen the simplest way to achieve this goal. While I’ve used some defaults, there are many other features and configurations to explore. Here I am just covering the basics on how to secure a Quarkus application in OpenShift while keeping everything as simple as possible. I hope sharing this experience will be helpful to others.