Safer answer
The accepted answer gives the administrator full access to Helm, which is not the best solution from a security point of view. With a little more work, we can limit Helm's access to a specific namespace. More details in the steering wheel documentation .
$ kubectl create namespace tiller-world namespace "tiller-world" created $ kubectl create serviceaccount tiller --namespace tiller-world serviceaccount "tiller" created
Define a role that allows Tiller to manage all resources in tiller-world , as in role-tiller.yaml :
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-manager namespace: tiller-world rules: - apiGroups: ["", "batch", "extensions", "apps"] resources: ["*"] verbs: ["*"]
Then run:
$ kubectl create -f role-tiller.yaml role "tiller-manager" created
In rolebinding-tiller.yaml ,
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: tiller-binding namespace: tiller-world subjects: - kind: ServiceAccount name: tiller namespace: tiller-world roleRef: kind: Role name: tiller-manager apiGroup: rbac.authorization.k8s.io
Then run:
$ kubectl create -f rolebinding-tiller.yaml rolebinding "tiller-binding" created
After that, you can run helm init to install Tiller in the tiller-world namespace.
$ helm init --service-account tiller --tiller-namespace tiller-world
Now add the prefix to all the commands --tiller-namespace tiller-world or set TILLER_NAMESPACE=tiller-world in your environment variables.
More reliable answer in the future.
Stop using tiller. Helm 3 completely eliminates the need for Tiller. If you are using Helm 2, you can use the helm template to generate yaml from the Helm diagram, and then run kubectl apply to apply the objects to your Kubernetes cluster.
helm template --name foo --namespace bar --output-dir ./output ./chart-template kubectl apply --namespace bar --recursive --filename ./output -o yaml