Handling Sensitive Data with External Secrets

Integrate Helm with external secret management systems to securely inject sensitive credentials into your templates without exposing them in version control.

In this lesson, you will learn how to bridge Helm’s templating engine with external secret management systems to ensure your sensitive credentials never touch your version control system.

The Problem with Plaintext Secrets

When managing Kubernetes applications with Helm, it is common practice to store configuration in values.yaml files. However, sensitive data like database passwords or API keys should never be committed to Git. Even if you use base64-encoded Kubernetes Secret manifests, they remain plain text within your repository, creating a significant security vulnerability.

The External Secrets Pattern

Instead of defining secrets directly in your Helm charts, you define ExternalSecret resources. These act as a "pointer" to an external vault (such as AWS Secrets Manager, HashiCorp Vault, or Azure Key Vault).

When you deploy your Helm chart, the External Secrets Operator reads these pointers, fetches the actual value from your secure vault, and creates a native Kubernetes Secret object within the cluster on-the-fly.

Integration in Helm

To implement this, your Helm chart should contain a resource template that references the external provider. Instead of a hardcoded password, your values.yaml only needs a reference key:

# values.yaml
secrets:
  dbPasswordRef: "projects/my-app/secrets/db-password/versions/latest"

Your template then generates an ExternalSecret object:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: {{ .Release.Name }}-db-secret
spec:
  data:
  - secretKey: password
    remoteRef:
      key: {{ .Values.secrets.dbPasswordRef }}

By using this approach, your Helm chart remains generic and safe. The actual sensitive content is injected at runtime by the operator, keeping your Git repository clean of any production secrets. This decoupling allows you to rotate credentials in your vault without needing to re-deploy or update your Helm charts, as the operator will synchronize the changes automatically.

Key Takeaway: By using External Secrets with Helm, you decouple application configuration from secret storage, ensuring sensitive data is fetched securely at runtime rather than being hardcoded in your version-controlled charts.