<p>Imagine a secret like this:</p>

<pre><code>apiVersion: v1
kind: Secret
metadata:
  name: {{ include "test-cicd.fullname" . }}
  labels:
    app.kubernetes.io/name: {{ include "test-cicd.name" . }}
    helm.sh/chart: {{ include "test-cicd.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
type: Opaque
data:
  secret.yaml: |
    {{ if eq .Values.env "prod" }}
    foo: bar-prod
    foo2: bar2_prod
    {{ else if eq .Values.evn "dev" }}
    foo: bar-dev
    {{ end }}
</code></pre>

<p>Is it possible to seal this using <a href="https://github.com/bitnami-labs/sealed-secrets" rel="noreferrer">Kubeseal</a>? 
Upon doing it now, I get <code>invalid map key: map[interface {}]interface {}{"include \"test-cicd.fullname\" .":interface {}(nil)}</code> which is probably because it is not a "valid" yaml file.</p>

<p>One thing that I tried was:
1. Removing the helm templating lines 
2. Generating the sealedsecret
3. Templating the sealedsecret using helm</p>

<p>But by doing this, the sealedsecret could not be decrypted by the cluster-side operator on deployment time. </p>

<p><strong>mkmik</strong> gave an answer to my question on <a href="https://github.com/bitnami-labs/sealed-secrets/issues/277" rel="noreferrer">Github</a>, so I'm quoting it here as well just for the records. </p>

<hr>

<p>So, you're composing a secret value with client-side templating.
Parts of your secret.yaml file are secret, yet parts must be templating directives (the if) and hence cannot be encrypted.</p>

<p>You have two options:</p>

<ol>
<li><p>you encrypt your secrets somehow using some client-side vault software, possibly with helm integration (e.g. <a href="https://github.com/futuresimple/helm-secrets" rel="noreferrer">https://github.com/futuresimple/helm-secrets</a>). That requires every user (and CI environment) that applies that helm chart, to be able to decrypt the secrets.</p></li>
<li><p>you re-factor your secrets so that secrets are "atomic", and use sealed-secrets to benefit from its "one-way encryption" approach, which allows your devops users (and CI automation) to apply the helm charts without ever seeing the secret values themselves.</p></li>
</ol>

<p>The rest of this answer assumes you picked option (2)</p>

<hr>

<p>Now, since you decided to use Helm, you have to deal with the fact that helm templates are not json/yaml files, but instead they are Go templates, and hence they cannot be manipulated by tools designed to manipulated structured data formats.</p>

<p>Luckily, kubeseal has a --raw command, that allows you to encrypt individual secret values and put them manually in whatever file format you're using to describe your k8s resources.</p>

<p>So, assuming you want to create a Helm template for SealedSecrets resource, which takes the name and label values as paramters, and also chooses which secrets to put also based on boolean prod/dev parameter, this example might work for you:</p>

<pre><code>apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: {{ include "test-cicd.fullname" . }}
  annotations:
    # this is because the name is a deployment time parameter
    # consider also using "cluster-wide" if the namespace is also a parameter
    # please make sure you understand the implications, see README
    sealedsecrets.bitnami.com/namespace-wide: "true"
  labels:
    app.kubernetes.io/name: {{ include "test-cicd.name" . }}
    helm.sh/chart: {{ include "test-cicd.chart" . }}
    app.kubernetes.io/instance: {{ .Release.Name }}
    app.kubernetes.io/managed-by: {{ .Release.Service }}
type: Opaque
spec:
  template:
    metadata:
      labels:
        app.kubernetes.io/name: {{ include "test-cicd.name" . }}
        app.kubernetes.io/instance: {{ .Release.Name }}
        app.kubernetes.io/managed-by: {{ .Release.Service }}
  encryptedData:
    {{ if eq .Values.env "prod" }}
    foo: AgASNmKx2+QYbbhSxBE0KTa91sDBeNSaicvgBPW8Y/q/f806c7lKfF0mnxzEirjBsvF67C/Yp0fwSokIpKyy3gXtatg8rhf8uiQAA3VjJGkl5VYLcad0t6hKQyIfHsD7wrocm36uz9hpH30DRPWtL5qy4Z+zbzHj8AvEV+xTpBHCSyJPF2hyvHXTr6iQ6KJrAKy04MDwjyQzllN5OQJT2w4zhVgTxXSg/c7m50U/znbcJ1x5vWLXLSeiDRrsJEJeNoPQM8OHmosf5afSOTDWQ4IhG3srSBfDExSFGBIC41OT2CUUmCCtrc9o61LJruqshZ3PkiS7PqejytgwLpw/GEnj2oa/uNSStiP9oa9mCY6IUMujwjF9rKLIT456DlrnsS0bYXO2NmYwSfFX+KDbEhCIVFMbMupMSZp9Ol2DTim5SLIgIza/fj0CXaO3jGiltSQ0aM8gLSMK9n3c1V+X5hKmzMI3/Xd01QmhMmwqKp+oy21iidLJjtz67EiWyfIg1l7hiD5IIVlM9Gvg3k67zij5mOcXPkFnMmUQhQWxVKgAf4z8qEgprt03C+q+Wwwt25UDhQicpwoGtVQzU5ChJi09ja5LeW4RrvDf2B5KRp9HXoj1eu93MMl1Kcnx+X7uVT5OqQz28c4wOLT4FDItFzh8zREGZbiG/B3o1vI8MmwvxXj++pQ7SfBxoz9Xe8gmQ7BuXno=
    foo2: AgAkaTBYcESwogPiauZ15YbNldmk4a9esyYuR2GDt7hNcv+ycPLHmnsJcYs0hBtqucmrO3HbgCy/hQ6dMRCY12RA7w7XsFqNjZy3kavnhqwM6YkHntK2INwercRNQpO6B9bH6MxQTXcxfJbPqaPt30iTnTAhtpN47lueoyIoka4WWzwG/3PAikXhIlkTaq0hrclRJHRqg4z8Kmcaf5A/BRL2xX8syHbjA7MK9/OoK+zytv+LGrbLLHUtuhNNNQ2PG9u05rP6+59wRduQojEDtB9FTCa+daS+04/F4H1vi6XUNnjkK+Xna1T2Eavyuq2GieKj/7ig96et/4HoTAz44zwVhh8/pk0IFC8srcH3p+rFtZZmjvbURrFahEjFZbav3BDMBNhrU8SI3MDN0Abiyvz4vJJfSxIYcyLD1EQ507q7ZXrqYN/v1EiYgYUACi0JGxSWHB9TlCkZOAdCl+hroXEhBN2u5utLJ12njBQJ8ACNQDOYf+CmtV0y7foCZ6Aaap0pV7a8twyqK8c17kImzfi102Zel8ALfLAzdAXBV9c1+1pH76turnTCE33aSMQlaVF3VTmFQWqB8uIO/FQhZDPo8u/ki3L8J31nepup4/WE7i59IT0/9qGh2LKql4oAv6v4D7qtKziN6DvG7bsJlj14Dln0roiTfTWEEnBqdDER+GKZJlKayOWsPQdN0Wp+2KVfwLM=
    {{ else if eq .Values.evn "dev" }}
    foo: AgAkaTBYcESwogPi..........
    {{ end }}
</code></pre>

<p>An alternative approach would be to have two templates, one for prod and one for dev and use Helm templating logic to pick the right file depending on which environment you're deploying to.</p>

<p>Anyway, each of those base64 blobs can be produced with:</p>

<pre><code>$ kubeseal --raw --scope namespace-wide --from-file=yoursecret.txt
</code></pre>

<p>Pro-tip, you can pipe the secret if it's not in a file:</p>

<pre><code>$ echo -n yoursecret | kubeseal --raw --scope namespace-wide --from-file=/dev/stdin
</code></pre>

<p>Then you have to paste the output of that command into your Helm Go template.</p>
