FHi
Nice findings and definitely worth improving.
@Elio can you take a look into this?
Nice findings and definitely worth improving.
@Elio can you take a look into this?
FSince ZITADEL itself allows to define multiple yaml or provide all as one we should make sure the helm-chart also provides this flexibility.
EDefinitely! Thank you for the detailed outline. I'll have a deeper look tomorrow. We are always happy about and open for contributions 
ESince ZITADEL itself allows to define multiple yaml or provide all as one we should make sure the helm-chart also provides this flexibility.
Also Helm allows to provide multiple values files. So, also the helm config can be split up arbitrarily.
In my opinion, the only thing needed is to additionally pass the secretConfig via the
--steps flag, then all use cases should be covered? Also, it wouldn't be a breaking change, as config properties passed by --config--steps. Or am I missing something?BTW, I think we should have done that a long time ago, I'm sorry for the inconvenience @skeletorXVI
EConfig and secret keys don't have a file ending
To keep usage of the properties configSecretName and masterkeySecretName non breaking, we can rename (if exists) a file masterkey to masterkey.txt and zitadel-secrets-yaml to zitadel-secrets.yaml in the init container. Then we can freely change all files to have endings without breaking existing configs. What do you think about that?
ESo, the conclusion is:
- We should change config-yaml to config.yaml
- We should rename the file config-yaml in the init container if it exists
- We should pass the ZITADEL secret config via the --steps argument