Terraform-provider-kubernetes: Secret type service-account-token cannot be created

[Dariusch]

Terraform Version

terraform -v
Terraform v0.11.10
+ provider.kubernetes v1.4.0

Affected Resource(s)

• kubernetes_secret

Terraform Configuration Files

provider "kubernetes" {
  version = "~> 1.4"
}

resource "kubernetes_secret" "sa-secret" {
  type = "kubernetes.io/service-account-token"
  metadata = {
    name      = "some_name"
  }
}

Debug Output

* kubernetes_secret.sa-secret: 1 error(s) occurred: 
* kubernetes_secret.sa-secret: Secret "some_name" is invalid: metadata.annotations[kubernetes.io/service-account.name]: Required value

Setting the annotation via terraform produces another error:

resource "kubernetes_secret" "sa-secret" {
  type = "kubernetes.io/service-account-token"
  metadata = {
    name      = "some_name"
    annotations {
      "kubernetes.io/service-account-token.name" = "service_account_name"
    }
  }
}

results in

Error: kubernetes_secret.sa-secret: metadata.0.annotations: "kubernetes.io/service-account-token.name" is internal Kubernetes annotation

Expected Behavior

Create a secret type service-account-token

Actual Behavior

Error exit 1

Background Information

I am trying to script my hashicorp vault configuration.
I want to create a secret I can reference with a static name and then grant my vault backend config based on the service accounts token stored in the secret.

For reading the secret I am waiting for https://github.com/terraform-providers/terraform-provider-kubernetes/pull/243 to be merged

[cupojoe]

I'm having the same issue, any updates on this?

[nunofernandes]

Bumped on this also.. Trying to create a service account using terraform and I can't create the secret for that service account.

[cupojoe]

@Dariusch removing the type property type = "kubernetes.io/service-account-token" creates the secret successfully and it works just the same when you mount it in a pod. Maybe I'm missing some other benefit from using the type property for this, but as far as I can tell no impact.

[Dariusch]

@cupojoe yes, removing the type property creates a simple secret.
ServiceAccount secrets mount their values into a folder in the pod (/var/run/secrets/kubernetes.io/serviceaccount/token), which then can be used e.g. in initContainers to authenticating against Hashicorps vault.
A simple secret is not enough because I need kube API access

[cupojoe]

I see. Well, hopefully, there will be a solution soon.

[WimDiepgrond]

I have the same issue here, anyone having a solution for this or a workaround? I really need it to be of type kubernetes.io/service-account-token.

[Dariusch]

yes there is a "temporary" fix by patching it via the null_resource.
Not pretty but it works

resource "null_resource" "patch" {
  provisioner "local-exec" {
    command = <<EOF
  SA_SECRET_NAME=$(kubectl get sa ${var.service_account_name} -o jsonpath="{.secrets[*]['name']}");
  kubectl patch secret $SA_SECRET_NAME --type=merge -p='{"data":{"key":"'value'"}}';
EOF
  }
}

[tdmalone]

@Dariusch A fix for the limitation on ‘internal Kubernetes annotations’ has been released in 1.7.0. Given you should now be able to add that second annotation, does that resolve this issue?

[JnMik]

I believe the annotation should be
"kubernetes.io/service-account.name" = "service_account_name"
instead of
"kubernetes.io/service-account-token.name" = "service_account_name"

But then on secret creation I have this weird error :
Error: secrets "alb-ingress-controller" not found

Terraform doesn't seem to like the type property with this value
type = "kubernetes.io/service-account-token"

[ikarlashov]

You need to specify namespace for the secret. This is the correct example that works for me:

resource "kubernetes_secret" "gitlab_admin_sa_secret" {
  metadata {
    name = "gitlab-admin-secret"
    namespace = "kube-system"
    annotations = {
      "kubernetes.io/service-account.name" = "${kubernetes_service_account.gitlab_admin_sa.metadata.0.name}"
    }
  }
  data = {
    token = "${var.gitlab_admin_token}"
  }
  type = "kubernetes.io/service-account-token"
}

[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.

[nandac]

I am on 0.12 and keep getting the error:```
Error: secrets "" not found

on .terraform/modules/gitlab_infra_runners/kubernetes.tf line 31, in resource "kubernetes_secret" "gitlab_kubernetes_secret":
31: resource "kubernetes_secret" "gitlab_kubernetes_secret" {

This is how I have configured my secret:```
resource "kubernetes_secret" "gitlab_kubernetes_secret" {
  metadata {
    name      = "<secret-name>"
    namespace = "<namespace>"
    annotations = {
      "kubernetes.io/service-account.name" = "<service-account>"
    }
  }

  data = {
    token = <string-from-secrets-manager>
  }

  type = "kubernetes.io/service-account-token"
}

I would like to avoid using a null resource but would like to get a definite answer is this issue has been fixed or not in 0.12.

[alexsomesan]

This configuration works for me:

resource "kubernetes_service_account" "my-user" {
  metadata {
    name = "my-user"
  }
}


resource "kubernetes_secret" "gitlab_kubernetes_secret" {
  metadata {
    name      = "my-secret"
    annotations = {
      "kubernetes.io/service-account.name" = kubernetes_service_account.my-user.metadata.0.name
    }
  }

  data = {
    token = "some-token"
  }

  type = "kubernetes.io/service-account-token"
}

When also creating the service account in the same Terraform operation it is important to set the value of the "kubernetes.io/service-account.name" annotation via referencing the attribute on the SA resource so that Terraform understands the order of dependencies and creates the SA before the secret.

[aareet]

Closing since this issue has been awaiting response for 20 days.

[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!