[bitnami/common] Add global.security.allowEmptyPassword

[maxime1907]

Description of the change

Add an option global.security.allowEmptyPassword to bypass empty password verification checks when using external vaults/secrets that manages this part

Benefits

Creating via .Values.extraDeploy an ExternalSecret resource inside the bitnami release when upgrading from values based passwords to external vault secret based passwords

Possible drawbacks

None as it keeps backward compatibility if the field is not present

Applicable issues

None

Additional information

None

Checklist

• Chart version bumped in Chart.yaml according to semver. This is not necessary when the changes only affect README.md files.
• Variables are documented in the values.yaml and added to the README.md using readme-generator-for-helm
• Title of the pull request follows this pattern [bitnami/<name_of_the_chart>] Descriptive title
• All commits signed off and in agreement of Developer Certificate of Origin (DCO)

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[github-actions]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.

[maxime1907]

Any updates on this? @javsalgar

[github-actions]

This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.

[migruiz4]

Hi @maxime1907,
Could you please provide an usage example where this feature is used? Maybe a branch in your fork where we can see a real use case for this feature.

The helper common.errors.upgrade.passwords.empty is usually used alongside other helpers such as common.validations.values.mariadb.passwords.
It had a key role in the past before we implemented common.secrets.passwords.manage, since we previously tried to avoid the usage of the Helm lookup function.

For context, during upgrades, the helper common.secrets.passwords.manage will look for the existing (built-in) chart secret to recreate it without having to provide the passwords in the values, while during first installations it will use a randomly generated password unless the user provided one in the values.

I see two main inconveniences with this contribution:

• Calling the value allowEmptyPassword would be inaccurate, because the charts won't be deployed with empty passwords when set.
• What this PR does is skip the upgrade password check, but it does not prevent the chart from generating its built-in secret which could end up in different scenarios depending on the chart template:
  • The built-in Secret is recreated with a new random password, so the bootstrap password could be lost.
  • The deployment fails because the secret expects a password value that was not provided.

Additionally, in the benefits you mention:

Creating via .Values.extraDeploy an ExternalSecret resource inside the bitnami release when upgrading from values based passwords to external vault secret based passwords`

Isn't that already possible by using the existingSecret value?