Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed to deploy a secret with type kubernetes.io/service-account-token #4884

Closed
guillomep opened this Issue Nov 5, 2018 · 5 comments

Comments

Projects
None yet
4 participants
@guillomep
Copy link

commented Nov 5, 2018

Hello,

I am trying to deploy a secret containing a token linked to a service account using a Helm chart.
When I am trying to deploy my release I got the following output in helm:

KIND             NAME
{ v1 secrets}    myserviceaccount-token-secret

I notice that if I run a helm template, I got the things in the right order:

---
# Source: testrbac/templates/rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: kube-system
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: myserviceaccount-token-secret
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: myserviceaccount

---

But if I run debug when I'm deploying my release, order changes to the following:

---
# Source: testrbac/templates/rbac.yaml
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: myserviceaccount-token-secret
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: myserviceaccount
---
# Source: testrbac/templates/rbac.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: kube-system

Secret is created before ServiceAccount and so missing after, because k8s doesn't know the ServiceAccount it linked with. I also notice that applying the secret with kubectl without creating the ServiceAccount before results in secret/dashboard-viewer-api-token-secret created with the return code of 0, but that's probably another story.

This behaviour can be easily reproduce by creating an empty chart and adding the following file in the templates:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: myserviceaccount
  namespace: kube-system
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
  name: myserviceaccount-token-secret
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: myserviceaccoun

Output of helm version:

Client: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}
Server: &version.Version{SemVer:"v2.11.0", GitCommit:"2e55dbe1fdb5fdb96b75ff144a339489417b146b", GitTreeState:"clean"}

Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"12", GitVersion:"v1.12.2", GitCommit:"17c77c7898218073f14c8d573582e8d2313dc740", GitTreeState:"clean", BuildDate:"2018-10-24T06:54:59Z", GoVersion:"go1.10.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.6", GitCommit:"a21fdbd78dde8f5447f5f6c331f7eb6f80bd684e", GitTreeState:"clean", BuildDate:"2018-07-26T10:04:08Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}

Cloud Provider/Platform (AKS, GKE, Minikube etc.):
Running it on minikube and AWS using the 1.10.6 version of kubernetes give the same result.

@guillomep

This comment has been minimized.

Copy link
Author

commented Nov 5, 2018

It is probably because of the installation order in tiller that makes the Secret creation to be before the one of ServiceAccount. I don't know what would be the impact if we would put ServiceAccount just before Secret in the installation order

See: https://github.com/helm/helm/blob/master/pkg/tiller/kind_sorter.go

@bacongobbler

This comment has been minimized.

Copy link
Member

commented Nov 6, 2018

@adamreese, do you know if there'd be any impact moving the ServiceAccount sooner in the install order?

@guillomep

This comment has been minimized.

Copy link
Author

commented Nov 12, 2018

For now I use the following workaround: helm template mychart -x template/rbac.yaml | kubectl apply -f -, but the drawback is that rbac resources are not manage by tiller

@aweimeow

This comment has been minimized.

Copy link

commented Mar 25, 2019

I have this issue too, and I figured out what happened until I looked @guillomep 's comment.

It is probably because of the installation order in tiller that makes the Secret creation to be before the one of ServiceAccount.

And I tried to install the hook for the service account, make sure the service account installed before anything else. This hook can avoid the potential problem from dependencies. For example:

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: multus-sa
  namespace: kube-system
  annotations:
    "helm.sh/hook": "pre-install"
---
apiVersion: v1
kind: Secret
metadata:
  name: multus-sa-secret
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: multus-sa
type: kubernetes.io/service-account-token

It forces helm to install ServiceAccount before anything else, more options available on Helm Docs - THE AVAILABLE HOOKS.

@guillomep

This comment has been minimized.

Copy link
Author

commented Apr 4, 2019

Thanks @aweimeow . I haven't thought about hook when I faced this issue.
This workaround works for me, so there is no more issue for that.

@guillomep guillomep closed this Apr 4, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.