Extra secrets created when helm is used

Question

I created a helm chart which has secrets.yaml as:

apiVersion: v1
kind: Secret
type: Opaque
metadata: 
 name: appdbpassword
stringData:
  password: password@1

My pod is:

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

Whenever I run the kubectl get secrets command, I get the following secrets:

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

Why am I getting that extra secret? Am I missing something here?

Which helm version are you using? – Eduardo Baitello Nov 04 '19 at 12:18 — Eduardo Baitello, Nov 04 '19 at 12:18
@EduardoBaitello I am using 3.0.0 – Bhargav Behara Nov 04 '19 at 12:30 — Bhargav Behara, Nov 04 '19 at 12:30

score 21 · Accepted Answer · edited Dec 01 '21 at 16:31

21

Helm v2 used ConfigMaps by default to store release information. The ConfigMaps were created in the same namespace of the Tiller (generally kube-system).

In Helm v3 the Tiller was removed, and the information about each release version had to go somewhere:

In Helm 3, release information about a particular release is now stored in the same namespace as the release itself.

Furthermore, Helm v3 uses Secrets as default 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).

edited Dec 01 '21 at 16:31

anton1

25
2
10

answered Nov 04 '19 at 12:48

Eduardo Baitello

10,469
7
46
74

2

I would expect that when I use upgrade --install that I see only 1 secret and not 20 – Martin Kosicky Jan 30 '20 at 19:51
@MartinKosicky Helm 2 always created a new configMap for every release revision. The difference is only that Helm 3 is now using Secrets...If you have done a hundred upgrades, you will have a hundred revisions, and 100 Secrets consequently...You can see some examples [here](https://developer.ibm.com/blogs/kubernetes-helm-3/#release-storage-changed). Worth mentioning too that every time an install, upgrade, or rollback happens, the revision number is [incremented by 1](https://helm.sh/docs/intro/using_helm/#helm-upgrade-and-helm-rollback-upgrading-a-release-and-recovering-on-failure). – Eduardo Baitello Jan 30 '20 at 20:22
Yes I agree it shouldn't keep the old secrets (I don;t need them anyway) – Martin Kosicky Jan 31 '20 at 07:59
1

helm should create a new namespace and put these annoying secrets there – BMW Jul 30 '20 at 09:00

score 18 · Answer 2 · answered Aug 27 '20 at 11:28

18

There is an option to helm upgrade to limit the number of old deployment secrets that are kept:

--history-max int      limit the maximum number of revisions saved per release.
                       Use 0 for no limit (default 10)

answered Aug 27 '20 at 11:28

js.

1,787
19
22

Is this mean that: We can only rollback 10 versions of a release, right? – Tho Quach Nov 26 '21 at 09:26

score 0 · Answer 3 · edited Dec 19 '22 at 20:37

0

This is because there is no Tiller anymore in Helm 3. Hence, release information is now stored in the same namespace as the release itself as a secret.

Which Helm uses as the default storage driver.

edited Dec 19 '22 at 20:37

Daniel Serodio

4,229
5
37
33

answered Dec 22 '21 at 19:02

Mostafa Wael

2,750
1
21
23

Extra secrets created when helm is used

3 Answers3