Add EKS cluster auth token data resource

[evilmarty]

Allow Terraform to authenticate with an EKS cluster via the Kubernetes provider:

resource "aws_eks_cluster" "foo" {
  name = "foo"
}

data "aws_eks_cluster_auth" "foo_auth" {
  name = "foo"
}

provider "kubernetes" {
  host = "${aws_eks_cluster.foo.endpoint}"
  cluster_ca_certificate = "${base64decode(aws_eks_cluster.foo.certificate_authority.0.data)}"
  token = "${data.aws_eks_cluster_auth.foo_auth.token}"
}

The auth logic was extracted from
https://github.com/heptio/aws-iam-authenticator because of lack of
documentation from AWS. Basically, the token is a signed URL for the
GetCallerIdentity action with a custom header. The URL is then base64
encoded and prefixed with vendor string.

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccAWSEksClusterAuthDataSource_basic'
 ==> Checking that code complies with gofmt requirements...
TF_ACC=1 go test ./... -v -run=TestAccAWSEksClusterAuthDataSource_basic -timeout 120m
?   	github.com/terraform-providers/terraform-provider-aws	[no test files]
=== RUN   TestAccAWSEksClusterAuthDataSource_basic
--- PASS: TestAccAWSEksClusterAuthDataSource_basic (40.47s)
PASS
ok  	github.com/terraform-providers/terraform-provider-aws/aws	40.510s

[wotc-baynhas]

This would be a huge deal for me, and is a major blocker for adoption of the kubernetes provider- not really much of a point to migrate kubectl configs over if I can't have a cluster created and configured with a single apply.

[omeid]

Is there anything holding this up? this would make using kubernetes provider with eks very seamless!

[omeid]

@evilmarty Are you still keen to get this landed? I think rebasing should help move things ahead.

[evilmarty]

@omeid Sure am. I've rebased with master.

[omeid]

@apparentlymart Can you look at this please? this is a very small change that makes a massive difference in using EKS and K8S with Terraform.

[yves-vogl]

Hi,

we'd be also very happy to see this being merge.

Thanks for this great implementation, @evilmarty!

[ktham]

cc @alexsomesan We'd also like to see this merged in being EKS users ourselves. Thanks @evilmarty !

[ktham]

cc @bflad also, we can remove the need for hashicorp/terraform-provider-kubernetes#161 if we get this in, and this would be much cleaner as well.

[ktham]

@evilmarty looks like you need to rebase on master again

[bflad]

Hi @evilmarty (and everyone chiming in) 👋 Thanks for submitting and showing your interest in this new data source. Apologies for the lengthy delay in an initial review.

Due to the lack of AWS/EKS documentation on the matter, we have been hesitant to accept any implementation due to its potential to be incorrect or outdated. I think we are willing to concede a little on this though because the EKS documentation goes through great lengths about using aws-iam-authenticator and this code is currently based off that, which likely means there is some stability for the interface and implementation.

There are few things holding this pull request up though:

• Missing Terraform website documentation for the new data source (sidebar link in website/aws.erb and new website/docs/d/eks_cluster_auth.html.markdown page as noted in https://github.com/terraform-providers/terraform-provider-aws/blob/master/.github/CONTRIBUTING.md#new-resource)
• A lack of inline code documentation surrounding the how's and why's of the implementation (partially AWS/EKS fault on this due to their lack of documentation on the matter, but I would expect to see comments similar to the upstream aws-iam-authenticator ones or at least URL comments pointing to the upstream codebase for context and future maintainability of this code)
• Only limited testing is being performed in the acceptance testing (its currently checking for a non-empty string, how do we know its a valid token?)
• Double checking that a configurable duration value is valid, given some of the notes in the upstream code

I think rather than re-implementing this ourselves which may more maintenance overhead than its potentially worth should the interface or implementation changes on AWS' side in the future, this may actually be a good time to consider vendoring the part of aws-iam-authenticator that handles this: https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/pkg/token/token.go

The upstream code handles most of my concerns by providing an easy GetWithSTS(clusterID string, stsAPI *sts.STS) (Token, error) interface and a verification method Verify(token string) (*Identity, error) which we can acceptance test against.

If we decide to go that path, I would encourage waiting a few days while we switch the repository over to Go modules in preparation for vendoring Terraform 0.12 and beginning 2.0 provider work so you don't wind up with a vendoring pull request that needs to be redone. 👍 I will try to remember to post back here when that's completed.

[evilmarty]

@bflad I agree with you 100%. I was not aware of that project but it a lot of sense to use an existing and supported implementation. I'm happy to make those changes but my time is a little limited right now as I just had a baby girl, which buys me time for Terraform 0.12 to release.

[bflad]

Thanks so much to @evilmarty (congratulations on the baby girl 👶 🎉 ) and @mbarrien this new aws_eks_cluster_auth data source has been merged via #7438 and will release with version 1.58.0 of the Terraform AWS provider, likely in the next day or two.

I'm guessing the co-authorship of commit a6ba529 was enough of a difference for GitHub to not automatically close this PR when #7438 was merged but proper attribution should be in the Git history to @evilmarty for the initial work. 👍

[bflad]

This has been released in version 1.58.0 of the AWS provider. Please see the Terraform documentation on provider versioning or reach out if you need any assistance upgrading.

[evilmarty]

Thanks everyone for your help and guidance in getting this feature merged. Again, apologies for lack of comms recently. Glad that it did not affect the overall outcome.

[ncrothe]

This is a great addition, considering the external script approach was clunky. However, our use case with the external script involved assuming a role (aws-iam-authenticator token -i <clustername> -r <some_IAM_role>). Would it be hard to add an optional role parameter?

The use case behind that is group permissions, i.e. without roles I would need to add every user that needs Kubernetes permissions individually to the aws auth config map (as far as I understand). With roles, I can just give sts:assume for a particular role (that doesn't even need to give any intrinsic permissions) to a group policy for everyone I want to be able to work with eks.

[bflad]

@ncrothe if I'm thinking about this correctly, would setting up an assume role provider configuration suit your need? e.g.

provider "aws" {
  # ... potentially other configuration ...
  alias = "eks_assume_role"

  assume_role {
    role_arn = "arn:PARTITION:iam::ACCOUNTID:role/ROLENAME"
  }
}

data "aws_eks_cluster_auth" "example" {
  provider = "aws.eks_assume_role"
  name     = "example"
}

If not, I would suggest opening a new GitHub issue for further tracking. 👍

[ncrothe]

Great idea, will test that out.

And of course, if not working, I'll open an issue.

[ncrothe]

@bflad Worked like a charm, thank again for the suggestion.

[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. Thanks!