Hostname configuration in production #20739

nicolas-goudry · 2023-06-02T09:06:54Z

nicolas-goudry
Jun 2, 2023

Hi,

We were using Keycloak 16 since about 2 years and decided that it was time to migrate to the latest Keycloak. We did so without any major issues, but we have a problem with the hostname-related configuration.

We’re deploying Keycloak to Kubernetes on GKE (without the Operator because we don’t want any alpha resources in our cluster) and the following Ingress configuration to prevent access to the admin console from the public domain:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: keycloak
  labels:
    app: keycloak
  annotations:
    kubernetes.io/ingress.class: 'gce'
    networking.gke.io/v1beta1.FrontendConfig: 'keycloak-http-to-https'
    cert-manager.io/cluster-issuer: 'letsencrypt-prod'
    acme.cert-manager.io/http01-edit-in-place: 'true'
spec:
  tls:
    - hosts:
        - auth.example.com
      secretName: auth.example.com-tls
  rules:
    - host: auth.example.com
      http:
        paths:
          # Only expose necessary paths
          - backend:
              service:
                name: keycloak
                port:
                  name: keycloak
            path: /realms/main/*
            pathType: ImplementationSpecific
          - backend:
              service:
                name: keycloak
                port:
                  name: keycloak
            path: /js/*
            pathType: ImplementationSpecific
          - backend:
              service:
                name: keycloak
                port:
                  name: keycloak
            path: /resources/*
            pathType: ImplementationSpecific

When we want to access the admin console, we create a port-forward to the keycloak Service and connect to the console from localhost. This worked fine with Keycloak 16, but doesn’t work with Keycloak 21…

I first tried to set the KC_HOSTNAME variable to localhost, but then the authentication stopped working from the deployed domain because it was trying to load assets from localhost…

I then set the KC_HOSTNAME to the deployed domain name auth.example.com, but it didn’t work as the assets were trying to be loaded from auth.example.com:8443, which is not the port on which the Ingress is listening…

The only configuration that worked is to set the KC_HOSTNAME_URL to https://auth.example.com. But it breaks our port-forward for two reasons:

we don’t expose the /realms/master/* path (as seen in the Ingress config), which effectively breaks the admin console as it tries to load /realms/master/protocol/openid-connect/3p-cookies/step1.html from auth.example.com (we get an expected 404 on this path)
after exposing all realms from the Ingress (changed /realms/main/* to /realms/*), assets succeed to load but the console is stuck on « Loading the Admin UI » with a 403 Forbidden trying to load /realms/master/protocol/openid-connect/login-status-iframe.html/init?client_id=security-admin-console&origin=https%3A%2F%2Flocalhost%3A9999 (my port-forward is on port 9999)

I tried to set the KC_HOSTNAME_ADMIN to localhost but it didn’t work either… I also added a web origin of https://localhost:9999 to the security-admin-console client of the master realm, without success.

Any clues on how to reproduce the legacy behavior of Keycloak 16?

nicolas-goudry · 2023-06-02T14:15:59Z

nicolas-goudry
Jun 2, 2023
Author

I think I found my answer by looking at the usage of KC_PROXY variable by the Kubernetes deployment example. Following the documentation to use a reverse proxy, I set the proxy in edge mode with strict hostname checking disabled and I removed the KC_HOSTNAME variable.

It’s now working like before (I guess). I can authenticate in my applications through deployed Keycloak as well as establish a port-forward to the keycloak Service through localhost.

0 replies

Navigation Menu

Repository navigation

Hostname configuration in production #20739

Uh oh!

{{title}}

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Hostname configuration in production #20739

Uh oh!

nicolas-goudry Jun 2, 2023

Replies: 1 comment

Uh oh!

nicolas-goudry Jun 2, 2023 Author

nicolas-goudry
Jun 2, 2023

nicolas-goudry
Jun 2, 2023
Author