Repository navigation
Replies: 2 comments 3 replies
|
Some thoughts:
|
|
I don't know what "backchannel" traffic is, so I can really comment on the first point. |
|
@pruivo - Reading your previous comment, you mention TLS passthrough, but once you do that you can't filter on the To be able to access and admin endpoint from outside of OpenShift, it needs to be an exposed route in OpenShift, I agree. What I've seen at customer setups is that they have different labels on the Routes that then end up on different ingresses, which then have different external firewall setting: One is accessible from the internet, another only internally. |
|
I meant an IP filter in Keycloak. |
|
I realize the initial discussion comment my dive in a little bit too much. More generally the situation today is that we logically have 4 different ways of accessing Keycloak:
And we support up to 3 ports:
In some scenarios you may be able to use https for public / admin access, and http for backchannel - or vice versa. But more than likely all of the non-management traffic is using the same port. Also the https and http ports are not differentiated - all of our proxy settings are currently applicable to both.
Here's what's been discussed for addressing this problem:
The first/last options have the same requirement for traffic restriction - either configuring our trusted proxies or when stable ips / ranges aren't available relying on network level restrictions like a Kuberentes NetworkPolicy. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
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.
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.
[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.
All reactions