Im using bitnami helm chart for keycloak. and trying to achieve High availability with 3 keycloak replics, using DNS ping.
Chart version: 5.2.8
Image version: 15.1.1-debian-10-r10
Helm repo: https://charts.bitnami.com/bitnami -> bitnami/keycloak
The modified parameters of values.yaml file is as follows:
global:
image:
registry: docker.io
repository: bitnami/keycloak
tag: 15.1.1-debian-10-r10
pullPolicy: IfNotPresent
pullSecrets: []
debug: true
proxyAddressForwarding: true
serviceDiscovery:
enabled: true
protocol: dns.DNS_PING
properties:
- dns_query=keycloak.identity.svc.cluster.local
transportStack: tcp
cache:
ownersCount: 3
authOwnersCount: 3
replicaCount: 3
ingress:
enabled: true
hostname: my-keycloak.keycloak.example.com
apiVersion: ""
ingressClassName: "nginx"
path: /
pathType: ImplementationSpecific
annotations: {}
tls: false
extraHosts: []
extraTls: []
secrets: []
existingSecret: ""
servicePort: http
When login to the keycloak UI, after entering the username and password , the login does not happen, it redirects the back to login page.
From the pod logs I see following error:
0:07:05,251 WARN [org.keycloak.events] (default task-1) type=CODE_TO_TOKEN_ERROR, realmId=master, clientId=security-admin-console, userId=null, ipAddress=10.244.5.46, error=invalid_code, grant_type=authorization_code, code_id=157e0483-67fa-4ea4-a964-387f3884cbc9, client_auth_method=client-secret
When I checked about this error in forums, As per some suggestions to set proxyAddressForwarding to true, but with this as well, issue remains same.
Apart from this I have tried some other version of the helm chart , but with that the UI itself does not load correctly with page not found errors.
Update
I get the above error i.e, CODE_TO_TOKEN_ERROR
in logs when I use the headless service with ingress. But if I use the service of type ClusterIP with ingress , the error is as follows:
06:43:37,587 WARN [org.keycloak.events] (default task-6) type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=10.122.0.26, error=expired_code, restart_after_timeout=true, authSessionParentId=453870cd-5580-495d-8f03-f73498cd3ace, authSessionTabId=1d17vpIoysE
Another additional information I would like to post is , I see following INFO in all the keycloak pod logs at the startup.
05:27:10,437 INFO [org.jgroups.protocols.pbcast.GMS] (ServerService Thread Pool -- 58) my-keycloak-0: no members discovered after 3006 ms: creating cluster as coordinator
This sounds like the 3 members have not combined and not formed a keycloak cluster.
2
Answers
One common scenario that may lead to such a situation is when the node that issued the access code is not the one who has received the code to token request. So the client gets the access code from node 1 but the second request reaches node 2 and the value is not yet in this node’s cache. The safest approach to prevent such scenario is to setup a session sticky load balancer.
I suggest you to try setting the
service.spec.sessionAffinity
toClientIP
. Its default value isNone
.This part of the error
might indicate a mismatch in timekeeping between the server and the client