Search code examples
kuberneteskubernetes-ingressamazon-eks

Is Kube2iam unnecessary with, and/or a part of, EKS?

In the Amazon EKS User Guide, there is a page dedicated to creating ALB ingress controllers by using an eponymous third-party tool, AWS ALB Ingress Controller for Kubernetes.

Both the EKS user guide and the documentation for the controller have their own walkthroughs for how to set up the controller.

The walkthrough provided by the controller has you either hard-code your AWS secret key into a Deployment manifest, or else install yet another third-party tool called Kube2iam.

The walkthrough in the AWS EKS user guide has you post exactly the same Deployment manifest, but you don't have to modify it at all. Instead, you create both an IAM role (step 5) and a Kubernetes service account (step 4) for the controller, and then you link them together by annotating the service account with the ARN for the IAM role. Prima facie, this seems to be what Kube2iam is for.

This leads me to one of three conclusions, which I rank in rough order of plausibility:

  1. EKS contains the functionality of Kube2iam as one of its features (possibly by incorporating Kube2iam into its codebase), and so installing Kube2iam is superfluous.
  2. eksctl installs Kube2iam behind the scenes as part of associate-iam-oidc-provider.
  3. The documentation for the controller was written for an earlier version of Kubernetes, and this functionality is now built into the stock control plane.

Does anyone happen to know which it is? Why doesn't the AWS walkthrough need me to install Kube2iam?

Solution

  • Does anyone happen to know which it is? Why doesn't the AWS walkthrough need me to install Kube2iam?

    Yes, I can authoritatively answer this. In 09/2019 we launched a feature in EKS called IAM Roles for Service Accounts. This makes kube2iam and other solutions obsolete since we support least-privileges access control on the pod level now natively.

    Also, yes, the ALB IC walkthrough should be updated.