CODEWITHSUNDEEP
kuberneteskubernetes-ingressamazon-eks
David Bruce Borenstein
David Bruce Borenstein

Reputation: 1745

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?

Upvotes: 3

Views: 1427

Answers (2)

benjimin
benjimin

Reputation: 4890

Everyone wants pods to assume appropriate IAM roles, ideally configured via service accounts (since those are the native Kubernetes construct for associating a set of permissions with a set of pods). There are multiple ways of doing this:

  • IAM user access keys are discouraged, because these long-lived credentials necessitate manual rotation maintenance to try to minimise the hazard of credential leakage (and nonstandardised schemes to try to pass the credentials into the pod without polluting secrets into the infra-codebase).
  • Node roles (EC2 instance roles attached to the Kubernetes worker nodes) are discouraged (or rather, their permissions should be limited to the minimum necessary for the node to join itself to the cluster and to procure container images to start pods, and the pods must all be blocked from accessing the IMDS which imbues instances with these temporary IAM credentials. Note the IMDS is a virtual service API hosted by the hypervisor to the instance VM, and accessed by the AWS SDK to retrieve temporary credentials). Node roles violate best-practice compartmentalisation, because the same permission set is granted to all pods that share the same host, rather than restricting particular privileges to just the specific pods intended to use them.
  • Traditional IRSA, whereby AWS STS uses OIDC to entrust the kubernetes control plane to identify the pod. (The control plane injects crypto tokens into the pods, which the AWS SDK in the pod exchanges with STS for temporary IAM credentials.)
  • EKS Pod Identities, whereby an agent run on all nodes retrieves credentials for pods. (Another identifying token is injected into the pod, and the AWS SDK in the pod connects to the host agent to get it exchanged with EKS for temporary credentials.)
  • kube2iam, whereby an agent run on each node spoofs the EC2 IMDS (so that pods all think they are accessing the EC2 instance role, but actually different pods on the same node are passed credentials of different roles). Incidentally, this is configured using pod annotations rather than service accounts.

FWIW, I prefer IRSA because OIDC is a standard approach used by Kubernetes (and many other services) and does not require privileged agents to be configured on the nodes. (For example, IRSA would still work if you ever chose to self-manage the cluster master nodes instead of using EKS for your control plane.)

Development of kube2iam definitely appears to have slowed somewhat since the introduction of IRSA (and subsequently of EKS Pod Identities) and there has been some internal discussion of its obsolescence.

Upvotes: 0

Michael Hausenblas
Michael Hausenblas

Reputation: 13941

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.

Upvotes: 6

Related Questions