Load config from an output or data resource

[vickleford]

Streamline the kubernetes provisioner to work in more harmony with the infrastructure where the kubernetes cluster is deployed.

It is helpful to think in the module context, such as a fluentd module which uses terraform to provision resources in kubernetes (daemonset, maybe a configmap), some cloudwatch log groups, and IAM roles. Such terraform files would already have very specific things set (AWS region, credentials) to move the author into the line of thought where a Kubernetes cluster is under the AWS umbrella rather than one umbrella for AWS and one umbrella for Kubernetes.

Example Usage

For example, if we're working with an EKS cluster in Amazon deployed by the eks_cluster resource from the AWS provider, imagine an output specifying the kube config file (absolutely free of secrets).

# demo.tf

data "terraform_remote_state" "eks_cluster" {
  backend = "s3"

  config {
    encrypt        = true
    bucket         = "my-remote-state-bucket"
    key            = "mykey/terraform.tfstate"
    region         = "us-west-2"
    dynamodb_table = "tflocks"
  }
}

provider "kubernetes" {
  config_content = "${data.terraform_remote_state.eks_cluster.kube_config}"
}

In the future, this can be tidied up and recycled across multiple providers, not just AWS. Imagine a data resource on aws_eks_cluster called config_file.

# future.tf

data "eks_cluster" "cluster" {
  name = "yeah-thats-my-cluster"
}

provider "kubernetes" {
	config_content = "${data.eks_cluster.cluster.config_file}"
}

This should allow us the additional benefit of keeping EKS tokens out of statefiles.

This PR is a rehash of #380.

[alexsomesan]

Hi and thanks for trying to address this! It's a really useful feature that's been missing in the provider.
I know it's going to make life easier for a lot of folks.

However, I do have reservations about dumping the intermediate config to disk (only to load it back up again soon after). This has security implications that aren't visible to the majority of users due to the "behind the scenes" nature of this approach. So unless the user actually scrutinizes the implementation they will not understand that sensitive credentials are persisted to disk (and also not cleaned up on destroy).

I'd like to propose an alternative implementation that would make use of direct loading of client config from an in-memory source.
In fact, the client-go package already has support this via:
https://github.com/kubernetes/client-go/blob/4009d98e83384a22714b5ea6ba2b9f8862254a0c/tools/clientcmd/loader.go#L388-L390

What do you think?

[vickleford]

@alexsomesan I share your reservations and apologize I didn't look much beyond how the provider itself was loading the config. You pointed me exactly in the right direction for ridding this of that pesky tempfile ;) I'll give this a serious stab as soon as I can. Thanks!

[alexsomesan]

Had a quick skim through the latest changes and they're looking good.
Is there any chance you could add a test case for this new code path?

[vickleford]

@alexsomesan more than happy to add a test for that. This has been a great opportunity to explore Terraform's guts. I hope I didn't butcher it up too badly. Thank you for your guidance.

[hashicorp-cla]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[vickleford]

Sorry guys, just now noticing this is still open and no longer needed. Thanks for allowing me to participate!

[ghost]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!