surrealdb / helm-charts

4 stars 5 forks source link

Root password should be in a secret #1

Closed schnapsidee closed 1 year ago

schnapsidee commented 1 year ago

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.

Odonno commented 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

sgirones commented 1 year ago

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?

schnapsidee commented 1 year ago

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!