Cockroachdb Connect Error: Requested user root is not authorized for tenant
Original message was deleted
FHow did you bootstrap the certs?
FAh I see if the top of my head the issue might be that cockroach tried to Eval the user out of the cert but cannot do that since none is included which might become a problem when ZITADEL opens the sql connection
FYeah, I think ZITADEL uses a different name
FSec.
FWe use two users
FOne for Schema stuff called root
FGitHub
ZITADEL - The best of Auth0 and Keycloak combined. Built for the serverless era. - zitadel/defaults.yaml at main · zitadel/zitadel
FAnd one to use the database called zitadel https://github.com/zitadel/zitadel/blob/main/cmd/defaults.yaml#L65
GitHub
ZITADEL - The best of Auth0 and Keycloak combined. Built for the serverless era. - zitadel/defaults.yaml at main · zitadel/zitadel
FWe have a compose example with a secure db and that generated the cert here https://github.com/zitadel/zitadel/blob/main/docs/docs/self-hosting/deploy/loadbalancing-example/docker-compose.yaml#L33
GitHub
ZITADEL - The best of Auth0 and Keycloak combined. Built for the serverless era. - zitadel/docker-compose.yaml at main · zitadel/zitadel
Fthis generates a cert for the zitadel_user (used in this example)
FGitHub
ZITADEL - The best of Auth0 and Keycloak combined. Built for the serverless era. - zitadel/example-zitadel-secrets.yaml at main · zitadel/zitadel
FHm need to think about that. Maybe @Elio or @adlerhurst have an idea
FHm care to share the command you used with the cockroach client to connect to the db?
FThanks for the insights
F@Elio what’s you take you have to best eye on helm
EI think you have a point there @Amine, lol.
EThe root cert is used for both users, which is fine, I guess. @adlerhurst does it make sense to move that property to a level higher in the config, as this is always the same for all users, I guess?
EBut there is just one client cert you can configure, which is then just used for the admin user, by default.
I think we should deprecate dbSslClientCrtSecret and split it to the properties dbSslAdminCrtSecret and dbSslUserCrtSecret which both default to dbSslClientCrtSecret for backwards compatibility. This should be fine, as TLS already needs to be enabled explicitly.
I think we should deprecate dbSslClientCrtSecret and split it to the properties dbSslAdminCrtSecret and dbSslUserCrtSecret which both default to dbSslClientCrtSecret for backwards compatibility. This should be fine, as TLS already needs to be enabled explicitly.
EDid I get that right @Amine? Then I'll create two issues on GitHub for this
AThe idea back then was that it's something you need to connect using the user and when we introduced the admin field we didn't want to break the configuration.