Repository navigation
Questions on hostname setup with a reverse proxy and in cluster communication between services. #41088
Replies: 1 comment 6 replies
If it is set to true, then any backchannel urls generated by the server will be based upon the incoming request, without consulting the hostname setting.
Which realm operator?
Only backchannel requests will be dynamic. If you are accessing a url that includes /admin - that is an admin url and it will instead use the hostname-admin setting as you are seeing.
There's a limited set of urls that are considered backchannel requests, see the docs or also this discussion #37238
Are you trying to access the admin over both keycloak.keycloak.svc.cluster.local and local-auth.server.localdomain? If it's only keycloak.keycloak.svc.cluster.local then you should set the hostname-admin to that instead. If at any point you are trying to access an admin or front-end endpoint as both keycloak.keycloak.svc.cluster.local and local-auth.server.localdomain, then you can only do that with hostname-strict=false. See #16432 for discussion around why. |
Yes, but it may not provide all the functionality you are looking for.
#27660 (comment) seems like a good summary of the state of things. The only way to have multiple front-end urls is with hostname-strict=false - but the iss checking means that tokens cannot cross between urls. |
|
Not crossing the front end urls is an issue, but I think the larger issue for us is the front end vs backend url. Our tokens will end up with an issuer that is the front end url. But as mentioned, our stuff in cluster is going to talk to keycloak on the cluster namespance of http://keycloak.keycloak.svc.cluster.local. Given that we are on the reverse proxy with hostname-strict=false, the refresh token with the issuer of the front end url will not match the in cluster http://keycloak.keycloak.svc.cluster.local/ that is being called by the in cluster clients. |
And if you had a sigle front-end url this scenario should work with a hostname setting and hostname-backchannel-dynamic=true.
To state things a little differently. There basically isn't a concept of a backchannel when hostname-strict=false (without a hostname configured) - everything is dynamic. So what you think should be a backchannel is simply a different host to keycloak in this scenario. |
|
Agreed, I did test things with setting the realm front end url and that does solve the issue for a single front end, but I unfortunately have multiple front ends to support on one realm and don't think thats going to change. |
|
Did you find a solution? I'm having the same problem. Have been trying several configurations but none of them seems to work. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I have a Keycloak setup that is behind a reverse proxy. This previously was hostname-strict false and I am trying to set it up with a defined hostname. With how our cluster is setup, our in cluster internal services cannot use external names when talking to things(route out of proxy and then back into cluster). My understanding of the hostname documentation is that hostname-backchannel-dynamic should allow the backend url to not be resolved as the hostname.
The http values are for local only, where we don't have https setup.
How does the hostname-backchannel-dynamic config work? The in cluster url of keycloak in our setup is http://keycloak.keycloak.svc.cluster.local. So for in cluster applications talking to keycloak, thats the url its going to use. My assumption is that hostname-backchannel-dynamic would allow it to communicate with this url and not the hostname.
However, with the hostname configured and hostname-backchannel-dynamic set to true, the keycloak realm operator fails to update keycloak because it ends up trying to ping the public hostname admin url, which our setup will not allow.
From the logs, you can see it starts with http://keycloak.keycloak.svc.cluster.local, but ends up getting redirected to the hostname admin url, which will not work in cluster for me. Am I misunderstanding the usage of hostname-backchannel-dynamic ?Whats the proper way to do hostname setup when I have things talking to keycloak by their kubernetes cluster url?
All reactions