Add support for existing secret references

[drpsyko101]

What kind of change does this PR introduce?

This PR add support for using existing secret references #53, instead of exposing sensitive values in values.yaml. The user can also modify the secretRefKey should their existing secrets use different keys from the default values in the chart.

TLDR

• Add support for existing secret references
• User can modify secret key input name

Known issues

• db password may not be correctly encoded. To ensure compatibility, use password that are URL-safe (not using characters that can be URL-encoded like &, % etc.)
• dashboard password may not contain / character, otherwise kong may crash due to sed
• Testing existing refs in CI/CD is not possible for now due to symlink to values.example.yaml

[arpagon]

@CodiumAI-Agent /review

[CodiumAI-Agent]

PR Review

⏱️ Estimated effort to review [1-5]	4, due to the extensive changes across multiple files and the complexity introduced by handling secret references conditionally. The PR modifies deployment configurations in various services, which requires careful review to ensure that secret management is handled securely and correctly.
🧪 Relevant tests	No
🔍 Possible issues	Possible Bug: The conditional checks for secret references might lead to misconfigurations if not properly set in values.yaml, leading to potential runtime errors or misrouted secret values.
	Security Concern: There's a risk of exposing sensitive information if the conditional logic fails or if there are misconfigurations in the secret references.
🔒 Security concerns	No explicit vulnerabilities introduced, but the complexity of the changes requires careful validation to ensure that secrets are managed securely.

Code feedback:

---

relevant file	charts/supabase/templates/secrets/_helpers.tpl
suggestion	Consider adding error logging or warnings when .Values.secret.s3.keyId or .Values.secret.s3.accessKey are not set, as the current implementation silently fails by returning "false". This could help in debugging configuration issues. [important]
relevant line	{{- printf "false" -}}

---

relevant file	charts/supabase/templates/analytics/deployment.yaml
suggestion	To improve code readability and reduce duplication, consider creating a helper template function for generating the secretKeyRef block since it is repeated with slight variations across multiple deployment files. [important]
relevant line	name: {{ .Values.secret.db.secretRef }}

---

relevant file	charts/supabase/templates/db/deployment.yaml
suggestion	Ensure that the default values for secretRefKey (like "username", "password", "database") are documented clearly in the values.yaml to avoid configuration errors by the users. [medium]
relevant line	key: {{ .Values.secret.db.secretRefKey.username | default "username" }}

---

relevant file	charts/supabase/templates/storage/deployment.yaml
suggestion	Add validation in the Helm chart to check if the necessary keys (username, password, database) are provided when secretRef is used. This prevents deployment issues due to missing keys in the referenced secrets. [important]
relevant line	key: {{ .Values.secret.db.secretRefKey.username | default "username" }}

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

• When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

• With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

[drpsyko101]

Add validation in the Helm chart to check if the necessary keys (username, password, database) are provided when secretRef is used. This prevents deployment issues due to missing keys in the referenced secrets. [important]

Yeah, I think this can be improved by adding checks and error handling in the _helpers.tpl for affected deployments. @arpagon Should I add it in this PR or in the next one?

[arpagon]

Add validation in the Helm chart to check if the necessary keys (username, password, database) are provided when secretRef is used. This prevents deployment issues due to missing keys in the referenced secrets. [important]

Yeah, I think this can be improved by adding checks and error handling in the _helpers.tpl for affected deployments. @arpagon Should I add it in this PR or in the next one?

In the next one. We should discuss the release process, but I am considering this chart as non-production ready so we can streamline the process.