Open vaaleyard opened 2 months ago
Hey @vaaleyard,
Yes this is intentional as we considered that for the database hostname it would be enough to store it as a configmap. There are no plans in the short term to change that. I'm leaving this issue open in case your suggestion shows community traction in order to implement it.
And is it possible to pass the other DATASOURCES_DEFAULT_*
variables as a secret? Like in the example above
Because in secret-env.yaml#L22 it uses the passboltEnv.secret
directly...
I think you would have problems with this function https://github.com/passbolt/charts-passbolt/blob/main/templates/_helpers.tpl#L67 that doesn't consider that the host could be stored in a secret.
+1 to using existing database and load necessary envs from secret
The only "important" vars I could set this way was these ones:
extraEnv:
- name: DATASOURCES_DEFAULT_PASSWORD
valueFrom:
secretKeyRef:
name: &secret passbolt-config-db-secret
key: password
- name: DATASOURCES_DEFAULT_USERNAME
valueFrom:
secretKeyRef:
name: *secret
key: username
- name: DATASOURCES_DEFAULT_DATABASE
valueFrom:
secretKeyRef:
name: *secret
key: username
- name: CACHE_CAKE_DEFAULT_PASSWORD
valueFrom:
secretKeyRef:
name: &secret passbolt-config-secret
key: CACHE_CAKE_DEFAULT_PASSWORD
At least these ones works.
Hello.
Thank you for your contribution. We are working on a fix for this issue and it will be included in the next release, which will be available in a few days.
I'm trying to use an external database as the passbolt db, and I want to pass its variables to fetch from a secret I have in the my kubernetes cluster.
I have a secret in kubernetes with four variables, which has the connection settings for the database:
My values file is something like this:
Troubleshooting the error message:
and going to _helpers.tpl#L67 it looks like I have to obligatory pass the HOST variable as plain... Wouldn't it be better to also allow it to pass as a secret variable? Because it doesn't make sense to also leave this var in plain text.