yersan/tls-wildfly-demo

A demo project as a playground for mutual microservice TLS configuration with WildFly

TLS WildFly Demo

A demo project as a playground for TLS and mutual TLS microservice configuration with WildFly.

The project is split into three branches:

• initial-commit: This branch contains two Wildfly Microservices (frontend and backend) without TLS enabled. These microservices can be deployed using WildFly Helm Charts. The frontend microservice is exposed via router working with edge TLS termination.

• external-traffic: This branch contains the changes applied on top of initial-commit to secure the external traffic with one way TLS. The required certificates need to be manually created under tls-wildfly-demo-frontend/deployment/tls.

• mutual-tls: This branch contains the changes applied on top of external-traffic to secure the communication between frontend and backend microservices using mutual TLS. The required certificates need to be manually created under tls-wildfly-demo-frontend/deployment/tls and tls-wildfly-demo-backend/deployment/tls. See instructions in the following sections.

Important

This demo uses Self-signed SSL certificates, which are not advisable for use in production environments due to their inherent security risks. For production environments, it is strongly recommended to use certificates issued by a trusted third-party Certificate Authority (CA).

Prerequisites

• An OpenShift cluster. You can get one for free at https://developers.redhat.com/developer-sandbox

• Install Helm Charts https://helm.sh/docs/intro/install/

• Install WildFly Helm Charts:

  $ helm repo add wildfly https://docs.wildfly.org/wildfly-charts/

• Optional ./jq https://jqlang.github.io/jq/

Default configuration

Checkout the initial-commit branch.

1. Deploy the frontend:

   $ helm install tls-wildfly-demo-frontend \
     -f ./tls-wildfly-demo-frontend/deployment/charts/helm.yaml wildfly/wildfly

2. Deploy the backend:

   $ helm install tls-wildfly-demo-backend \
     -f ./tls-wildfly-demo-backend/deployment/charts/helm.yaml wildfly/wildfly

3. Wait for the deployments to finish:

   $ oc get deployment tls-wildfly-demo-frontend -w
   NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
   tls-wildfly-demo-frontend   1/1     1            1           5m22s
   $ oc get deployment tls-wildfly-demo-backend -w
   NAME                       READY   UP-TO-DATE   AVAILABLE   AGE
   tls-wildfly-demo-backend   1/1     1            1           5m50s

4. Access the frontend endpoint:

   $ curl -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings | jq
   {
     "hostname": "tls-wildfly-demo-frontend-66b9bb8b84-5lmpb",
     "localAddress": "10.128.10.116",
     "localPort": 8080,
     "message": "Hello From WildFly Frontend Microservice!"
   }

5. Access the backend microservice from the frontend endpoint:

   $ curl -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings/backend | jq
   {
     "hostname": "tls-wildfly-demo-backend-99b7f78d4-vwc9t",
     "localAddress": "10.128.10.117",
     "localPort": 8080,
     "message": "Hello from WildFly Backend Microservice!"
   }

Note

In the above curl commands, the -k, --insecure option was not used. This is because the route is configured using the CA authority available on my developer sandbox cluster.If your cluster is not using a trusted CA authority, you will need to use the -k, --insecure option to bypass the certificate validation.

The frontend microservice is accessed using TLS with the termination in the route. The communication between the route and the frontend is not encrypted. On the second request, the frontend microservice calls the backend microservice also without TLS enabled. The communication is secured only from your local machine to the route. Notice the local port is 8080, which is the HTTP port configured in WildFly.

Securing the external traffic

Checkout the external-traffic branch.

1. Navigate to tls-wildfly-demo-frontend/deployment/tls

   $ mkdir tls-wildfly-demo-frontend/deployment/tls
   $ cd tls-wildfly-demo-frontend/deployment/tls

2. Generate the required certificates:

   $ keytool -noprompt -genkeypair -keyalg RSA -keysize 2048 \
     -validity 365 \
     -dname "CN=tls-wildfly-demo-frontend" \
     -ext "SAN:c=DNS:localhost" \
     -alias wildfly.frontend.service \
     -storepass secret \
     -keypass secret \
     -keystore wildfly.frontend.service.keystore.pkcs12

