What happened:
Even though the username for the redis connection can be configured and is considered within the code, it is not actually used. It always assumes the user default. I enabled usePassword and supplied a working username-password pair, but it only started working when I supplied the default user password (with the non-default username). This leads me to believe, that the username is completely ignored and only the password is actually important.
What you expected to happen:
The username should be considered. Otherwise only the default user can be used, making any kind of ACL configuration redundant.
How to reproduce it (as minimally and precisely as possible):
Use a Redis Database with ACL enabled and a user default and apple, both with their own distinct passwords.
Adjust the matchmaker configuration and create the corresponding secret (with the password of user apple)
Create a ticket and get io.grpc.StatusException: UNAVAILABLE: CreateTicket, id: coj74uis0ooc738qg5lg, failed to connect to redis: WRONGPASS invalid username-password pair or user is disabled.
What happened: Even though the username for the redis connection can be configured and is considered within the code, it is not actually used. It always assumes the user
default
. I enabledusePassword
and supplied a working username-password pair, but it only started working when I supplied the default user password (with the non-default username). This leads me to believe, that the username is completely ignored and only the password is actually important.What you expected to happen: The username should be considered. Otherwise only the default user can be used, making any kind of ACL configuration redundant.
How to reproduce it (as minimally and precisely as possible):
default
andapple
, both with their own distinct passwords.apple
)io.grpc.StatusException: UNAVAILABLE: CreateTicket, id: coj74uis0ooc738qg5lg, failed to connect to redis: WRONGPASS invalid username-password pair or user is disabled.
Config:
Anything else we need to know?: This is most probably a bug within any of the dependencies (redigo), as the construction of the redis string looks fine: https://github.com/googleforgames/open-match/blob/v1.8.1/internal/statestore/redis.go#L235
Output of
kubectl version
: Server Version: v1.27.11Cloud Provider/Platform (AKS, GKE, Minikube etc.): Hetzner Cloud
Open Match Release Version: 1.8.1
Install Method(yaml/helm): YAML with Kustomize