I have found a strange behavior in Keycloak when deployed in Kubernetes, that I can’t wrap my head around.
Use-case:
- login as admin:admin (created by default)
- click on Manage account
(manage account dialog screenshot)
I have compared how the (same) image (quay.io/keycloak/keycloak:17.0.0) behaves if it runs on Docker or in Kubernetes (K3S).
If I run it from Docker, the account console loads. In other terms, I get a success (204) for the request
GET /realms/master/protocol/openid-connect/login-status-iframe.html/init?client_id=account-console
From the same image deployed in Kubernetes, the same request fails with error 403. However, on this same application, I get a success (204) for the request
GET /realms/master/protocol/openid-connect/login-status-iframe.html/init?client_id=security-admin-console
Since I can call security-admin-console, this does not look like an issue with the Kubernetes Ingress gateway nor with anything related to routing.
I’ve then thought about a Keycloak access-control configuration issue, but in both cases I use the default image without any change. I cross-checked to be sure, it appears that the admin user and the account-console client are configured exactly in the same way in both the docker and k8s applications.
I have no more idea about what could be the problem, do you have any suggestion?
2
Answers
Try to set
ssl_required = NONE
in realm table in Keycloak database to your realm (master)So we found that it was the
nginx
ingress controller causing a lot of issues. While we were able to get it working withnginx
, viaX-Forwarded-Proto
etc., but it was a bit complicated and convoluted. Moving tohaproxy
instead resolved this problem. As well, make sure you are interfacing with the ingress controller overhttps
or that may cause issues with keycloak.