How do AWS "Pod Identities" compare to (OIDC) IRSA?

Question

In Kubernetes clusters, we often wish to provide temporary credentials to the containerised processes running in a particular pod, usually marked by associating the pod with a service account.

• Recently (in late 2023) AWS introduced "EKS Pod Identities", as a new mechanism for associating AWS IAM roles with k8s pods (selected via k8s service account associations).

• Traditional IRSA (IAM Roles for Service Accounts) used OIDC. This involved having configured a trust relationship between the AWS account and the cluster control plane, so that pod processes could exchange their k8s service account tokens for IAM credentials. The AWS SDKs transparently handle this authorisation exchange (also appending role session names taken from an environment variable so as to volunteer finer grained metadata into the logs of accessed AWS services).

IRSA has been strongly advocated as a replacement of passing long-lived IAM keys into pods (which is more susceptible to leakage and demands regular maintenance for credential rotation). IRSA has also been strongly advocated as a replacement of associating IAM roles with EC2 instance host nodes (for compartmentalisation and to mitigate escalation attacks), with many sources advising admins to block or disable the Instance MetaData Service that facilitates instance identity roles.

How do EKS Pod Identities compare to traditional IRSA, particularly from a security standpoint? Is it still implemented identically under the hood (just transparently pre-configuring AWS STS with the thumbprint to recognise each EKS cluster)? The docs suggest EKS Pod Identities is similar to EC2 instance IAM roles, so does the implementation also expose similar fresh security concerns?

Answer 1

EKS Pod Identities are similar to EC2 Instance identity roles only in the sense that they both transparently authenticate SDK-based processes according to where they are run, obviating the need for developers to supply credentials to those workloads.

Kubernetes clusters incorporate the function of an OIDC identity provider, by passing tokens into pods for use by the processes therein to prove (e.g. to external relying parties) which service account they have been run under. The secret token is mounted into a specific path in the container filesystem.

AWS could have just preconfigured their Security Token Service to automatically recognise EKS (i.e. AWS-managed Kubernetes) clusters, to simplify admin configuration but otherwise keep IRSA unchanged. Instead, they've implemented a duplication of the IRSA mechanism, whereby EKS automatically specifies to mount an additional service account token into another path in the pod filesystem. Thus, the new method requires the processes to have been built with a more recent SDK version, and a pod could potentially have three different IAM roles independently available for it through traditional IRSA, new "pod identities" and the host node's instance role, and it is up to the SDK to select which takes precedence. Since AWS singly manages all involved components (EKS, IAM/STS and the SDK) it can be taken as an internal implementation detail how it departs from the previous IRSA/OIDC protocol. As it turns out, the "pod identities" token gets exchanged not directly with the STS service endpoint but instead indirectly with the EKS service endpoint via a daemonset on the node (and this host agent is empowered by the node instance role to procure the exchange).

From a security standpoint it appears to be equivalent to traditional IRSA, in that the privilege is still conferred via a secret token mounted by the pod. In contrast, instance roles are conferred according to which (virtual) network device a request (to the Instance MetaData Service) is routed from. The IMDS is a virtual web-service that the AWS-managed hypervisor exposes solely to the hosted virtual machine, but the credentials can leak if that VM unwittingly proxies traffic to the IMDS. (If the IMDS functions analogous to the "pod identities" host agent, the difference is that using it requires the token obtained through a separate channel.)