Introduce Management Interface

[cescoffier]

This PR adds management interface support. It allows exposing selected routes (management routes) to a different HTTP server. It avoids exposing these management routes on the main HTTP server, which could lead to leaks and undesired access to these endpoints.

Enabling/Disabling the management interface is a build-time property. However, the interface, port, and SSL... are runtime values.

The management interface is not intended to be used using native transport (as high concurrency is rarely a need for these endpoints). Also, the access log and same site cookie are not supported yet.

The management interface does not expose plain and secured endpoints. It's either using HTTP or HTTPS.

At the moment are considered management routes:

• health routes (but not the health-ui)
• prometheus routes
• metrics routes

When deploying to Kubernetes and Openshift, the management port is also exposed.
The Promethues scrape url and the health checks probes are configured to use that management port.

Tasks:

• Kubernetes configuration when using the management interface (as the URLs change) - need Allow configuring port of http probes #30566
• Fix dev UI path to health and the health-ui path to health
• A lot more tests
• Fix scrape path for prometheus

Related issues

• Fix Management interface and port #23429
• Fix Secure the /q endpoint (or subset) in Prod more by default #25001
• Fix Separate binding/port config for non application endpoints #13602

[quarkus-bot]

/cc @ebullient (metrics,micrometer), @jmartisk (metrics)

[cescoffier]

I've rebased on top of the new main (jakarta).

[github-actions]

🙈 The PR is closed and the preview is expired.

[ebullient]

Docs suggestions

[rsvoboda]

I tried just few things with the app running against cescoffier:management-interface-3
based on https://code.quarkus.io/?e=smallrye-health&e=micrometer&e=resteasy-reactive&S=io.quarkus.platform%3A3.0&extension-search=origin:platform%20resteas with usage of 999-SNAPSHOT bom

Few observations:

A) quarkus.http.non-application-root-path=/qq is not reflected, health check is still on http://localhost:9000/q/health
I know the new doc says to use quarkus.management.root-path=/xyz. Current Quarkus users are used to the above property, there needs to clear message about the need for different property when using management interface - migration guide, release text.

B) quarkus.http.root-path is not reflected
https://quarkus.io/guides/all-config#quarkus-vertx-http_quarkus.http.non-application-root-path says Relative path (Default, q) → Non-application endpoints will be served from ${quarkus.http.root-path}/${quarkus.http.non-application-root-path}.
Similarly to the above point. Needs good message towards users.

C) existing guides
Guides for Health Checks, SmallRye Metrics, and Micrometer Prometheus should have pointer to the docs/src/main/asciidoc/management-interface-reference.adoc

D) Docs for root-path config for health / metrics / micrometer
Text rendered in https://quarkus.io/guides/all-config#quarkus-smallrye-health_quarkus.smallrye-health.root-path and similar parts for metrics/micrometer need to cover both quarkus.http and quarkus.management based exposure

E) Enabled by default or not ...
Should be enabled by default to provide "secured" experience?
Breaking change on the other hand ...

F) dev mode is stuck, had to kill-9 the process
my application.properties for the above app

quarkus.management.enabled=true

quarkus.http.root-path=/api
quarkus.http.non-application-root-path=/qq

Well, just quarkus.management.enabled=true is enough to get stuck in dev mode. After hitting Ctrl+C the process ( mvn quarkus:dev) doesn't end and I have to run kill -9 the process

[rsvoboda]

forgot to attach management-interface-thread-dump.txt

[sberyozkin]

@cescoffier Can you please have this test confirming the optional Basic authentication works ? I've noticed you have added SSL tests which is great but they don't confirm the actual HTTP authentication mechanisms are working

[sberyozkin]