3. Create a secret to mount the keystore into the frontend microservice:

   $ oc create secret generic tls-frontend-secret \
   --from-file=wildfly.frontend.service.keystore.pkcs12 \
   --from-literal=key-trust-store-password=secret

4. Back to the root frontend microservice maven project directory and upgrade the frontend helm chart to pick up the new configuration:

   $ cd ../../
   $ helm upgrade tls-wildfly-demo-frontend \
     -f ./deployment/charts/helm.yaml wildfly/wildfly

5. Start a new build to pick up the server changes we have applied in this branch:

   $ oc start-build tls-wildfly-demo-frontend-build-artifacts

6. Once the build finishes and the new frontend pod starts, invoke the frontend endpoint using the route:

   $ curl -k -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings | jq
   {
     "hostname": "tls-wildfly-demo-frontend-5859695889-246pb",
     "localAddress": "10.128.10.200",
     "localPort": 8443,
     "message": "Hello From WildFly Frontend Microservice!"
   }

   This time the request arrived directly to the 8443 port on the pod, which is the HTTPS port configured in WildFly.

7. Verify it is also possible to reach out the backend from the frontend:

   $ curl -k -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings/backend | jq
   {
     "hostname": "tls-wildfly-demo-backend-99b7f78d4-vwc9t",
     "localAddress": "10.128.10.117",
     "localPort": 8080,
     "message": "Hello from WildFly Backend Microservice!"
   }

   This traffic is still unsecured and arriving to the 8080 port.

Enabling Mutual TLS between the frontend and backend

Checkout the mutual-tls branch.

1. From the root of the maven project, create the tls-wildfly-demo-backend/deployment/tls to generate the backend keystore and truststore:

   $ mkdir tls-wildfly-demo-backend/deployment/tls
   $ cd tls-wildfly-demo-backend/deployment/tls
   $ keytool -noprompt -genkeypair -keyalg RSA -keysize 2048 \
     -validity 365 \
     -dname "CN=tls-wildfly-demo-backend" \
     -ext "SAN:c=DNS:localhost,DNS:tls-wildfly-demo-backend-secure" \
     -alias wildfly.backend.service \
     -storepass secret \
     -keypass secret \
     -keystore wildfly.backend.service.keystore.pkcs12

2. Extract the backend certificate from the keystore:

   $ keytool -exportcert -keystore wildfly.backend.service.keystore.pkcs12 \
      -alias wildfly.backend.service \
      -keypass secret \
      -storepass secret \
      -file wildfly.backend.service.crt

3. From tls-wildfly-demo-frontend/deployment/tls directory, extract the frontend certificate:

   $ cd ../../../tls-wildfly-demo-frontend/deployment/tls
   $ keytool -exportcert -keystore wildfly.frontend.service.keystore.pkcs12 \
      -alias wildfly.frontend.service \
      -keypass secret \
      -storepass secret \
      -file wildfly.frontend.service.crt

4. Create the frontend truststore by importing the backend certificate:

   $ keytool -noprompt -keystore wildfly.frontend.service.truststore \
     -importcert -file ../../../tls-wildfly-demo-backend/deployment/tls/wildfly.backend.service.crt \
     -alias wildfly.frontend.service \
     -storepass secret

5. Delete the old secret and create a new one including the frontend keystore and truststore to mount them in the frontend microservice:

   $ oc delete secret tls-frontend-secret
   $ oc create secret generic tls-frontend-secret \
   --from-file=wildfly.frontend.service.keystore.pkcs12 \
   --from-file=wildfly.frontend.service.truststore \
   --from-literal=key-trust-store-password=secret

6. From tls-wildfly-demo-backend/deployment/tls directory, create the backend truststore by importing the frontend certificate:

   $ cd ../../../tls-wildfly-demo-backend/deployment/tls
   $ keytool -noprompt -keystore wildfly.backend.service.truststore \
   -importcert -file ../../../tls-wildfly-demo-frontend/deployment/tls/wildfly.frontend.service.crt \
   -alias wildfly.backend.service \
   -storepass secret

