<p>I created a helm chart which has <code>secrets.yaml</code> as:</p>

<pre><code>apiVersion: v1
kind: Secret
type: Opaque
metadata: 
 name: appdbpassword
stringData:
  password: password@1
</code></pre>

<p>My pod is:</p>

<pre><code>apiVersion: v1
kind: Pod
metadata:
  name: expense-pod-sample-1
spec:
  containers:
    - name: expense-container-sample-1
      image: exm:1
      command: [ "/bin/sh", "-c", "--" ]
      args: [ "while true; do sleep 30; done;" ]
      envFrom:
      - secretRef:
              name: appdbpassword
</code></pre>

<p>Whenever I run the <code>kubectl get secrets</code> command, I get the following secrets:</p>

<pre><code>name                                     Type                 Data    Age
appdbpassword                            Opaque               1      41m
sh.helm.release.v1.myhelm-1572515128.v1  helm.sh/release.v1   1      41m
</code></pre>

<p>Why am I getting that extra secret? Am I missing something here?</p>

Bhargav Behara
<p>Helm v2 <a href="http://technosophos.com/2017/03/23/how-helm-uses-configmaps-to-store-data.html" rel="noreferrer">used ConfigMaps</a> by default to store release information. The ConfigMaps were created in the same namespace of the Tiller (generally <code>kube-system</code>).</p>
<p>In Helm v3 the Tiller was removed, and the information about each release version <a href="https://helm.sh/docs/faq/changes_since_helm2/#release-names-are-now-scoped-to-the-namespace" rel="noreferrer">had to go somewhere</a>:</p>
<blockquote>
<p>In Helm 3, release information about a particular release is now
stored in the same namespace as the release itself.</p>
</blockquote>
<p>Furthermore, Helm v3 <a href="https://helm.sh/docs/faq/changes_since_helm2/#secrets-as-the-default-storage-driver" rel="noreferrer">uses Secrets as default</a> storage driver instead of ConfigMaps (i.e., it's expected that you see these helm secrets for each namespace that has a release version on it).</p>
