Hello! Thank you for opening this issue. Currently there's a workaround for this using yamldecode, see this example:

hashicorp/terraform-provider-helm#614 (comment)

Hello!

I would like to configure the provider this way and I'm interesting to contribute in this feature.

Some fields of kubeconfig file are not covered in provider arguments, like tls-server-name (.clusters[0].cluster.tls-server-name). It could be one more reason in favor of this proposal.

Currently, even if we have terraform variables, we need to write a file and use config_path argument to provide a tls-server-name.

With this proposal, it would be easier. We would provide just config_data argument.

Oh please let this get some traction ASAP. 😄

That is a neat feature that will undoubtedly simplifies quite some use-cases, really interested in that! :)

Creating a cluster, using that cluster as a provider, and deploying things to the cluster are advantages of using terraform over many other tools. It is really unfortunate that this use case is not considered a priority. I could not find any official documentation covering this case and had to rely on 3rd party blogs to find that people were writing temp files. As others stated, in many CI environments, this is not feasible.

The workaround is almost worse than just creating a temp file. IDEs cannot resolve the references, leading to false errors like this:

And in my case, creating an Oracle Cloud Cluster, the workaround doesn't even work:

To add more reasons to support this, I would argue that the workaround of writing a temp file and then specifying the config_path is a security issue. The machine where terraform was executed now has an unnecessary local kubeconfig file.

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!