Validate Secrets and ConfigMap Patterns in Helm

Secrets and ConfigMap Configuration

Helm charts commonly reference Kubernetes Secrets and ConfigMaps for configuration injection. The values.yaml file controls which secrets and configmaps are used, how they are mounted, and which environment variables are set.

Environment Variables Pattern

env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: database-url
  - name: LOG_LEVEL
    value: "info"
  - name: CONFIG_PATH
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: config-path

extraEnvVars: []

Volume Mounts Pattern

extraVolumes:
  - name: config-volume
    configMap:
      name: app-config
  - name: secret-volume
    secret:
      secretName: app-credentials

extraVolumeMounts:
  - name: config-volume
    mountPath: /etc/config
    readOnly: true
  - name: secret-volume
    mountPath: /etc/credentials
    readOnly: true

What Gets Validated

1. Type checks: env and extraEnvVars should be arrays, extraVolumes and extraVolumeMounts should be arrays
2. Structure: Environment variable entries should have name and either value or valueFrom
3. Secrets handling: Secret values should not be hardcoded in values.yaml (use external secrets or sealed secrets)

External Secrets Pattern

For production, secrets should not be stored in values files. Instead, use external secrets operators:

externalSecrets:
  enabled: true
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  data:
    - secretKey: database-url
      remoteRef:
        key: /prod/myapp/database-url

Common Anti-Patterns

• Hardcoding sensitive values directly in values.yaml
• Using plain value: for secrets instead of secretKeyRef
• Mounting secrets as writable volumes (should be readOnly: true)
• Not setting a defaultMode on secret volume mounts (defaults to 0644, consider 0400)