All Keycloak application traffic is to a single port. This combines both admin and non-admin access as well as both proxy and non-proxied access - this complicates proxy configuration and makes Keycloak more difficult to secure properly.

Splitting the admin and non-admin access is unfortunately difficult based upon what is currenlty supported in Quarkus. While it's easy enough to start a new port, getting all of the configuration, and in particular the https configuration wiring, the same is not easy - we'd need some kind of enhancement to support this.

We could focus just on the proxy / non-proxy split instead:

• Optionally (and by default?) have the "main" port perform a hostname check (as suggested by @vmuzikar) such that access to non-public endpoints is allowed for only the relevant admin hostname and/or another option that explicitly enables non-public endpoints over the proxy port.

  • We'd expect only proxies to communicate with this port - via either the trusted proxy addresses option or in Kubernetes environments, where fixed ips aren't ideal, we'd document using a NetworkPolicy.

• Optionally expand the management port to be the “Non-proxy or backchannel” port - meaning we expose all of our endpoints [1] there as well. Since none of the proxy options are supported there, this traffic cannot specify proxy-headers nor a client cert, etc.

  • We'd need to tweak our client cert lookup logic to account for this scenario. We'd configure the provider by port - or just always use the quarkus/vertx provider for the management port.
  • The need for mtls with client auth required on the non-proxy port would be a problem. If the main port were also https, the user could enable http and elect to generally expose the health endpoints (which would require additional proxy configuration in the case that admin hostnames are not used).
  • Allowing the http-management-relative-path to be set differently than the http relative path would not work in this scenario.

[1] this mainly involves mounting the main router as a subrouter on the management router - but there are of course additional path and probably filter concerns.