-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Management interface and port #23429
Comments
I completely agree. I will even push the requirement even further: it should be possible to move management endpoints to a separate port and interface. The current solution eases the routing strategy to avoid exposing the management endpoints to the public internet, but that was just a first step. |
And yes both interface / port should be able to use TLS / mTLS. mTLS is particularly interesting for the management endpoints as you can limit / scope who can call these APIs. |
Would there be an outline on how that would be implemented @cescoffier ? |
It's relatively straightforward. At the moment, Quarkus APIs are composed of two sub-routers: the application router and the non-application router (management). Both routers are registered on the primary router exposed by the Quarkus HTTP server. So, the distinction between management and application is already there. You can see this distinction already as the management router uses the "/q" prefix. Thus, to expose the management API on a separate interface/port, we need to start a second HTTP server (in quarkus-vertx-HTTP) on a particular interface/port and register the management router to this server. It would only be enabled by configuration. TLS configuration will also be configurable (I have some work in progress regarding TLS). |
cool maybe I will find some time in the next days :) |
Just as a question: Do I have to have a second |
I would have added the logic to the same recorder, to create a second http server (if needed). However, you can use a second recorder if that's simpler. I would start by locating where the management router is attached to the main router, and just before that check if we need to create a second server. |
+1 |
qq, any moevement with this ? I want to move away from spring boot, but this little enhancment is holding back. :) |
There are some ongoing discussions: https://quarkusio.zulipchat.com/#narrow/stream/187038-dev/topic/Non-application.20endpoints.20on.20different.20port. |
Hi @cescoffier and all, Thanks in advance! |
Yes, I never had the time to look into it. It's a change that requires a bit of thinking, such as allowing "routes" to decide if they want to be on the main /q router, or on the admin interface instead (or both). It's not hard, I just never had the time to do it. |
@cescoffier summarizing here the fixed points we agreed on 🙂 :
with this in mind we can try to prototype a follow-up step and count on some level of guidance to proceed. |
Description
I wanted to elaborate a bit on #7893.
Management port is security requirement/feature. I think - no matter of kubernetes or other context.
As part of health check we might expose some information we wouldn't like normally share.
Exposing health check or metrics on ingress or service is pointless as it is per pod.
I quite commonly run two different TLS/mTLS configurations, we might enable mTLS for main port, while I do not need it for health checks. And kubernetes do not support mTLS out of box for health checks.
Of course there is always some kind of custom tricky workaround, but it would be much easier to have such mgmt port and capability to bind some beans to it. As I can write much more internal functionality.
Currently it is kind of spinning up own web server and exposing everything we need on it. But really would be nice to have such thing integrated in overall design.
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: