[bitnami/harbor] Enable zero-secret output

[meln5674]

Description of the change

This patch makes the following changes:

• Added value trivy.existingEnvVarsSecret
• Added value jobservice.existingEnvVarsSecret
• Moved redis URL from jobservice config secret to env vars secret
• Switched jobservice config from Secret to ConfigMap now that no sensitive values are present
• Don't create core service if it would be empty

Benefits

It is now possible to deploy the chart while creating all secrets out-of-band (i.e. kubectl). This means that no sensitive values are required to be in the values.yaml. This is more secure when running via GitOps.

Because the jobservice configuration no longer contains the (potentially) sensitive redis URL, it can be stored as a ConfigMap, which makes it easier to view.

All changes should be backwards compatible.

Possible drawbacks

None known.

Applicable issues

• fixes [harbor] Allow providing all secrets out-of-band #25399

Additional information

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)

[carrodher]

Thanks for your contribution, could you please rebase from main? There is an issue with one of the GH actions which is totally unrelated to your PR but will require to use the latest changes in the main branch

[meln5674]

Let me know if there's anything needed on my end besides the rebase to get the check to pass.

[javsalgar]

It seems that your branch is 31 commits behind main, could you sync your fork? The issue with the action should be fixed by then

[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.

[meln5674]

Please excuse my impatience, but its been 3 weeks since I've made the requested change, and all checks are passing. I rebased again yesterday. Please let me know if there are any further obstacles to merging that I can address.

[dgomezleon]

Thanks a lot for contributing and sorry for the delay. I apply a couple of suggestions. Could you please take a look?

[dgomezleon]

Suggested change

	## `REGISTRY_CEDENTIAL_PASSWORD` (required),
	## `REGISTRY_CREDENTIAL_PASSWORD` (required),

[dgomezleon]

This two variables are not use fot the same purpose (a bit confusing I think). I suggest this change:

Suggested change

	{{- if or (not .Values.core.existingSecret) (not .Values.core.secretName) }}
	{{- if (not .Values.core.existingSecret) }}

[meln5674]

You are correct that they are used for different things, however, if you check the data section, you'll notice that if both secrets are provided, the secret in this file will be empty. While this is not technically "wrong", it does mean that it A) still creates a secret (when the goal of the PR is to enable it to output zero secrets) and B) prevents the user from creating a secret out-of-band with the same name (as the chart would overwrite it). By checking if at least one of those secrets is not already provided, we can avoid outputting an unnecessary empty secret.

Let me know if I've misunderstood your comment.