Problem Description

Temporal Helm charts currently create Kubernetes Secrets inline with base64-encoded sensitive data (passwords, etc.) directly in the chart templates. While this works for basic deployments, it creates significant challenges in GitOps workflows where:

1. Security concerns: Sensitive data like database passwords are stored as base64-encoded strings in Git repositories, which provides minimal security since base64 is easily reversible
2. Centralized management: When using external secret management solutions, secrets must be created outside the Helm chart, breaking the centralized deployment and management approach
3. Compliance issues: Many organizations require encrypted secrets in version control, not just base64 encoding

Current State

The chart currently generates secrets like this (from server-secret.yaml):

apiVersion: v1
kind: Secret
metadata:
  name: {{ $secretName }}
type: Opaque
data:
  password: {{ $driverConfig.password | b64enc | quote }}

⚠️ This approach works for development and simple deployments but doesn't support external secret management systems.

Proposed Solution

Add support for extraObjects configuration to the Temporal Helm chart, similar to how other Helm charts handle this. This would allow users to inject custom resources that can generate secrets externally.

Use Cases

** ExternalSecretOperator**: Create ExternalSecret resources that fetch secrets from external providers (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault, etc.)
SealedSecrets: Use SealedSecret resources for encrypted secrets stored in Git
Other secret management tools: Support for any Kubernetes-native secret management solution