You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, this does not seem to work with the operator. We can set the variable only as a text based value - or leave it unset. We cannot redefine the environment variable on our own either, because we cannot provide any extraEnv-Style environment variable overrides.
{{- with .Values.existingSecret }}
valueFrom:
secretKeyRef:
name: {{ . }}
key: password
{{- else}}
value: {{ .Values.cmpassword | required "either existingSecret or cmpassword is required" | quote }}
{{- end }}
The situation with Postgres and Minio is a little more complex since the secret is cross referenced between the kestra chart itself and the sub charts. This Feature request does not address the affected secrets on both of those dependencies.
We are looking forward to your opinions on that topic.
Thank you very much.
The text was updated successfully, but these errors were encountered:
aresfkonrad
changed the title
Allow the use of an existingSecrets for superadmin, license, operator, s3, postgres
Allow the use of an existingSecrets for superadmin, license, operator basic auth etc
Oct 7, 2024
I think a less intrusive solution would be to allow passing arbitrary env variables to the operator deployment, this is what is done for all other deployment and would allow you to set the API key or basic auth env variable to anything: other env variables, secret or config map, ...
Feature description
As of now, the kestra operator does not allow the direct use of secrets for its configuration:
helm-charts/charts/kestra/templates/operator.yaml
Line 249 in 0d3cff8
For other components, we could figure out a hacky way to use existingSecrets for the super admin account:
for the kestra-ee license the following way:
etc.
Unfortunately, this does not seem to work with the operator. We can set the variable only as a text based value - or leave it unset. We cannot redefine the environment variable on our own either, because we cannot provide any
extraEnv
-Style environment variable overrides.A more elegant solution for all of these cases would be to allow the user to choose between a deployment using existingSecret and a deployment using plain strings. I found a relatively simple example here: https://stackoverflow.com/questions/74739625/can-we-define-env-variable-in-the-helm-charts-only-if-secrets-are-provisioned
The situation with Postgres and Minio is a little more complex since the secret is cross referenced between the kestra chart itself and the sub charts. This Feature request does not address the affected secrets on both of those dependencies.
We are looking forward to your opinions on that topic.
Thank you very much.
The text was updated successfully, but these errors were encountered: