Kubernetes & EKS Workload Identity

Understand how Amazon EKS workloads assume IAM roles and how Securitain surfaces the IAM security posture of those workload identities — from trust-policy classification through blast radius, effective permissions and privilege escalation.

Why workload identity is an IAM concern

When an EKS pod assumes an IAM role it receives real AWS credentials with real permissions. The risk profile of that role is identical to any other IAM role: if the role is over-scoped, holds sensitive permissions, carries a privilege escalation path, or trusts a broader set of principals than intended, the cluster workload inherits those risks directly.

The distinction from human identities is operational scale. A misconfigured IRSA role may be assumed simultaneously by every replica of a deployment across a namespace. Because credential issuance is automated and short-lived, over-permissive workload roles are frequently invisible to manual IAM review — they never appear in the credential report and rarely generate CloudTrail events that stand out against background workload traffic.

Two EKS workload identity patterns

EKS IRSA — IAM Roles for Service Accounts

IRSA lets a Kubernetes service account annotated with an IAM role ARN assume that role via the cluster's OIDC provider. The IAM role's trust policy contains a Federated principal pointing to the cluster OIDC endpoint, with a condition narrowing the subject to a specific service account (system:serviceaccount:namespace:name). Securitain identifies IRSA roles from that trust-policy pattern.

A condition that narrows the subject to a specific namespace and service account is the correct security posture for IRSA. The absence of that condition — for example, a wildcard subject — means any service account in any namespace on any cluster trusting that OIDC provider can assume the role.

EKS Pod Identity

EKS Pod Identity is a newer mechanism where the EKS Pod Identity Agent running on each node delivers credentials to pods without requiring an OIDC trust relationship in the IAM role. The IAM role's trust policy contains a Service principal for the EKS Pod Identity service. Namespace and service-account mapping is configured in EKS Pod Identity associations — not in the IAM trust policy — so the trust policy alone does not reveal which pods can assume the role.

How Securitain classifies workload identities

Classification reads the actual trust-policy document collected from IAM and follows a strict evidence order. Names and tags are unreliable signals and are only used when trust-policy evidence is absent:

• Federated OIDC principal with a system:serviceaccount: subject condition → EKS IRSA, high confidence
• EKS Pod Identity service principal → EKS Pod Identity, high confidence
• Customer-set purpose tags on the role → medium confidence, reported as customer-supplied and unverified in the product
• Role name alone → low confidence, explicitly flagged as a guess

What you can investigate

Under Exposure → Machine Identities, each classified EKS workload role surfaces:

• identity type (EKS IRSA or EKS Pod Identity) and classification confidence
• blast-radius score — the potential scope of impact if the role's credentials are misused or the workload is compromised
• effective permissions — what the role can do after permission boundaries, SCPs and explicit denies are applied
• privilege escalation paths — whether the role can reach a stronger capability than it was intended to hold
• the trust-policy principals and subject conditions that produced the classification, including any missing conditions that widen access

What is not in scope