kubernetes_secret data is not read from cluster after secret creation

[astorath]

Terraform Version, Provider Version and Kubernetes Version

Terraform version: v0.14.5
Kubernetes provider version: v2.0.3
Kubernetes version: GitVersion:"v1.20.2"

Affected Resource(s)

• kubernetes_secret

Terraform Configuration Files

terraform {
  required_providers {
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.0.3"
    }
  }
  required_version = ">= 0.14"
}

provider "kubernetes" {
  alias          = "dev"
  config_path    = "~/.kube/config"
  config_context = "kind-kind1"
}

resource "kubernetes_secret" "gitlab-token-dev" {
  provider = kubernetes.dev
  metadata {
    namespace     = "kube-system"
    generate_name = "gitlab-token-"
    annotations = {
      "kubernetes.io/service-account.name" = "gitlab"
    }
  }
  type = "kubernetes.io/service-account-token"
}

resource "local_file" "foo" {
  content  = "resource: ${kubernetes_secret.gitlab-token-dev.data}"
  filename = "${path.module}/tmp.txt"
  depends_on = [
    kubernetes_secret.gitlab-token-dev
  ]
}

Debug Output

https://gist.github.com/astorath/0511a583ce91f95fff58e676c16bae6e

Steps to Reproduce

1. kubectl create serviceaccount gitlab
   2.terraform plan

Expected Behavior

secret's kubernetes_secret data is read from cluster after creation

Actual Behavior

secret's kubernetes_secret data is treated as null as per resource manifest

Important Factoids

References

• Missing secretNamespace on azure_file of persistent_volume_source #1234

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[jrhouston]

This looks like it might be a duplicate of #1168

[jffaust]

@astorath Have you found any workaround?
We want to read the secret token and use it to manage a corresponding azuredevops_serviceendpoint_kubernetes resource that uses the "ServiceAccount" authorization_type but can't because the secret data is always empty.

[jffaust]

Here's what we ended up doing:

Terraform:

data "external" "kubernetes_secret_env_systems" {
  for_each    = kubernetes_service_account.env_systems
  program     = ["Powershell.exe", "& ./Get-KubernetesSecretData.ps1"]
  working_dir = path.module
  query = {
    kubeConfigContext = var.cluster_name
    namespace         = each.value.metadata.0.namespace
    secretName        = each.value.default_secret_name
    jsonPath          = "{.data}"
  }
}

# Example usage
# data.external.kubernetes_secret_env_systems[each.key].result.token

File: Get-KubernetesSecretData.ps1

$ErrorActionPreference = "Stop"

# Read stdin as string
$jsonPayload = [Console]::In.ReadLine()

$json = ConvertFrom-Json $jsonPayload

if (-not $json) {
    Write-Error "Unable to parse JSON input."
}
if ([string]::IsNullOrEmpty($json.kubeConfigContext)) {
    Write-Error "Required property 'kubeConfigContext' not provided in JSON input."
}
if ([string]::IsNullOrEmpty($json.namespace)) {
    Write-Error "Required property 'namespace' not provided in JSON input."
}
if ([string]::IsNullOrEmpty($json.secretName)) {
    Write-Error "Required property 'secretName' not provided in JSON input."
}

if (-not [string]::IsNullOrEmpty($json.kubeConfigPath)) {
    $Env:KUBECONFIG = $json.kubeConfigPath
}

$null = kubectl config use-context ($json.kubeConfigContext)

$dataJsonPath = "{@}"
if ($json.jsonPath) {
    $dataJsonPath = $json.jsonPath
}

$ns = $json.namespace
$name = $json.secretName
$secretData = kubectl get secret $name -o jsonpath=$dataJsonPath --namespace=$ns

Write-Output $secretData

[github-actions]

Marking this issue as stale due to inactivity. If this issue receives no comments in the next 30 days it will automatically be closed. If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. This helps our maintainers find and focus on the active issues. Maintainers may also remove the stale label at their discretion. Thank you!

[z0rc]

Still relevant. With #1792 it isn't clear how to create token for ServiceAccount using provider's resources.

[arybolovlev]

Hi @astorath,

This issue has been addressed, with the latest version of the provider your initial code works.

@z0rc, please refer to the provider documentation here.

I will go ahead and close this issue.

Thank you.