Quarkus-openshift extension should create a route to access separate management interface

[fedinskiy]

Description

I have an application[1], deployed on Openshift via Quarkus-openshift extension[2][4], which uses separate management interface[3]. After the deployment, there is no way to access the management interface from outside the cluster, since the extension creates a service[5] for application, but the route only points to the http port[6].

[1] git@github.com:fedinskiy/reproducer.git -b openshift-extension-management
[2] mvn clean install -Dquarkus.kubernetes.deploy=true -Dquarkus.openshift.route.expose=true -Dquarkus.kubernetes-client.trust-certs=true -Dquarkus.platform.version=999-SNAPSHOT -Dquarkus.platform.group-id=io.quarkus
[3] #30506
[4] https://quarkus.io/guides/deploying-to-openshift
[5]

$ oc describe service openshift-quickstart
Name:              openshift-quickstart
<...>
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:               <...>
IPs:               <...>
Port:              https  443/TCP
TargetPort:        8443/TCP
Endpoints:         <...>
Port:              http  80/TCP
TargetPort:        8080/TCP
Endpoints:         <...>
Port:              management  9000/TCP
TargetPort:        9000/TCP
Endpoints:         <...>

[6]

$ oc get route openshift-quickstart
|NAME                |HOST/PORT                           | PATH|SERVICES            |PORT|TERMINATION|  WILDCARD
|openshift-quickstart|openshift-quickstart<...>.apps.<...>|     |openshift-quickstart|http|           |  None

Implementation ideas

Ideally, there should be option like quarkus.openshift.management-route.expose=true to create a route to the management interface, if required.

[quarkus-bot]

/cc @Sgitario (kubernetes), @geoand (kubernetes,openshift), @iocanel (kubernetes,openshift)

[rquinio]

Which endpoint of the management interface do you need access from outside the cluster ?
One of the reasons of having a separate management interface was to avoid exposing internal info (metrics, health probe output, ...) outside, which could help an attacker.

[Sgitario]

There is already a property to specify the port name to expose: https://quarkus.io/guides/all-config.html#quarkus-kubernetes_quarkus.openshift.route.target-port

quarkus.openshift.route.target-port=management

I'm closing this issue for now. Feel free to reopen it, if you mean to achieve something else.

[fedinskiy]

@Sgitario thank you, but this option allows to create route to the management port instead of http port. My intention is to have access to both simultaneously, but I see no way to do it through this property.

@rquinio I understand, that external access may have security implications, that is why I suggest to add an optional property.

[Sgitario]

Since this raises security concerns, I doubt we should provide this option. Yet users can always provide their own Route resource that uses the management port in src/main/kubernetes/common.yml.

[fedinskiy]

@Sgitario security concerns for the suggested management route are exactly the same, as for disabled management interface, which is default in quarkus, no? Comparing with the current baseline, we just give the user an ability to make traffic flow through two routes instead of one.

[Sgitario]

@Sgitario security concerns for the suggested management route are exactly the same

Not really, because the management port is not publicly exposed.

[fedinskiy]

@Sgitario by default(without quarkus.management.enabled=true) the management interface (or management endpoints, if you prefer) can be accessed on port 8080, which is publicly exposed.

After the second thought, it looks like the best solution would be not to have a separate new property, but to allow quarkus.openshift.route.target-port to accept list instead of string, so the user can do something like -Dquarkus.openshift.route.target-port=management,http if she wants.

[Sgitario]

And the idea of quarkus.management.enabled=true is not to expose these endpoints along with the application endpoints, so I don't see the point of wanting to expose again these endpoints.

Still, if users wanted to do this, they would use quarkus.management.enabled=false or provide their own Route resource.

What I'm trying to say is that while I understand your feature request, I don't see a real use case for it.

After the second thought, it looks like the best solution would be not to have a separate new property, but to allow quarkus.openshift.route.target-port to accept list instead of string, so the user can do something like -Dquarkus.openshift.route.target-port=management,http if she wants.

The configuration for the application port and the management port (to be precise, the TLS configuration) is different, so we could not reuse the same route config for both.

[Sgitario]

What I'm trying to say is that while I understand your feature request, I don't see a real use case for it.

Having said this, if you strongly think that this is necessary. I'm ok to reopen this feature, so other users can request it as well, and if so, we will implement it in the future.