Terraform-provider-kubernetes: automountServiceAccountToken for pods / deployments is neither tracked nor respected

[synhershko]

It's impossible to set automountServiceAccountToken: false when defining a deployment, and changing this manually in k8s yaml after creation isn't detected by terraform plan. Using latest pre-12.

[MiniJerome]

@synhershko this might help you workaround https://github.com/terraform-providers/terraform-provider-kubernetes/issues/38#issuecomment-318581203

[shcallaway]

I wasn't familiar with automountServiceAccountToken, so this comment is for people like me:

automountServiceAccountToken allows you to prevent Kubernetes from automatically mounting cluster API credentials to a pod. You can set it on either the pod or the service account, but the pod value takes precedence.

If automountServiceAccountToken is false, the pod will not be able to communicate with the cluster API.

In Terraform, automountServiceAccountToken is hard-coded to false on the pod.

This is what happened to me when I was setting up external-dns. The pod was unable to discover the cluster API endpoint. I was getting the following error:

time="2019-05-17T00:26:24Z" level=fatal msg="invalid configuration: default cluster has no server defined"

[TylerWanner]

FYI, this only happens on deployment creation. For some reason, if you do an update to that deployment (not an add and destroy, but a change), the automountserviceaccounttoken disappears

[tdmalone]

I think this issue is a duplicate of #38, and was fixed recently with the merge of https://github.com/terraform-providers/terraform-provider-kubernetes/pull/261 (yet to be released though).

[pdecat]

261 was released with 1.8.0: https://github.com/terraform-providers/terraform-provider-kubernetes/blob/master/CHANGELOG.md#180-july-02-2019

[hashibot]

This issue has been open 180 days with no activity. If this issue is reproducible with the latest version of the provider and with Terraform 0.12, please comment. Otherwise this issue will be closed in 30 days.

[martin-schaefer]

I have this issue as well: I deploy a Spring Boot application (Java) which must be able to read config maps. The service account is given read permission for that case. When I do the deployment the classic way with kubectl apply -f the Spring Boot application works fine. But using terraform with exactly the same deployment description, the Spring Boot application cannot access the Kubernetes API anymore with a TLS certificate error: SunCertPathBuilderException: unable to find valid certification path to requested target

When I compared the created pods by kubectl and terraform I noticed the following difference:
With kubectl there is a mount for the service account token:

volumes: - name: default-token-fh2cv secret: secretName: default-token-fh2cv defaultMode: 420 containers: (...) volumeMounts: - name: default-token-fh2cv readOnly: true mountPath: /var/run/secrets/kubernetes.io/serviceaccount
However, with terraform I don't see such mounts, but I see the following flag:
automountServiceAccountToken: false

My assumption is, that this is exaclty the issue described in this ticket. Was it not fixed yet?

I am using minikube to test this, my versions are:
minikube version: v1.9.2
Terraform v0.12.24
provider.kubernetes v1.11.1

[martin-schaefer]

After reading a bit more about this, adding automount_service_account_token = true to the template-section in the terraform resource "kubernetes_deployment" fixed the issue for me:

    template {
    ...
      }
      spec {
        automount_service_account_token = true
        container {
          name  = "${var.app_name}-container"
          image = "gcr.io/handy-zephyr-272321/${var.app_name}:latest"

[jtcressy]

Why does terraform not follow the kubernetes defaults?
automountServiceAccountToken is defaulted to true by the kubernetes api. Why are we doing the opposite behavior? If it needs to be false for security reasons, the operator of the terraform code should be able to set this override. However, new users to the kubernetes terraform provider should expect it to behave as if they wrote their pod specs in yaml, especially if they are transitioning from flat yaml manifests to terraform resources.

[gbolo]

While I agree that the default should be the same as the k8s API, it's still a terrible default. It should be false by default, as in very few containers (almost none) would ever need to use this, so its an unnecessary security risk. So terraform devs setting this to false is an improved default, but now it doesnt match the a yaml that kubectl would apply if this value is omitted.

[jcreager]

I think this is a case where it is difficult to have a perfect solution. However, I think terraform plan and terraform apply should indicate automount_service_account_token is set to false. For example, template.spec.host_ipc defaults to false, and this is indicated in terraform apply.

              + spec {
                  + dns_policy                       = "ClusterFirst"
                  + host_ipc                         = false

automount_service_account_token defaults to false, but this is not indicated in the output from terraform apply as far as I can tell. At least not when a kubernetes deployment resource is applied for the first time.

The default is documented.

automount_service_account_token - (Optional) Indicates whether a service account token should be automatically mounted. Defaults to false.

However, the documentation does not indicate what the ramifications are if the value needs to be true. For example, if you are creating a deployment with a service account that isn't the default service account you will run into difficult to diagnose errors that won't make it obvious that the issue is the service account token has not been auto mounted.

Does it make sense in this case that a warning should be presented to the user if the value has not been explicitly set, or perhaps even going as far as requiring automount_service_account_token in the schema (a breaking change, unfortunately)?

I feel that a warning when automount_service_account_token is not set explicitly will be very helpful.

[alexsomesan]

The automount_service_account_token has been updated to default to true and the change will be part of the v2.0.0 release of the provider.
That should align the behaviour with Kubernetes and should eliminate the issues reported here, so we won't consider adding a warning mechanism to the provider.

[hashibot[bot]]

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!