Openshift TLS edge termination not working with Payara server

34 views Asked by At

Problem

I have a jsf web application deployed in Payara community edition server (v5.2020.6). I have this application deployed in azure openshift by importing a deployment config yaml inside an openshift project. I want to access this application from the browser, so I configured an openshift service to expose the pods created by the deployment config. I also created a Route to make the application accessible via a Public Url by selecting this service that is exposing my application. I can access the application fine if I use secure route with Passthrough TLS termination which makes my web app seem like it is not secured in the client side because it is using the default payara certificate. So, I wanted to configure Edge TLS termination, use openshift's default certificate and send the decrypted traffic straight to the pod via port 8080 which is configured in my payara web server to handle the http traffic. I do not want to configure certificate on the payara server side if possible. This is the error I get:


Error

This page isn’t working
app-domain.ose-dev.com redirected you too many times.
Try deleting your cookies.
ERR_TOO_MANY_REDIRECTS

Service

    apiVersion: v1
    kind: Service
    metadata:
      name: my-app
    spec:
      externalTrafficPolicy: Cluster
      ports:
      - name: http-8080
        port: 8080
        protocol: TCP
        targetPort: 8080
      - name: https-8181
        port: 8181
        protocol: TCP
        targetPort: 8181
      - name: ssl-443
        port: 443
        protocol: TCP
        targetPort: 443
      - name: admin-listener-4848
        port: 4848
        protocol: TCP
        targetPort: 4848
      selector:
        name: my-app
  type: LoadBalancer

Route

apiVersion: route.openshift.io/v1
kind: Route
metadata:
  name: my-app
spec:
  port:
    targetPort: 8080 
  to:
    kind: Service
    name: my-app

Payara Server

http-listener-1 |  enabled and listening on port 8080
http-listener-2 |  enabled, secured and listening on port 8181
ssl-listener    |. enabled, secured and listening on port 443
No redirection from 8080 to any secure port (8181 or 443)

Questions

  • If we are using edge termination, and decrypted traffic is passing through the pods to the payara server, what could be the reason for redirects?
  • If the client is making https request, is the router when intercepting the request is it looking for port 443 in the service, or does it use whatever port we have configured on the route for the service.
  • For the Insecure traffic policy under routes, is this what the router does when it receives incoming traffic or is it for the traffic after the router routes the traffic to the service?
2

There are 2 answers

0
Mausam Shrestha On BEST ANSWER

So the problem was not related to the openshift infrastructure at all.

  • web.xml for my app had a security constraint that enforced secured transmission for all path (/* with https)
  • enabled auth-pass-through enabled for http-listener-1 protocol that allowed tls edger termination and allowed the traffic to pass through the pods.
1
David Ogren On

type: LoadBalancer is wrong in your service. That's not needed: your service is just for internal cluster traffic. Try deleting it. It also appears to be incorrectly indented, but I expect that's just a copy and paste error.

externalTrafficPolicy seems incongruous too. The idea is to have the route handle all the external traffic and the Service to be local online . Remove that line as well.

If that doesn't fix it, take my general approach to debugging network issues:

  • Verify that the container is serving the port correctly. Start with port-forward to just make requests to that pod directly. In your case setup port-forward and then just make requests from your local browser to 8080. That will tell you if your application is making the port forwards.
  • Try making those requests from a different container, such as a debug pod. This will tell you if it's something in the pod definition.
  • Try making those requests form a different container, but connecting to the service rather than the pod directly. This will tell you if it's something in the service definition.
  • Try making those requests from a different container, but connecting to the router. This will tell you if it's something in the router config.
  • Try making those requests externally. If this will tell you if it's a network issue/firewall issue.

In answer to your direct questions:

If we are using edge termination, and decrypted traffic is passing through the pods to the payara server, what could be the reason for redirects?

My guess is that the externalTrafficPolicy: cluster in the service is causing a redirect to be issued at the Service level. That's just a guess though because I haven't tried this combination of things.

If the client is making https request, is the router when intercepting the request is it looking for port 443 in the service, or does it use whatever port we have configured on the route for the service.

Whatever port you configure in the router. (targetPort)

For the Insecure traffic policy under routes, is this what the router does when it receives incoming traffic or is it for the traffic after the router routes the traffic to the service?

For when it receives incoming traffic.