Improvement(helm chart): Allow use of redis existingSecret

[PurseChicken]

Description 📣

This addresses #4421

In summary, this PR removes REDIS_URL from the infisical deployment if .Values.redis.auth.existingSecret is populated.

The redis subchart will use auth.existingSecret and auth.existingSecretPasswordKey already without issue. The problem then becomes specifying the correct REDIS_URL string which includes the password. This now allows the user to specify their own REDIS_URL (via secret) by removing the REDIS_URL when redis.auth.existingSecret is set.

Type ✨

• Bug fix
• New feature
• Improvement
• Breaking change
• Documentation

Tests 🛠️

helm template --debug returns no issues. I have also packaged the chart using helm package and used it directly and it works exactly as it should.

---

• I have read the contributing guide, agreed and acknowledged the code of conduct. 📝

[maidul98]

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

[greptile-apps]

Greptile Summary

This PR enhances the Infisical standalone PostgreSQL Helm chart to support using existing Kubernetes secrets for Redis authentication. The change modifies the conditional logic in the deployment template to exclude the automatic REDIS_URL environment variable generation when redis.auth.existingSecret is configured.

The core modification is in helm-charts/infisical-standalone-postgres/templates/infisical.yaml, where the condition for injecting REDIS_URL changes from {{- if .Values.redis.enabled }} to {{- if and .Values.redis.enabled (not .Values.redis.auth.existingSecret) }}. This allows users to leverage the Bitnami Redis subchart's existing secret functionality while providing their own REDIS_URL (including password) through the kubeSecretRef mechanism.

The values.yaml file is updated with documentation explaining the new existingSecret and existingSecretPasswordKey options under the Redis configuration section. When existingSecret is specified, the password parameter is ignored, and users must provide the complete REDIS_URL via their own Kubernetes secret.

This change integrates well with the existing Helm chart architecture, maintaining backward compatibility while enabling better security practices. It addresses a legitimate limitation where users previously had to specify Redis passwords in plaintext within chart values or deploy Redis separately to use proper secret management.

Confidence score: 4/5

• This PR is safe to merge with minimal risk as it's a targeted improvement with clear conditional logic
• Score reflects solid implementation of a well-defined feature request with proper documentation
• Pay close attention to the template conditional logic in infisical.yaml to ensure it works correctly in all deployment scenarios

_{2 files reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}