Support kubeconfig file data instead of path only

[JUST1CEjohnson]

Description

Would like to be able to provide kubeconfig data directly to the provider instead of a path to the file. Currently trying to pull the data from a Vault secret and it's failing because it's the contents of the file and not the path.

Potential Terraform Configuration

Ideally would like to do something like this:

provider "kubernetes" {
  config_data = data.vault_generic_secret.k8s_creds.data["KUBECONFIG"]
}

Currently it only accepts config_path and so providing it the way above errors out with "'config_path' refers to an invalid path:" - proposing adding config_data option to supply the kubeconfig contents directly

Setup that doesn't work currently:

provider "kubernetes" {
  config_path = data.vault_generic_secret.k8s_creds.data["KUBECONFIG"]
}

References

Something similar was previously requested, but the issue is now closed. https://github.com/hashicorp/terraform-provider-kubernetes/issues/917

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

[BBBmau]

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

https://github.com/hashicorp/terraform-provider-helm/issues/614#issuecomment-722665842

[matheusfm]

Hello!

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

[matheusfm]

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.

[DaleyKD]

Oh please let this get some traction ASAP. 😄

[kzgrzendek]

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

[eduanb]

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:

[eduanb]

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.

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