Repository navigation
Replies: 2 comments
|
Yes, this should be possible. You can keep the existing Ingress for The main caveat is Keycloak’s hostname configuration. Keycloak should have one canonical hostname, for example: KC_HOSTNAME=https://authorization.somedomain If TLS terminates at the Gateway, you should also configure the appropriate proxy headers and ensure that the proxy overwrites the A safe migration would be:
The old hostname can remain as a temporary compatibility endpoint, but it should not be treated as a second independent OIDC issuer. Users may also need to authenticate again because cookies are normally hostname-specific. I would avoid using References: Keycloak hostname configuration, Keycloak reverse proxy configuration, and GKE Gateway documentation. |
|
Thanks!
…On Wed, Sep 16, 2026 at 17:11 Rubén Teijeiro ***@***.***> wrote:
Yes, this should be possible. You can keep the existing Ingress for
auth.somedomain and create a regional GKE Gateway for
authorization.somedomain, with an HTTPRoute pointing to the same Keycloak
Service.
The main caveat is Keycloak’s hostname configuration. Keycloak should have
one canonical hostname, for example:
KC_HOSTNAME=https://authorization.somedomain
If TLS terminates at the Gateway, you should also configure the
appropriate proxy headers and ensure that the proxy overwrites the
X-Forwarded-* headers.
A safe migration would be:
1. Create and test the regional Gateway while keeping the old Ingress
active.
2. Change Keycloak’s canonical hostname and update the realm Frontend
URL if configured.
3. Update all OIDC clients and resource servers to use the new issuer.
4. Keep the old hostname available until existing tokens and sessions
have expired.
5. Remove the old Ingress after confirming that no clients still
depend on it.
The old hostname can remain as a temporary compatibility endpoint, but it
should not be treated as a second independent OIDC issuer. Users may also
need to authenticate again because cookies are normally hostname-specific.
I would avoid using hostname-strict=false just to support both hostnames
dynamically, since this can create security risks if host headers are not
strictly controlled.
References: Keycloak hostname configuration
<https://www.keycloak.org/server/hostname>, Keycloak reverse proxy
configuration <https://www.keycloak.org/server/reverseproxy>, and GKE
Gateway documentation
<https://docs.cloud.google.com/kubernetes-engine/docs/how-to/deploying-gateways>
.
—
Reply to this email directly, view it on GitHub
<#52511?email_source=notifications&email_token=AF7BKKOCZBLAQYZNUOLFLCD5PMT4BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUG4ZTGMBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-18473307>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AF7BKKKGSTTF3MGH4NJKW335PMT4BAVCNFSNUABHKJSXA33TNF2G64TZHMYTCMJSGU2TQOJ3IRUXGY3VONZWS33OHMYTANZXGQ3TENNBOYBA>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AF7BKKKIGRYOLZI7KKIEV3L5PMT4BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUG4ZTGMBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM>
and Android
<https://github.com/notifications/mobile/android/AF7BKKLYV7FOQMJI3IBILKL5PMT4BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOBUG4ZTGMBXUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>.
Download it today!
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Uh oh!
There was an error while loading. Please relo 8000 ad this page.
I currently have a keycloak 26.7.x deployed in GCP behind an ingress.
I have a few other applications also deployed in gcp that use this keycloak for SSO.
One of our upcoming requirements for these apps is the use of regional(vs global) resources. Since the other apps use keycloak, I figured keycloak probably needs to be handled first. My thinking to do this without a lot of downtime was to allocate a new regionial static ip, hostname, regional managed cert, gateway and http route(s) that point to the existing Service object, Deployment etc. In theory I think this should be possible.
So what I'm thinking is
old hostname auth.somedomain via ingress
new hostname authorization.somedomain via gateway api
If I can make keycloak be accessible via both names, I can switch the the apps that use keycloak for auth to the new name and then remove the old static ip, hostname, managed certificate and ingress.
Is this possible?
All reactions