Use Dependency check chart to create randomly Generate Postgresql Password

[Homopatrol]

Fixes #89 and adds the ability to handle a persistent PostgreSQL password when performing a helm upgrade.

[davidkarlsen]

Is this really needed? See the bitnami chart for postgres and how it handles secrets.

[Homopatrol]

@davidkarlsen, I disagree, the postgresql password for the user deptrack is hard coded in the values.yaml - This is not good practice.

postgresql:
  enabled: true
  postgresqlUsername: deptrack
  postgresqlPassword: deptrack
  postgresqlDatabase: deptrack

Therefore my proposed changes allow the Postgresql secret to be created outside of the Postgresql chart. I believe DefectDojo chart has a good example of how to handle postgresql secrets.

secret-postgresql

{{- if .Values.createPostgresqlSecret -}}
apiVersion: v1
kind: Secret
metadata:
...
...
data:
{{- if .Values.postgresql.postgresqlPassword }}
  postgresql-postgres-password: {{ .Values.postgresql.postgresqlPassword | b64enc | quote }}
  {{ .Values.postgresql.secretKey }}: {{ .Values.postgresql.postgresqlPassword | b64enc | quote }}
{{- else }}
  {{- $postgresRandomPassword := randAlphaNum 16 | b64enc | quote }}
  postgresql-postgres-password: {{ $postgresRandomPassword }}
  {{ .Values.postgresql.secretKey }}: {{ $postgresRandomPassword }}
{{- end }}
.....

values.yaml

# create postgresql secret in defectdojo chart, outside of postgresql chart
createPostgresqlSecret: false
....
postgresql:
  enabled: true
....
  postgresqlUsername: defectdojo
  postgresqlPassword: ""
  postgresqlDatabase: defectdojo
  existingSecret: defectdojo-postgresql-specific
  secretKey: postgresql-password

django-deployment.yaml

...
        - name: DD_DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              {{- if eq .Values.database "postgresql" }}
              name: {{ .Values.postgresql.existingSecret }}
              key: {{ .Values.postgresql.secretKey }}
..

[davidkarlsen]

We can drop the default credentials. But the postgres chart is a child chart handled by bitnami - so see what they have in place for this.

[Homopatrol]

@davidkarlsen Yes but Postgresql doesn't reuse it's Chart generated secret when performing a Helm Upgrade #6731

The first password generated is the correct value and after re-installing, the secret would get populated with a new (wrong) password.

the "existingSecret" parameter assumes that you're managing the creation of the secret outside Helm.

By handling secrets outside of the chart using "existingSecret" this allows us to create the secret outside the Postgresql Chart and add the functionality to persist the secret when perfroming a Helm Upgrade.

Additionally, by adding options to re-create the secrets, it's easier to handle the lifecycle of the secrets: ie. the same secret when performing an upgrade so it will still hold the correct value.

[ildar-unlimit]

merge please, it is good decision like here https://github.com/DefectDojo/django-DefectDojo/blob/master/helm/defectdojo/values.yaml#L369

GitHub

django-DefectDojo/helm/defectdojo/values.yaml at master · DefectDojo/django-DefectDojo

DevSecOps, ASPM, Vulnerability Management. All on one platform. - DefectDojo/django-DefectDojo