Terraform-aws-eks: Consider other options for cluster authentication (AWS CLI, aws-iam-authenticator, eksctl)

[romatr]

I have issues

I'm submitting a feature request

What is the current behavior?

aws-iam-authenticator is used by default for authenticate using IAM in kubeconfig template.

What's the expected behavior?

The Amazon Elastic Container Service for Kubernetes (EKS) command line interface (CLI) now includes a sub-command for generating the authentication token required for connecting to their Kubernetes cluster using the command line.

Are you able to fix this problem and submit a PR? Link here if you have already.

Not sure, just a proposal for now.

[max-rocket-internet]

Cool but this is just swapping out aws-iam-authenticator for eksctl, right? Is the some advantage to one over the other?

[romatr]

Yes, it is for replacing defaults for auth command in generated kubeconfig. I think here https://github.com/terraform-aws-modules/terraform-aws-eks/blob/d6fa9f48ff02b0d6ddb7e3ce17d2a5e5c71f535a/variables.tf#L191 and here https://github.com/terraform-aws-modules/terraform-aws-eks/blob/d6fa9f48ff02b0d6ddb7e3ce17d2a5e5c71f535a/data.tf#L54
If AWS EKS now supports a native API command, why use a 3rd party 🤷‍♂

[max-rocket-internet]

But aws-iam-authenticator is maintained by AWS employees, part of the Kubernetes SIGs. And I think it was jointly created by AWS and Heptio before Heptio was acquired by VMware? And eksctl is a tool from Weaveworks, a third party, I think?

I don't really have an opinion either way though 🤷‍♂

[jkpl]

Cool but this is just swapping out aws-iam-authenticator for eksctl, right? Is the some advantage to one over the other?

I don't think this issue is about replacing aws-iam-authenticator with eksctl, but with AWS CLI itself. As of version 1.6.59, the AWS CLI includes a sub-command that can be used for EKS authentication similar to aws-iam-authenticator. The update-kubeconfig sub-command in AWS CLI now generates a config that uses AWS CLI directly. This means that there's one dependency less for most users.

Here's an example output from aws eks update-kubeconfig:

users:
- name: arn:aws:eks:us-east-1:1234567890123:cluster/mycluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1alpha1
      args:
      - --region
      - us-east-1
      - eks
      - get-token
      - --cluster-name
      - mycluster
      command: aws
      env: null

[jkpl]

BTW, these module settings work great, if someone wants to try using the AWS CLI for auth with this module:

kubeconfig_aws_authenticator_command = "aws"
kubeconfig_aws_authenticator_command_args = [
    "--region",
    "${var.region}",
    "eks",
    "get-token",
    "--cluster-name",
    "${var.cluster_name}",
    "--role",
    "${var.my_role}",
]

[confiq]

yeah, but how will we know which version of aws-cli is installed on user machine?
The question is just, what default will be... I would still vote for aws-cli.

[dpiddockcmp]

We run terraform and this module from a container. aws-iam-authenticator is a much smaller dependency than aws cli and a whole python environment. I don't mind which is the default as long as it's not changed in a minor release and we can still use the other. And it would be good to document how to use the other authenticator with the module.

[jkpl]

@dpiddockcmp Fair point! I had assumed that most people using AWS with Terraform would have the CLI installed as well, which would have made aws-iam-authenticator redundant. However, as you pointed out, this is not the case everywhere. I now think that preserving the existing behaviour is better since overriding it is already very easy.

[reegnz]

I would prefer that the module detects if I have the cli and use that. I don't want to install aws-iam-authenticator when I already have the aws cli handling this for me.

Could we fall back to aws-iam-authenticator only in cases when the CLI is not present?

[wolf31o2]

The other way around would match the existing behavior. Check for aws-iam-authenticator, fall back to aws, else fail.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This issue has been automatically closed because it has not had recent activity since being marked as stale.