A helm chart to help ease deployment on kubernetes clusters. At the moment it’s only designed to run as a single “node” but will work on adding horizontal scaling in time. Thought others might find it a useful.
I am fairly new to creating helm charts, so feel free to comment, critique, or contribute!
Thank you for taking the time to look through my chart’s source. I appreciate the thoughtful critiques and will implement them shortly. I’ll also be looking at your chart to learn from, thanks for sharing! In response to each of your points:
Good call on using a dependency for postgres; I did not know of this functionality or think to look for it.
In hindsight storing the config file in a
Secretinstead of aConfigMapis obvious, thanks for pointing that out.The reason I opted to require creating a
Secretwas the concern of storing secrets invalues.yamlin plaintext. In my opinion secrets invalues.yamlis a potential attack vector and an unneeded liability (not that I did much better storing secrets in aConfigMap). This does bring up the concern of secrets being stored in the bash history as well now I think of it. Trying to look up best practices on the matter I can’t find anything except don’t commit yoursecrets.yamlto a repo haha. Is this generally considered an acceptable risk?Generally, allowing secrets to be inserted through the
values.yamlis an ease-of-install feature, it’s technically no more or less safe than requiring secrets to be created manually. The one place it makes a difference is in GitOps, since having them only invalues.yamlmeans pushing them into git.Normally, the best practice is to have secrets as two sets of inputs in your
values.yaml;username/password/apikey/etc for cleartext inputexistingSecretwithexistingSecretKey/existingSecretUsernameKey/etc for users that want to handle the secrets themselves