Role parameter for `aws_eks_cluster_auth`

jbarop commented 3 years ago

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

When an EKS cluster is created, only the IAM user who created cluster has access to it. To grant access to other users, there are 2 possibilities. Adding the individual users to the aws-auth-ConfigMap or the user needs to assume a role just before generating a token.

The later is currently not possible with aws_eks_cluster_auth because a role cannot be specified. Using the token without assuming the role will result in an Unauthorized error.

aws-iam-authenticator help token
  [...]
  -r, --role string            Assume an IAM Role ARN before signing this token
  [...]

New or Affected Resource(s)

aws_eks_cluster_auth

Potential Terraform Configuration

data "aws_eks_cluster_auth" "cluster" {
  name     = aws_eks_cluster.cluster.id
  role_arn = aws_iam_role.role.arn
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
  version                = "~> 1.11"
}

Workaround:

I found a workaround by using a second aws provider configuration. But I think it would be nice if aws_eks_cluster_auth could do this directly. Especially because aws-iam-authenticator already offers the option.

provider "aws" {
  alias  = "role_assumed"
  region = data.aws_region.current.name
  assume_role {
    role_arn = aws_iam_role.role.arn
  }
}

data "aws_eks_cluster_auth" "cluster" {
  provider = aws.role_assumed
  name     = aws_eks_cluster.main.id
}

provider "kubernetes" {
  host                   = data.aws_eks_cluster.cluster.endpoint
  cluster_ca_certificate = base64decode(data.aws_eks_cluster.cluster.certificate_authority.0.data)
  token                  = data.aws_eks_cluster_auth.cluster.token
  load_config_file       = false
  version                = "~> 1.11"
}

References

0000

bryantbiggs commented 1 year ago

with the Kubernetes provider, as well as Helm and kubectl providers, the exec() method of authentication is preferred over the static token using the describe-addon-versions data source. With the exec() method you are able to use an assumed role for authenticating to the cluster

benben commented 1 month ago

@bryantbiggs What is the reason exec() is preferred? I think it is much cleaner to let the provider deal with it through aws_eks_cluster_auth instead of shelling out to awscli, which means I also need to have a fully working and authenticated awscli environment available where I do my CI. Also from whats written in the current docs[1], it seems like the token is pretty much the same short-lived token as you would get from using exec().

[1] https://registry.terraform.io/providers/hashicorp/aws/latest/docs/data-sources/eks_cluster_auth

bryantbiggs commented 1 month ago

https://registry.terraform.io/providers/hashicorp/kubernetes/latest/docs#exec-plugins

lorengordon commented 4 days ago

Yeah, I agree with @benben... The exec method feels kinda scummy, shelling out and requiring another binary, which in this case, the shell environment also needs to be setup to authenticate to aws. Much nicer to have options fully contained by the Terraform provider binaries.

bryantbiggs commented 4 days ago

Much nicer to have options fully contained by the Terraform provider binaries.

I would suggest opening an issue on the respective provider to improve that process - its not related to the AWS provider though

hashicorp / terraform-provider-aws