@cescoffier I noticed AuthConfig was removed which was fine, but IMHO we really should have something available from the start, having an open management port in prod mode without any simple authentication is a problem. Complexity of the MTLS setup to have a secure management port access would indeed be rarely used if ever used (esp if we assume the browser will be used to access it).
We need to have a Basic Auth support from the start IMHO. You said Verx authentication would be used directly, not sure it is a good idea as it would prevent reusing Quarkus identity providers like JDBC/JPA to keep user name and passwords. It should not really bypass the actual Quarkus Security.

I can propose a fairly simple solution:

• Have ManagementAuthConfig group, but only copy AuthConfig.basic to it, so that if someone wants they just do quarkus.management.auth.basic=true
• If it is enabled then BasicAuthenticationMechanism is created (update the condition in HttpSecurityRecorder where it is created) and then in HttpSecurityRecorder.initPermissions, have PathMatchingHttpSecurityPolicy updated with one more PolicyMappingConfig (add new method to PathMatchingHttpSecurityPolicy to accept PolicyMappingConfig which will have basic authentication scheme requiring an authenticated access for the management root).

And that should be it for now, then users just will have to add security-jpa or security-jdbc, or set user name/password in application.properties with the file properties.

Would you like to give it a quick try, it will literally take 30 mins for you to complete.

In the future we can also update those policies to be applicable to specific ports only, I can handle the port related part separately.

[sberyozkin]

Also if for ex both management and application need Basic auth, then how to ensure that someone who passes the application level basic auth check can not access management, and vice versa, for that PolicyMappingConfig for management can in the future include a management role, it can be taken care of in the future

[cescoffier]

I agree that basic auth would be nice, but I don't have the time to do it right now.
Also, I've looked into hooking the quarkus security provider, and it requires a lot more work and adaptation than just using vertx auth.

[cescoffier]

My initial investigation really scared me. Can you @sergei make it happen then I'm happy to look.

[sberyozkin]

@cescoffier Can you clarify something please, what happens in HttpSecurityRecorder, does it affect the main router only or other routers such as the management router is also affected ?

[cescoffier]

Only the main router.

[sberyozkin]

@cescoffier Thanks, I started guessing it was the case, after getting the basic authentication activated only in the 404 case in the test which I understand now hits the main router only.
What exactly binds the main router to it, I don't see any obvious link,

I see in HttpSecurityProcessor:

@BuildStep
 @Record(ExecutionTime.RUNTIME_INIT)
    SyntheticBeanBuildItem initBasicAuth(
            HttpSecurityRecorder recorder,
            HttpBuildTimeConfig buildTimeConfig...) {
...
}

and

public HttpSecurityRecorder(RuntimeValue<HttpConfiguration> httpConfiguration, HttpBuildTimeConfig buildTimeConfig) {
        this.httpConfiguration = httpConfiguration;
        this.buildTimeConfig = buildTimeConfig;
 }

Both routers are created in VertxHttpRecorder but I lack some Vert.x HTTP extension knowledge to understand why HttpSecurityProcessor and HttpSecurityRecorder affect the main router only.
Can you clarify please ? It is obviously taking more than my 30 mins's assertion, so I'll lift my change request. I'll continue investigating the Quarkus Sec path anyway, but I'd appreciate some help related to this router binding, thanks

[cescoffier]

@sberyozkin You would need to completely duplicate the HttpSecurityRecorder because the input of that class are the main server configuration and not the management one. However, the authenticationMechanismHandler should be reusable (at 90%).

However, with a bit of modification, I believe we would be able to reduce the amount of duplication to almost nothing:

1 - modify the current recorder to extract the used value from the received configuration
2 - add a second recorded for the management interface doing the same
3 - extract the field containing these values and the authenticationMechanismHandler in a parent class.
4- call the new recorder when we configure the management interface

It's important to understand that the main and management servers are managed entirely separately at runtime, on purpose.

[sberyozkin]

@cescoffier Thanks, I'll try to get something working with a duplicate first just to get some feeling it actually works, and then we can optimize, will ping offline for some extra hints, but in any case, as I said, I don't want to hold this PR, my change request has been lifted