Terraform-provider-helm: Provide a way to deploy the ServiceAccount and ClusterRoleBinding for Tiller on provider setup

Created on 13 Mar 2018  ·  11Comments  ·  Source: hashicorp/terraform-provider-helm

Tiller needs a ServiceAccount and ClusterRoleBinding to run.
The provider currently only allows to specify an existing ServiceAccount, but does not allow to create it.
Creating this ServiceAccount and ClusterRoleBinding is currently a pain in the Terraform ecosystem.

Also, how to orchestrate, that the serviceaccount and CRB need to be created before the helm provider is being loaded?

This is why it would be great if the helm provider could create it automatically, maybe based on a yaml file provided.

Most helpful comment

terraform-providers/terraform-provider-kubernetes#73 has been merged / released so you can now do:

resource "kubernetes_cluster_role_binding" "tiller" {
  metadata {
    name = "tiller"
  }

  subject {
    kind = "User"
    name = "system:serviceaccount:kube-system:tiller"
  }

  role_ref {
    kind  = "ClusterRole"
    name = "cluster-admin"
  }
} 

All 11 comments

I've ran into the same problem yesterday testing this provider against k8s 1.9.3 (gke). I suspect this is more an issue with helm rather than the logic in provider. The work around is to manually run:

kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
./helm init --upgrade --service-account tiller --wait

tf is able to manage the sa naively:

resource "kubernetes_service_account" "helm" {
  metadata {
    name      = "tiller"
    namespace = "kube-system"
  }
}

resource "helm_release" "foo" {
  ...
  depends_on = [ "kubernetes_service_account.helm" ]
}

There isn't currently a tf resource to manage clusterrolebindings but there is an open PR:
https://github.com/terraform-providers/terraform-provider-kubernetes/pull/73

However, there isn't (at least not documented) was to setup the equivalent of the cli --service-account flag. Obviously, the most convient solution for the end user would be completely hide the requirement setup inside the provider. While exposing a service_account argument on the provider would allow end-users to at least configure around the problem.

These are perhaps the most relevant upstream helm issue(s):

https://github.com/kubernetes/helm/issues/2861
https://github.com/kubernetes/helm/issues/2962

My reading is that helm will not be changed to hand automatic setup on k8s clusters with RBAC enabled and that this will be documented.

@jhoblitt #35 #29 ? with https://github.com/terraform-providers/terraform-provider-kubernetes/pull/73, AFAICT, that should be everything needed.

@Stelminator Looks like #35 needs to be documented, as I didn't know that argument existed. I think means we're down to waiting on terraform-providers/terraform-provider-kubernetes#73

terraform-providers/terraform-provider-kubernetes#73 has been merged / released so you can now do:

resource "kubernetes_cluster_role_binding" "tiller" {
  metadata {
    name = "tiller"
  }

  subject {
    kind = "User"
    name = "system:serviceaccount:kube-system:tiller"
  }

  role_ref {
    kind  = "ClusterRole"
    name = "cluster-admin"
  }
} 

@shaneramey do we need to create the ClusterRole and User/ServiceAccount first?

@shaneramey The argument "api_group" is required, but no definition was found

@c4m4 juste add api_group="rbac.authorization.k8s.io" to role_ref

Closing this issue since is making reference to a version based on Helm 2, if this is still valid to the master branch please reopen it. Thanks.

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!

Was this page helpful?
0 / 5 - 0 ratings