Register GCP auth plugin

[e-max]

This PR intends to address the bug reported in this issue
#5

As described here hashicorp/terraform#15244 (comment)
client-go doesn't enable GCP auth plugin by default. We have to do it explicitly.

Fixes #5
Fixes #8

[e-max]

Could anybody restart the travis build? Looks like it stuck.

[radeksimko]

That's very interesting find - thank you for the PR.

Sorry to cause any pain, but we always prefer to keep vendor changes separate - i.e. 1 PR for anything in /vendor (which we can merge almost straight away) and followup PR(s) using those new libraries. Would you mind submitting vendor changes separately?

Also I'd love to have such change to be covered by a test. Is there any way I can reproduce #5 ? Were you able to reproduce it reliably? Did you need any specific GKE settings or did you deploy K8S to any specific environment (GCloud, AWS) with any specific settings?

Thanks.

[e-max]

No problem, I'll split this PR.

Yes, I can reproduce it reliably. It happens every time I try to create cluster in gcloud.

Here the example of terraform file

provider "google" {
  project = "${var.gcp_project}"
  region  = "${var.gcp_region}"
}

resource "random_id" "password" {
  byte_length = "20"
}

// Create the Google Container Cluster
resource "google_container_cluster" "primary" {
  name = "${var.cluster_name}"
  zone = "${var.gcp_zone}"
  initial_node_count = 3

  master_auth {
	username = "admin"
	password = "${random_id.password.b64}"
  }

  node_config {
	oauth_scopes = [
	  "https://www.googleapis.com/auth/compute",
	  "https://www.googleapis.com/auth/devstorage.read_only",
	  "https://www.googleapis.com/auth/logging.write",
	  "https://www.googleapis.com/auth/service.management.readonly",
	  "https://www.googleapis.com/auth/servicecontrol",
	  "https://www.googleapis.com/auth/monitoring",
	]
	machine_type = "n1-standard-2"
  }

  provisioner "local-exec" {
	command = "gcloud container clusters get-credentials ${var.cluster_name} --zone ${google_container_cluster.primary.zone}"
	}
}

resource "kubernetes_service" "ingress_service" {
	metadata {
		name = "ingress-service"
	}
	spec {
		selector {
			name = "nginx-ingress-daemon-set"
		}
		type = "LoadBalancer"
		port {
			name = "http"
			port = 80
			target_port = 80
		}
		port {
			name = "https"
			port = 443
			target_port = 443
		}
	}
}

[e-max]

I've splitted PR.

[e-max]

Regarding the tests - I am not sure that I understand how I can properly test this case without using real GKE cluster. I would love to hear any suggestions.

[radeksimko]

I was able to reproduce the issue, I'll take a look if there's any reasonable way to test this.

[2color]

👍

Experiencing the same here.

[bonifaido]

Could we import the whole auth package? I have a very similar issue, which could be solved with that: #8

[radeksimko]

I took some time to read the relevant code to understand the problem better and I agree with @bonifaido - we should initialize all available auth providers - that is

_ "k8s.io/client-go/plugin/pkg/client/auth"

which also means adding more packages to vendor.

There are currently 3 (azure, gcp and oidc) so it shouldn't cause any performance issues and when the list grows we can revisit the decision/solution.

@e-max Would you mind updating the PR accordingly, so we can resolve the issue?

I managed to create a test for it here: https://github.com/terraform-providers/terraform-provider-kubernetes/compare/b-test-auth-providers#diff-5b8f5184f088cd547dff9f4eb33ad883R35 - feel free to cherry-pick that to you branch - or I can do it prior to merging.

[e-max]

Yes, sure - I'll take care of it later today.

[e-max]

Hm. We have a small impediment here. We use 3.0.0-beta.0 version of go-client. Azure auth plugin was added later. Should I switch to the latest master or we will wait for the next tagged version of go-client?

[radeksimko]

We certainly want to keep it pinned to a tag, ideally - happy to leave out Azure here, until it becomes part of a tagged release in which case we'd raise a separate PR.

Would you mind submitting the vendor changes separately - as before, please? 😃

[radeksimko]

Oh, I missed #11 sorry - just looking at it 👀

[radeksimko]

@e-max I decided to rebase your branch and remove the vendor commit from here as it's already in master & force push to speed things up and finish this PR. I hope you don't mind.

Thanks for all the work and patience in all the feedback loops. 👍 🎉

[mattes]

Thank you @e-max and everyone for fixing!

[2color]

Thanks @e-max

[burdiyan]

I still have this issue in v0.9.10 of Terraform.

[e-max]

@burdiyan You should try terraform v.0.10+ with terraform-provider-kubernetes built from a master branch.
Since 0.10 terraform has extracted providers in external projects.

[burdiyan]

@e-max It worked, thanks a lot! So on Terraform v0.9.10 the Kubernetes provider is broken then?

[svenmueller]

i'm running version Terraform v0.9.11 and still get the following error. Any idea how to solve this?

* module.kubernetes.provider.kubernetes: Failed to configure: No Auth Provider found for name "gcp"

[radeksimko]

Per changelog this bugfix was released in 0.1.1 which is available via any of the 0.10 recent beta Terraform releases.

There are no plans of backporting this to 0.9.