terraform-provider-helm
terraform-provider-helm copied to clipboard
Allow us to pass in a kubeconfig as a file() in TF
Description
Right now if I want to pass in a kubeconfig, I have to reference it as an actual file on the filesystem. I would like to be able to either reference it as a file()
or a TF var.
Potential Terraform Configuration
How it works:
provider "helm" {
kubernetes {
config_path = "/path/to/kube_cluster.yaml"
}
}
How I want it to work:
provider "helm" {
kubernetes {
config_path = file("/path/to/kube_cluster.yaml")
}
}
References
None
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
Hi @tibers, thanks for the issue. I think there's already a Terraform native way to do this, without having to make changes to the provider. You can use the Terraform yamldecode
function to import the kubeconfig, and then assign the values directly. Please let me know if there's some reason this won't work for your use case.
locals {
kube_config = yamldecode(file("/Users/redeux/.kube/config"))
}
provider "helm" {
kubernetes {
load_config_file = false
host = local.kube_config.clusters[1].cluster.server
cluster_ca_certificate = base64decode(local.kube_config.clusters[1].cluster.certificate-authority-data)
client_certificate = base64decode(local.kube_config.users[1].user.client-certificate-data)
client_key = base64decode(local.kube_config.users[1].user.client-key-data)
}
}
Our particular problem is we've got no access to the filesystem on the runners, which are a pool anyway, so we can't promise we're always running on that exact runner every time.
Fortunately we're in GKE so we can do the cert thing, but if someone is using some provider which only outputs a kubeconfig as a variable it might be an issue if they're also on a runner pool.
Alternate version: If someone is working in a shop where they only give them a kubeconfig (EG: some sort of SSO auth in front of the cluster) it would be handy to be able to code that into TF and feed it to the helm provider.
Your code snippit is awfully handy though! You should at least tuck that into an example somewhere. :)
I agree there should be a way to provide a i.e. a config_content
instead of a config_path
. In our use case we have different types of kubeconfigs, some use token authentication, other use helpers, others client certificate, etc. so it would be useful to support directly providing the kubeconfig contents (which is produced by another module) instead of trying to decode the YAML to retrieve the different parts.
@airadier
Is there any technical limitation that's preventing you to write the kubeconfig from your module to a local temporary file before passing it's path to the Kubernetes provider?
If you control the modules' structure yourself, you could even do that in the module and just pass out the file.
Is there any technical limitation that's preventing you to write the kubeconfig from your module to a local temporary file before passing it's path to the Kubernetes provider?
If you control the modules' structure yourself, you could even do that in the module and just pass out the file.
No technical limitations. I just want to avoid writing temporary files to pass values between modules, it would be more practical to just pass the raw contents as a parameter.
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!