EKS IRSA — IAM Roles for Service Accounts

EKS IRSA lets Kubernetes pods assume an IAM role via the cluster's OIDC provider. Securitain identifies these roles from their trust policies and surfaces their blast radius, effective permissions and privilege escalation context — without accessing the cluster API.

What IRSA is in IAM terms

IAM Roles for Service Accounts (IRSA) is an AWS mechanism that lets a Kubernetes service account exchange a Kubernetes-issued OIDC token for short-lived AWS credentials by assuming an IAM role. From AWS's perspective, the trust relationship is a standard OIDC federation: the IAM role trusts a specific OIDC provider (the EKS cluster endpoint), and conditions in the trust policy narrow which Kubernetes subjects can assume the role.

The IAM role carries real permissions and is subject to the same policy evaluation as any other role — permission boundaries, SCPs and resource policies apply in full. The Kubernetes layer (which pod gets which service account) is outside what IAM enforces.

The trust-policy pattern Securitain recognizes

Trust policy
  Principal → Federated: oidc.eks.<region>.amazonaws.com/id/<CLUSTER_ID>
  Condition  → StringEquals
                 <oidc-provider>:sub = system:serviceaccount:<namespace>:<service-account>
                 <oidc-provider>:aud = sts.amazonaws.com

Securitain reads the collected trust-policy document for every IAM role. When it finds a Federated principal whose value matches an EKS OIDC endpoint pattern and whose condition includes a system:serviceaccount: subject, the role is classified as EKS IRSA at high confidence.

The subject condition and why it matters

The subject condition in the trust policy determines which Kubernetes service accounts can assume the role. This is the only IAM-layer control that narrows IRSA access to a specific workload — the Kubernetes annotation on the service account is the other half, but it is outside IAM.

• Narrowed subject — system:serviceaccount:production:payments-worker restricts the role to one service account in one namespace. This is the intended security posture for IRSA.
• Wildcard namespace — system:serviceaccount:*:payments-worker allows any namespace's service account with that name to assume the role.
• Wildcard or absent subject condition — any Kubernetes service account on any cluster that trusts the OIDC provider can assume the role. This is the widest possible exposure for IRSA.

Classification and confidence

When trust-policy collection succeeds and the IRSA pattern is present, the role is classified at high confidence. Confidence can be lower when:

• the trust-policy document could not be resolved for this role (lower confidence is stated on the record, not silently omitted)
• the role has a mixed trust policy — for example, both an EKS OIDC Federated principal and an EC2 service principal. Both classifications are reported; the highest-evidence tier determines the primary type.

Where to find IRSA roles

Open Exposure → Machine Identities and filter by type EKS IRSA. Each row is a classified IAM role. You can also open any IAM role directly from the IAM Analyzer — the trust policy panel there shows the OIDC principal and subject condition without navigating to Machine Identities.

What Securitain surfaces per role

• Trust-policy principals and conditions — the OIDC endpoint, the subject condition value, and whether the audience condition is present
• Effective permissions — what the role can do after permission boundaries, SCPs and resource-policy denies are applied (see Effective Permissions)
• Blast radius — the reachable targets and potential scope of impact if the role is compromised (see IAM Blast Radius)
• Privilege escalation paths — whether the role can reach a stronger capability than it was intended to hold (see Privilege Escalation & Attack Paths)
• Sensitive permissions — whether the role holds high-consequence permissions such as IAM mutation, PassRole or data-plane access

Security risks to investigate

1. Absent or wildcard subject condition — any service account on any trusting cluster can assume the role. Look for a specific StringEquals condition on the subject.
2. Over-scoped permissions — an IRSA role scoped to a payment worker that holds s3:* or iam:* has far broader access than the workload needs. Use Least Privilege analysis to compare granted vs observed access.
3. 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 Kubernetes boundary.
4. Sensitive permissions held directly — IAM mutation, Secrets Manager access, KMS key management and similar permissions on a workload role represent a high-consequence target for a compromised pod.
5. Multiple OIDC providers trusted — a role whose trust policy lists more than one OIDC Federated principal is accessible from more than one cluster. Each additional trusted cluster widens the attack surface.

What is not in scope