Closed schnapsidee closed 1 year ago
Hi @schnapsidee
IMO, this is clearly a must-have. external-secrets
seems like a wonderful solution for this. I may be wrong but I think there is no specific reason for this not to be done.
Perhaps @sgirones can provide some guidance
hey!
The initial root password is only relevant during the bootstrap process (on the first start and only by one of the pods).
After that, the credentials are persisted on the datastore and the values you provided to the surrealdb server are no longer used: you could change the root password from surreal sql
for example.
In the GKE deployment guide, I suggest deploying with surrealdb.auth=false
, create the root user with surreal sql
and then redeploy with surrealdb.auth=true
.
For convenience reasons in Dev or CI environments, I added the possibility to provide credentials as env vars, but given it's for ephemeral environments, I didn't want to overcomplicate things with Kubernetes secrets. In any case, I that's not the recommended way to deploy SurrealDB in production!
What do you think?
I see. I guess in that case, it's fine to not have a secret. I didn't really look into it too much. One of my colleagues just wanted to deploy it, I saw a clear text password and alarm bells were ringing. 😄
I'll close the issue then, thanks for your reply!
Currently, root user and password just get set as env vars from clear text yaml, but this information should really be stored in a secret. For one, the pod spec shouldn't contain clear text passwords and doing this via secrets would also allow getting secrets via external-secrets and do GitOps deployments without having clear text password stored in a repo.
I'd be happy to do a PR, just wanted to know if there's a specific reason this isn't done before I do the work.