provider seems to fall back to, rather than ignore, kubeconfig_path when kubeconfig_raw is set

[pmahoney]

I'm using version 0.3.1.

I haven't investigated this completely, but I was setting kubeconfig_raw in the provider, which was invalid in some way (I believe), and it seemed like the plugin fell back to the default context in my local ~/.kube/config.

This seems contrary to the docs, which state

If kubeconfig_raw is set, kubeconfig_path is ignored.

And it's also potentially highly dangerous to use an unexpected kubeconfig.

terraform-provider-kustomization/kustomize/provider.go

Lines 83 to 95 in 2341cf8

	// try to get a config from kubeconfig_raw
	config, err = getClientConfig(data, context)
	if err != nil {
	// if kubeconfig_raw did not work, try kubeconfig_path
	path := d.Get("kubeconfig_path").(string)
	data, _ = readKubeconfigFile(path)
	config, err = getClientConfig(data, context)
	if err != nil {
	// if neither worked we fall back to an empty default config
	config = &rest.Config{}
	}
	}

I fixed my config, but would like:

• any error using kubeconfig_raw should be logged
• if kubeconfig_raw was set but failed, it should not fallback to kubeconfig_path
• any error using kubeconfig_path should be logged
• perhaps the docs should suggest specifying a non-default context to prevent accidentally using the wrong kubeconfig

[pst]

The current implementation is, if kubeconfig_raw and kubeconfig_path are set, kubeconfig_path is ignored. In any case the provider falls back to the default config file on disk like kubectl does and supports the same environment variables. Behaving like kubectl was the original intention of the implementation. Most recently the Kubernetes provider dropped support for a fallback and made it mandatory to specify a config. That's an option too. I'm open to feedback and pull requests to change that.

[pmahoney]

Here's a few more details on my use case: I'm using terraform-aws-eks to create an EKS cluster. I then configure the kustomization provider like this:

data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

locals {
  # non-default context name to protect from using wrong kubeconfig
  kubeconfig_context = "_terraform-kustomization-${var.cluster_name}_"

  kubeconfig = {
    apiVersion = "v1"
    clusters = [
      {
        name = local.kubeconfig_context
        cluster = {
          certificate-authority-data = data.aws_eks_cluster.cluster.certificate_authority.0.data
          server                     = data.aws_eks_cluster.cluster.endpoint
        }
      }
    ]
    users = [
      {
        name = local.kubeconfig_context
        user = {
          token = data.aws_eks_cluster_auth.cluster.token
        }
      }
    ]
    contexts = [
      {
        name = local.kubeconfig_context
        context = {
          cluster = local.kubeconfig_context
          user    = local.kubeconfig_context
        }
      }
    ]
  }
}

provider "kustomization" {
  kubeconfig_raw = yamlencode(local.kubeconfig)
  context        = local.kubeconfig_context
}

And I never want to use credentials from my local ~/.kube/config or anywhere other than the given config.

[vincentvdk]

I had the same problem on GCP. Explicitly specifying the context in the provider did the trick.

[KarstenSiemer]

I would actually favor something like the helm provider does:

provider "helm" {
  kubernetes {
    host                   = "https://${module.testing_gke_core.endpoint}"
    token                  = data.google_client_config.default.access_token
    cluster_ca_certificate = base64decode(module.testing_gke_core.ca_certificate)
  }
}