Terraform-provider-helm: AutoMountServiceAccountToken Option not being set when installing Tiller.

Created on 1 Oct 2018  ·  6Comments  ·  Source: hashicorp/terraform-provider-helm

Terraform Version

0.11.7

Affected Resource(s)

Tiller installed by provider.

Terraform Configuration Files

Current snippit of terraform file that includes manual hacky step to update this value.

provider "helm" {
  service_account = "${kubernetes_service_account.tiller.metadata.0.name}"

  kubernetes {
    host                   = "${local.k8s_host}"
    username               = "${local.k8s_user}"
    password               = "${local.k8s_password}"
    client_certificate     = "${local.k8s_client_certificate}"
    client_key             = "${local.k8s_client_key}"
    cluster_ca_certificate = "${local.k8s_cluster_ca_certificate}"
  }
}

resource "null_resource" "fix_tiller_installation" {
  depends_on = ["kubernetes_service_account.tiller"]

  # TODO depends on tiller being installed!!! Temp fix to get around the issue with not using automountServiceAccountToken
  provisioner "local-exec" {
    command = "kubectl -n kube-system patch deployment tiller-deploy -p '{\"spec\": {\"template\": {\"spec\": {\"automountServiceAccountToken\": true}}}}'"
  }
}

# Other Helm resources. The null resource will currently fail until tiller is installed.

Expected Behavior

Helm should be installed and allow automountServiceAccountToken to be used or just set it to ture by default. I think this is ignored because helm will default this value to true when parsing the commandline arguments but will not use default of true when used directly in GO. However I am not 100% sure that this is the cause.

Actual Behavior

automountServiceAccountToken is not set at all meaning a manual patch to the tiller deployment needs to be made.

Steps to Reproduce

Terraform a cluster with RBAC enabled and try to apply any helm resource using terraform apply. Tiller will be succesfully installed but the service account token is not mounted and thus any helm commands fail (even helm list) because connection is refused.

Important Factoids

My example is running using GKE. For reference a larger snippit of the terraform code includes:

resource "google_container_cluster" "k8s" {
  name               = "kubernetes"
  zone               = "europe-west1-b"
  min_master_version = "1.10.6-gke.2"
  initial_node_count = 1                # per zone

  additional_zones = [
    "europe-west1-c",
    "europe-west1-d",
  ]

  network    = "${google_compute_subnetwork.default.network}"
  subnetwork = "${google_compute_subnetwork.default.name}"

  addons_config {
    kubernetes_dashboard {
      disabled = true
    }
  }

  timeouts {
    create = "10m"
  }
}

locals {
  k8s_host                   = "${google_container_cluster.k8s.endpoint}"
  k8s_user                   = "${google_container_cluster.k8s.master_auth.0.username}"
  k8s_password               = "${google_container_cluster.k8s.master_auth.0.password}"
  k8s_client_certificate     = "${base64decode(google_container_cluster.k8s.master_auth.0.client_certificate)}"
  k8s_client_key             = "${base64decode(google_container_cluster.k8s.master_auth.0.client_key)}"
  k8s_cluster_ca_certificate = "${base64decode(google_container_cluster.k8s.master_auth.0.cluster_ca_certificate)}"
}

provider "kubernetes" {
  version                = "1.2.0"
  host                   = "${local.k8s_host}"
  username               = "${local.k8s_user}"
  password               = "${local.k8s_password}"
  client_certificate     = "${local.k8s_client_certificate}"
  client_key             = "${local.k8s_client_key}"
  cluster_ca_certificate = "${local.k8s_cluster_ca_certificate}"
}

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

References

bug

Most helpful comment

I pushed #141 which should fix this issue

All 6 comments

After having a brief scan I think this would require an update to v2.11.0 since the AutoMountServiceAccountToken option is not available in v2.10.0

I am happy to investigate making this change myself, but would like some direction seeing as dependency management does not seem intuitive in go. I tried to just dep ensure before making any changes and it seems that changes most of the vendor directory.

I came across the same issue and tried opening a PR to update helm to 2.11.0 but unfortunately I don't know the first thing about go ;).
Just wanted to amend your script for other readers to ensure kubectl is executed in the right context with GKE:

resource "null_resource" "fix_tiller_installation" {
  depends_on = ["kubernetes_service_account.tiller"]

  provisioner "local-exec" {
    command = <<EOF
gcloud container clusters get-credentials ${var.cluster_name} --zone ${var.zone} --project ${var.project}

kubectl patch deployment tiller-deploy \
  --patch '{"spec": {"template": {"spec": {"automountServiceAccountToken": true}}}}' \
  --namespace kube-system \
  --context "gke_${var.project}_${var.zone}_${var.cluster_name}"
EOF
  }
}

I pushed #141 which should fix this issue

Just to clarify, since #143 was merged (released with 0.7.0?): Is the patch not needed anymore?

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

Related issues

alexkreidler picture alexkreidler  ·  71Comments

adaphi picture adaphi  ·  11Comments

dangarthwaite picture dangarthwaite  ·  19Comments

sean-ersw picture sean-ersw  ·  22Comments

rubenv picture rubenv  ·  11Comments