bug: stop committing MySQL root password in Helm chart values

[devin-ai-integration]

Summary

helm/bankapp/values.yaml stored the MySQL root/app password in cleartext (Test@123) and templates/secrets.yml rendered it unconditionally into the deployed mysql-secret — the banking DB root credential was readable to anyone with repo or git-history access, no base64 decoding needed.

The chart no longer carries a credential. It now consumes an externally-managed Secret by default and only creates one when the operator explicitly supplies the values at install time:

secret:
  name: mysql-secret
  create: false          # chart does not manage the Secret; it must already exist
  data:
    MYSQL_ROOT_PASSWORD: ""
    SPRING_DATASOURCE_PASSWORD: ""

{{- if .Values.secret.create }}
  MYSQL_ROOT_PASSWORD: {{ required "...pass it at install time, never commit it" .Values.secret.data.MYSQL_ROOT_PASSWORD | b64enc | quote }}
{{- end }}

required means secret.create=true with an empty value fails the render rather than silently deploying an empty root password. The workload templates now reference {{ .Values.secret.name }} instead of the hardcoded mysql-secret, so the chart can point at an ESO/Sealed-Secrets/Vault-managed Secret under any name. helm/README.md documents both paths.

Not verified locally: no helm binary on the box and the release tarball host is off the network allowlist, so helm template/lint could not be run.

Follow-ups outside this change: the exposed Test@123 credential must be rotated and purged from git history, the app should stop using the DB root account, and kubernetes/secrets.yaml still commits the same password base64-encoded (separate manifest, separate finding).

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review