Skip to content
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

Closed
evilezh opened this issue Feb 3, 2022 · 15 comments · Fixed by #30506
Closed

Management interface and port #23429

evilezh opened this issue Feb 3, 2022 · 15 comments · Fixed by #30506
Assignees
Labels
area/kubernetes area/vertx kind/enhancement New feature or request kind/epic Large issue with links to sub-issues triage/quarkus-3
Milestone

Comments

@evilezh
Copy link

evilezh commented Feb 3, 2022

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

@evilezh evilezh added the kind/enhancement New feature or request label Feb 3, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented Feb 3, 2022

/cc @geoand, @iocanel

@geoand
Copy link
Contributor

geoand commented Feb 4, 2022

cc @sberyozkin @cescoffier

@cescoffier
Copy link
Member

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.

@cescoffier
Copy link
Member

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.

@jogueber
Copy link

jogueber commented Feb 7, 2022

Would there be an outline on how that would be implemented @cescoffier ?
I could pitch in if help is needed since we need this as well

@cescoffier
Copy link
Member

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).

@jogueber
Copy link

jogueber commented Feb 7, 2022

cool maybe I will find some time in the next days :)
thanks @cescoffier

@jogueber
Copy link

jogueber commented Feb 23, 2022

Just as a question: Do I have to have a second VertxHttpRecorder
I get that I can have seperate BuildItem that registers everything from the framework router
But how do I start another server then ? @cescoffier

@cescoffier
Copy link
Member

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.

@mschorsch
Copy link
Contributor

+1

@evilezh
Copy link
Author

evilezh commented Apr 3, 2022

qq, any moevement with this ? I want to move away from spring boot, but this little enhancment is holding back. :)

@cescoffier
Copy link
Member

@andreaTP
Copy link
Contributor

Hi @cescoffier and all,
we have been discussing the importance of this feature in the Keycloak team, is there any progress on it?
Are you looking for contributions or anything else?

Thanks in advance!

@cescoffier
Copy link
Member

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.

@andreaTP
Copy link
Contributor

andreaTP commented Jun 7, 2022

@cescoffier summarizing here the fixed points we agreed on 🙂 :

  • start with implementing (only) one "management server/port"
  • routes have an option to be bound to management but default to the main
  • a secondary server will be spawned for the management port
  • the management port can be enabled/disabled

with this in mind we can try to prototype a follow-up step and count on some level of guidance to proceed.
Please feel free to suggest corrections to this summary if I missed miss-interpreted anything 🙏

@github-project-automation github-project-automation bot moved this from In Progress to Done in Quarkus Roadmap/Planning Mar 16, 2023
@quarkus-bot quarkus-bot bot added this to the 3.0 - main milestone Mar 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/kubernetes area/vertx kind/enhancement New feature or request kind/epic Large issue with links to sub-issues triage/quarkus-3
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

7 participants