Inconsistent final plan when local file content is unknown before apply using kube secret binary data

[tschneider-aneo]

Terraform Version, Provider Version and Kubernetes Version

Terraform version: 1.8.5
Kubernetes provider version: 2.30.0
Kubernetes version: 1.29.5+k3s1

Affected Resource(s)

• data kubernetes_secret

Terraform Configuration Files

# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file. For
# security, you can also encrypt the files using our GPG public key.

provider "kubernetes" {
  config_path = "~/.kube/config"
}

terraform {
  required_version = ">= 1.6"
  required_providers {
    local = {
      source  = "hashicorp/local"
      version = ">= 2.4.0"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.21.1"
    }
  }
}


resource "kubernetes_secret" "my_kube_secret" {
  metadata {
    name = "secret-name"
  }
  data = {
    username = "foo"
    password = "bar"
  }
  type = "kubernetes.io/basic-auth"
}

data "kubernetes_secret" "my_kube_secret_data" {
  metadata {
    name = kubernetes_secret.my_kube_secret.metadata[0].name
  }
  binary_data = {
    username = ""
    password = ""
  }
}

resource "local_file" "my_local_file" {
  content = data.kubernetes_secret.my_kube_secret_data.binary_data["username"]
  filename = "${path.root}/generated/foo.txt"
}

Debug Output

https://gist.github.com/tschneider-aneo/691a2d49d4ee0a69ec035b00622834a9

Panic Output

Steps to Reproduce

1. terraform init
2. terraform apply

Expected Behavior

What should have happened? TF should know that the local file's content will be known during apply and should just wait for the data source to retrieve the kube secret data.

Actual Behavior

What actually happened? TF seems to be converting an unknown value to a null value, producing the inconsistent final plan error.

Important Factoids

References

• https://github.com/hashicorp/terraform-provider-kubernetes/issues/2444

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

[tschneider-aneo]

I was redirected here by @liamcervante after posting the following issue on the Terraform repo : https://github.com/hashicorp/terraform/issues/35332

The reason why I did not reference the kubernetes secret resource directly is because I encountered this bug while trying to access a kube secret created by a Helm release resource (deployed with TF). But deploying a Helm release is quite tedious and not necessary to reproduce the bug.

[alexsomesan]

This does look like an issue with the way binary_data's UX was designed. Because it requires users to set both a key and a value for the Secret's attributes that it requires encoding of, Terraform treats these as "known values" at plan time and doesn't accept the new (encoded) value that the datasource tries to insert there during apply.

We will look further into this, but the fix is likely to require schema changes which we only allow on major version releases and thus will be while out.

In the mean time, my suggested workaround is to use Terraform's own base64encode function on the values of the data attribute. This should similarly yield base64 encoded values, but avoid the strange UX of setting a dummy value like binary_data requires.

[github-actions[bot]]

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!