How can I best expose a secure Route?

[iocanel]

Description

This originates from Stack Overflow: https://stackoverflow.com/questions/69502561/quarkus-openshift-route-annotations#

Possible answer: https://docs.openshift.com/container-platform/4.8/networking/routes/secured-routes.html

We do not to improve the user experience and the documentation here.

Implementation ideas

No response

[quarkus-bot[bot]]

/cc @geoand

[geoand]

Is this just a matter of documentation?

[brunobaiano]

Is there anyway to create a route like this using tls just adding properties ?

When i set quarkus.openshift.route.expose=true it creates a http route. How can i change to something like this?

apiVersion: v1
kind: Route
metadata:
  name: route-passthrough-secured 
spec:
  host: www.example.com
  port:
    targetPort: 8080
  tls:
    termination: passthrough 
    insecureEdgeTerminationPolicy: None 
  to:
    kind: Service
    name: frontend

another real example from a route that we are using:

spec:
  host: myhost.com
  port:
    targetPort: 8080-tcp
  tls:
    insecureEdgeTerminationPolicy: Redirect
    termination: edge
  to:
    kind: Service
    name: my-service-api
    weight: 100
  wildcardPolicy: None

this generates https://myhost.com

[rquinio]

Not sure it's possible to avoid a quarkus.openshift.route.tls (and quarkus.kubernetes.ingress.tls) build time config to enable TLS & termination, because quarkus.http.ssl.certificate.* can change at runtime, so values are not known when generating the manifests ?

• With termination: passthrough a certificate would have to be issued for myhost.com
• With termination: reencrypt I'd expect a certificate to be issued instead for the K8s service hostname <service.name>.<service.namespace>.svc(.cluster.local) cf https://docs.openshift.com/container-platform/4.8/security/certificates/service-serving-certificate.html
• With termination: edge no ssl would be configured for quarkus.http

[brunobaiano]

But this options are not available right? Would be great if this exists!

[cescoffier]

Somewhat related to #24751.

[ia3andy]

I managed to make this work out of the box: src/main/kubernetes/openshift.yml

kind: Route
apiVersion: route.openshift.io/v1
metadata:
  name: <name>
spec:
  to:
    kind: Service
    name: <name>
    weight: 100
  port:
    targetPort: 8443
  tls:
    termination: passthrough
    insecureEdgeTerminationPolicy: Redirect
    wildcardPolicy: None

I use the -Dquarkus.profile=openshift, but you could make that default, also this is a self-signed certificate exposed via a secret. I could give more info on it if needed.

application.properties

%openshift.quarkus.kubernetes.deployment-target=openshift
%openshift.quarkus.openshift.route.expose=true
%openshift.quarkus.http.ssl.certificate.file=/mnt/https-secret/cert.pem
%openshift.quarkus.http.ssl.certificate.key-file=/mnt/https-secret/key.pem
%openshift.quarkus.http.insecure-requests=redirect
%openshift.quarkus.http.ssl-port=8443
%openshift.quarkus.openshift.ports."http".container-port=8443
%openshift.quarkus.openshift.ports."http".host-port=8443

[iocanel]

We could possible take quarkus.http.xxx into consideration in order to set tls termination and policy. @Sgitario I think that you have done some related work. Is this something that is feasible makes sense?

[Sgitario]

Personally, I would not overcomplicate the logic here to magically/automatically configure the Ingress tls termination when configuring the http.ssl ... properties. Mostly, because it's not that simple: the certificates need to be in a Kubernetes secret.

So, if users still want to proceed, they would have to manually configure the Ingress TLS following the guide: https://quarkus.io/version/main/guides/deploying-to-kubernetes#exposing-with-secured-ingress.

And, sooner than later, we'll have the Quarkus Cert-Manager extension (see request) that will automatically configure the HTTP SSL and the Kubernetes Ingress TLS properties. This extension will also generate the certificates in a secret by using the Cert-Manager operator. I would say that when available, this should be the recommended way for users to enable SSL.

[iocanel]

@Sgitario: Ok, still we need to expose all the required configuration properties so that users don't have to bring their own Route. Can you please ensuere we expose all the required configuration?

[Sgitario]

Yes, we need to expose these required configuration properties for secured routes. I've just added the "good first issue" label, just in case a newcomer wants to implement this. Otherwise, I will take a look when I have the capacity.