Skip to content

Streamlining Helm Templates for External Secrets with Prefix Variables or Functions

In this article, we tackle the challenge of managing multiple environments (like dev, prod, and specific phi branches) within a Kubernetes/Helm context when referencing external AWS secrets managed by Secret Manager. We aim to maintain clean code without repeating complex logic for determining environment-specific secret names throughout Helm templates, while adhering strictly to Markdown format guidelinesto keep the content professional and concise (less than 500 words).


The Challenge in Hand: Complex Prefix Determination within a Helm Template for External Secrets Management.

When deploying applications with multiple environments using AWS secrets manager, we often face an issue where different namespaces—beyond just dev and prod, such as ‘prod-phi’ branches—require distinct secret references:

    - secretKey: RdsDataUsername
      remoteRef:
        key: {{ or (eq .Release.Namespace "prod") (eq .Release.Namespace "prod-phi") | ternary "prod" "dev" }}/rds/data/primary

This long expression, necessary for setting up correct secret references based on the environment’s namespace (env), hampers readability and maintainability. The goal is to find a way to define this logic once in our Helm templates rather than repeating it multiple times across different resources or files within them.


Previous Post
How Argo CD Tracks Resources in Kubernetes Deploym
Next Post
How can I tell Helm Chart to ignore the default In