Using default passwords is that it makes it very easy for ppl to install a chart with minimal changes or minimal extra values added. However, this is a Security risk when ppl start to try the chart i.e. and later decide to use it in production.
We supply default passwords here:
rabbitmq.auth.password
rabbitmq.auth.erlangCookie
postgres.postgresqlPassword
onlyoffice.jwtSecret
Enable redis auth by default (solved in !252 (merged))
Also:
How to deal with passwords in values-local.yaml.example ? Should we use a string like CHANGE_ME which can get replaces with a single sed cmd ? Or should we also don't specify any defaults there for the same reasons
Why don't we generate passwords during installation when no value is specified ?
1 of 6 checklist items completed
· Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Why don't we generate passwords during installation when no value is specified ?
I can't find the helm issue that I originally discussed re-usable helm secrets in. The bottom line is helm charts easily break on upgrades because if you don't execute them right, new passwords will get generated (breaking all kinds of things, often databases).
I think we should go for the simple solution of adding commented password fields in the values files as well as the example values-local files. So that would look like:
I have been looking into how Bitnami's approach to this is, because in general I found bitnami charts as a kind of reference of best practices for helm charts.
They do generate passwords if they are not specified.
Installation procdure looks like this (i.e. for mariadb:
$ kc create namespace test$ helm repo add bitnami https://charts.bitnami.com/bitnami$ helm -n test install my-release bitnami/mariadbNAME: mariaLAST DEPLOYED: Mon Apr 25 14:31:36 2022NAMESPACE: testSTATUS: deployedREVISION: 1TEST SUITE: NoneNOTES:CHART NAME: mariadbCHART VERSION: 11.0.0APP VERSION: 10.6.7** Please be patient while the chart is being deployed **Tip: Watch the deployment status using the command: kubectl get pods -w --namespace test -l app.kubernetes.io/instance=mariaServices: echo Primary: maria-mariadb.test.svc.cluster.local:3306Administrator credentials: Username: root Password : $(kubectl get secret --namespace test maria-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 --decode)To connect to your database: 1. Run a pod that you can use as a client: kubectl run maria-mariadb-client --rm --tty -i --restart='Never' --image docker.io/bitnami/mariadb:10.6.7-debian-10-r62 --namespace test --command -- bash 2. To connect to primary service (read/write): mysql -h maria-mariadb.test.svc.cluster.local -uroot -p my_databaseTo upgrade this helm chart: 1. Obtain the password as described on the 'Administrator credentials' section and set the 'auth.rootPassword' parameter as shown below: ROOT_PASSWORD=$(kubectl get secret --namespace test maria-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 --decode) helm upgrade --namespace test maria bitnami/mariadb --set auth.rootPassword=$ROOT_PASSWORD$ kubectl get secret --namespace test maria-mariadb -o jsonpath="{.data.mariadb-root-password}" | base64 --decodeded67sqj...%
I love the simplicity of installing a chart for testing.
I started this conversation because I am frustrated that I coldn't test-install our NC+OO chart successfully for the second time (see #1020 (closed) for the first time), and just want a simple, 2/3 lines of code that I can copy&paste and maybe add one or max. two additional values. Currently, the installation instructions are more complicated, you need to change values in 10 (!) places in our values-local.yaml file, and on top of this I can't get it installed. This is a waste of time for me.
We make it super easy to install this/our charts by generating passwords if not set, following the Bitnami example, including added documentation how to upgrade properly if the charts are used manually (see https://artifacthub.io/packages/helm/bitnami/mariadb#upgrading as example)
We specify passwords in Stackspin helmReleases anyhow, so your concern of upgrade failures doesn't apply for our usage in Stackspin.