terraform-provider-helm icon indicating copy to clipboard operation
terraform-provider-helm copied to clipboard

Allow us to pass in a kubeconfig as a file() in TF

Open tibers opened this issue 4 years ago • 5 comments

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

tibers avatar Oct 28 '20 23:10 tibers

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)
    }
}

redeux avatar Nov 05 '20 21:11 redeux

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. :)

tibers avatar Nov 05 '20 22:11 tibers

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 avatar Mar 01 '22 13:03 airadier

@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.

alexsomesan avatar Mar 01 '22 15:03 alexsomesan

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.

airadier avatar Mar 01 '22 19:03 airadier

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!

github-actions[bot] avatar Mar 02 '23 00:03 github-actions[bot]