7. Create a secret to mount the backend keystore and truststore in the backend microservice:

   $ oc create secret generic tls-backend-secret \
   --from-file=wildfly.backend.service.keystore.pkcs12 \
   --from-file=wildfly.backend.service.truststore \
   --from-literal=key-trust-store-password=secret

8. At this point you should have the following files created on each deployment/tls directory for the frontend and backend:

   .
   ...
   ├── tls-wildfly-demo-backend
   │         ├── deployment
   │         │         └── tls
   │         │             ├── wildfly.backend.service.crt
   │         │             ├── wildfly.backend.service.keystore.pkcs12
   │         │             └── wildfly.backend.service.truststore
   ...
   └── tls-wildfly-demo-frontend
       ├── deployment
       │         └── tls
       │             ├── wildfly.frontend.service.crt
       │             ├── wildfly.frontend.service.keystore.pkcs12
       │             └── wildfly.frontend.service.truststore
   ...

9. Upgrade both Helm charts:

   $ cd ../../../
   $ helm upgrade tls-wildfly-demo-frontend \
     -f ./tls-wildfly-demo-frontend/deployment/charts/helm.yaml wildfly/wildfly
   $ helm upgrade tls-wildfly-demo-backend \
     -f ./tls-wildfly-demo-backend/deployment/charts/helm.yaml wildfly/wildfly

10. Start new builds for the backend and frontend to pick up the new server changes incorporated in this branch:

    $ oc start-build tls-wildfly-demo-frontend-build-artifacts
    $ oc start-build tls-wildfly-demo-backend-build-artifacts

11. Once the build finishes and the new frontend pod starts, invoke the frontend endpoint using the route:

    $ curl -k -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings | jq
    {
      "hostname": "tls-wildfly-demo-frontend-685d8df958-gxmvc",
      "localAddress": "10.128.10.247",
      "localPort": 8443,
      "message": "Hello From WildFly Frontend Microservice!"
    }

    The frontend service is receiving the request from the 8443 port, which is the HTTPS port.

12. Now invoke the backend endpoint from the frontend endpoint:

    $ curl -k -s https://$(oc get routes/tls-wildfly-demo-frontend  -o jsonpath='{.spec.host}')/greetings/backend | jq
    {
      "hostname": "tls-wildfly-demo-backend-564584964b-kx9fs",
      "localAddress": "10.128.10.248",
      "localPort": 8443,
      "message": "Hello from WildFly Backend Microservice!"
    }

    Now the traffic arrives to the backend microservice also via the secured 8443 port.

    You can also check you cannot access the backend service using TLS without having the backend certificate. For example, trying to access the backend from the frontend pod without specifying the certificates fails:

    $ oc rsh tls-wildfly-demo-frontend-685d8df958-gxmvc
    sh-4.4$ curl -v -k https://tls-wildfly-demo-backend-secure:8443/greetings
    *   Trying 172.30.210.119...
    * TCP_NODELAY set
    * Connected to tls-wildfly-demo-backend-secure (172.30.210.119) port 8443 (#0)
    * ALPN, offering h2
    * ALPN, offering http/1.1
    * successfully set certificate verify locations:
    *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
      CApath: none
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    * TLSv1.3 (IN), TLS handshake, Server hello (2):
    * TLSv1.2 (IN), TLS handshake, Certificate (11):
    * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
    * TLSv1.2 (IN), TLS handshake, Request CERT (13):
    * TLSv1.2 (IN), TLS handshake, Server finished (14):
    * TLSv1.2 (OUT), TLS handshake, Certificate (11):
    * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
    * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
    * TLSv1.2 (OUT), TLS handshake, Finished (20):
    * TLSv1.2 (IN), TLS alert, bad certificate (554):
    * error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
    * Closing connection 0
    curl: (35) error:14094412:SSL routines:ssl3_read_bytes:sslv3 alert bad certificate
    sh-4.4$

13. Clean up all the deployed resources by executing the following:

    $ helm uninstall tls-wildfly-demo-frontend
    release "tls-wildfly-demo-frontend" uninstalled
    $ helm uninstall tls-wildfly-demo-backend
    release "tls-wildfly-demo-backend" uninstalled