Context
A Kubernetes service account identifies a workload inside a cluster. It does not automatically give that workload an AWS IAM role. EKS Pod Identity and IAM roles for service accounts, usually called IRSA, connect these two identity systems using different credential-delivery paths. The operational goal is predictable role selection for each application.
Prerequisites for a useful comparison
Record the cluster, namespace, service account, node environment, application SDK versions, required AWS actions and target resource accounts. Review one real deployment manifest rather than a chart's unused default values. Establish a nonproduction resource against which the workload can exercise its intended permissions.
AWS recommends Pod Identity for new workloads where supported. IRSA remains useful for existing OIDC designs and environments outside Pod Identity support, including the documented Fargate and Windows cases. Verify the current support details for your nodes before planning a migration.
1. Map the configured trust path
For Pod Identity, inspect the association between the cluster, namespace, service account and IAM role. Check the role's trust for the EKS Pod Identity service principal and the required agent arrangement on the applicable nodes. For IRSA, inspect the cluster's OIDC provider and the role's web-identity trust conditions, including the intended service-account subject.
Do not mix an operator's cluster access with workload AWS access. A person being able to run kubectl says nothing about which AWS role a pod can assume. Record the application permission policy separately from the mechanism that delivers credentials.
2. Check the application's actual credential provider
Inspect SDK support and initialization code. Pod Identity uses the container credential provider in the default chain; IRSA uses a web identity token exchanged through STS. A supported SDK still may select another identity if the application supplies explicit credentials or has an earlier provider available.
Review configuration names and deployment sources without printing credential values. Look for old access-key injection, an explicitly selected profile, or application code that constructs a fixed credential provider. Migrate one test deployment first, then remove the superseded credential mechanism through the approved secret-management workflow.
3. Prove identity and permissions independently
| Observation | Likely explanation | Evidence to collect |
|---|---|---|
| Pod starts but calls use an older role | Earlier credential provider wins | Caller identity and SDK configuration |
| Intended role is used but resource access fails | Permission policy or resource policy differs | Exact action, resource and denial |
| Only some nodes fail | Agent or node-support difference | Pod placement and agent health |
| New service account works, old one fails | Mapping or trust subject differs | Namespace and account association |
An explicitly illustrative scenario: a report worker gains a Pod Identity association but still accesses the staging bucket. Its deployment injects legacy credentials ahead of the container provider. The team verifies the unexpected caller identity, removes that injection from a test release, and confirms the intended role can read only its approved report prefix. Expanding the new role's permissions would not change credential precedence.
Correct, verify, and preserve ownership
Apply the smallest correction to mapping, SDK usage, agent deployment or policy. Restart test pods as required so new launch configuration is exercised. Verify both an allowed operation and a harmless denied operation against controlled test resources. Keep caller identity evidence free of tokens and keys.
Document which team owns IAM trust, cluster associations, application SDK updates and resource authorization. Monitor access-denied trends by workload and review identity behavior after node or SDK upgrades. During migration, retain a clear rollback plan for configuration while avoiding simultaneous uncontrolled credential sources. A reliable outcome is an application identity that the on-call engineer can explain from deployment to resource.
Explore Clouvenix containers kubernetes for implementation and operational handover.
Technical reference
Service-account identity comparison, Pod Identity credential flow, and multi-account identity guidance describe the supported choices.