EKS Pod Identity

EKS Pod Identity is a newer AWS mechanism for delivering credentials to EKS pods without requiring an OIDC federation in the IAM trust policy. Securitain identifies these roles from their trust policies and surfaces the same IAM posture analysis available for all machine identities.

What EKS Pod Identity is in IAM terms

In the traditional IRSA model, the IAM role's trust policy contains the OIDC federation and the Kubernetes subject condition. In the Pod Identity model, the trust relationship is simpler on the IAM side: the role trusts the EKS Pod Identity service principal, which is an AWS service — not an external OIDC provider. The mapping from which pods assume which role is configured as a Pod Identity association in the EKS cluster, not in the IAM trust policy itself.

From AWS's perspective this is a standard service-principal trust: the EKS Pod Identity Agent running on each node exchanges a credential on behalf of a qualifying pod. The IAM role then applies the same policy evaluation as any role — permission boundaries, SCPs and resource policies apply.

The trust-policy pattern Securitain recognizes

When Securitain reads a role's trust-policy document and finds a Service principal for the EKS Pod Identity service, it classifies the role as EKS Pod Identity at high confidence. No condition narrowing to a namespace or service account appears in the IAM trust policy for Pod Identity roles — that scoping lives in the EKS Pod Identity association, which Securitain does not read.

IRSA vs Pod Identity: what Securitain can see

Classification and confidence

A role whose trust policy contains the EKS Pod Identity service principal is classified at high confidence. Confidence is lower when the trust-policy document could not be resolved for the role — that state is stated on the record rather than silently omitted.

A role with both a Pod Identity service principal and another principal (for example, also trusting Lambda) is classified by the highest-evidence tier and both principals are reported.

Where to find Pod Identity roles

Open Exposure → Machine Identities and filter by type EKS Pod Identity. You can also reach any specific role through the IAM Analyzer, where the trust-policy panel shows the Pod Identity service principal directly.

What Securitain surfaces per role

• Trust-policy principal — the EKS Pod Identity service principal that produced the classification
• Effective permissions — what the role can do after permission boundaries, SCPs and resource-policy denies are applied
• Blast radius — reachable targets and potential scope of impact if the role's credentials are misused
• Privilege escalation paths — whether the role can reach a stronger capability than intended
• Sensitive permissions — high-consequence actions the role holds, such as IAM mutation, PassRole or secret access

Security risks to investigate

1. Over-scoped permissions — a Pod Identity role scoped to a single microservice that holds broad S3 or IAM access has far more privilege than the workload needs. Least Privilege analysis compares granted vs observed access.
2. Privilege escalation paths — a workload role that can create or modify IAM policies, assume other roles, or pass roles to services can escalate to higher privilege outside the cluster boundary.
3. Sensitive permissions held directly — IAM mutation, Secrets Manager access, KMS key management and similar permissions represent a high-consequence target if the Pod Identity association is misconfigured or the node is compromised.
4. Shared Pod Identity roles — if the same IAM role is associated with multiple unrelated workloads in EKS (visible through AWS console or CLI, not in Securitain), a compromise of any one workload gains the permissions of all. Securitain surfaces the role's full permission scope regardless of how many associations exist.

What is not in scope