---
title: PodIdentity vs IRSA vs Static AWS Creds: Securing Kubernetes Workloads in the Cloud
author: Victor Olmedo
date: 2026-06-02
tags:
  - AWS
  - Kubernetes
  - Security
  - SecurityX
  - Cloud
  - IAM
---

# Securing Amazon EKS with OIDC and IRSA

## Introduction

Kubernetes workloads often require communication to other AWS services such as S3, Databases like RDS or DynamoDB, Secrets Manager, and CloudWatch. The main challenge is how can you achieve this securely, reliable, and fast. In this post, I'll be discussing how one can minimize risk, maintain operational efficiency, and ultimately secure your kubernetes workloads.

## Traditional Static Credentials

Historically, applications stored AWS Access Keys and Secret Access keys directly in configuration files, environment variables, or kubernetes secrets. Although that works and its the "easy-button" as I like to call it, it introduces several security concerns.
+ long lived credentials
+ credential rotation challenges
+ secret sprawl (my favorite)
+ increased risk of credential leakage

If a kubernetes Secret is exposed or improperly managed, anyone could potentially gain access to your AWS resources until those credentials are either revoked or rotated.

## IAM Roles for Service Accounts (IRSA)

IAM Roles for Service Accounts (IRSA) was introduced to provide a more secure method for granting AWS permissions to kubernetes workloads. When a pod requires access to AWS resources, it receives temporary credentials through a federated trust relationship rather than relying on static access keys.
One of the benefits of IRSA is that it eliminates the need for long term or long lived credentials. Another big part of it is that its auditable with CloudTrail. Think about it, since you're now using an IAM Role, all the api actions that this pod makes, is now being tracked natively in CloudTrail. Integrating with existing IAM controls is another benefit. This uses native IAM Policy's and you are able to leverage the least privilage model when designing or scoping the permissions for your application/workload.
Although there are huge benefits, one of the downsides is that it is more complex. With traditional static keys, you cut the keys and you are done. With IRSA there are more steps, like creating the OIDC provider configuration.

## EKS Pod Identity

The newer capability is Amazon EKS Pod Identity, which is designed to simplify workload authentication within EKS clusters. Pod Identity removes the need and requirement for creating and managing OIDC providers. Instead, AWS manages the authentication workflow between kubernetes workloads and IAM roles.
One of the benefits is that it is a native EKS integration and uses temporary credentials. On the downside, it is only for EKS so if you are wanting to run Rancher or rke or any other kubernetes orchestrator, this will not work.

## Security Comparison

| Capability | Static Credentials | IRSA | Pod Identity |
|---|---|---|---|
| Temporary Credentials | No | Yes | Yes |
| Credential Rotation | Manual | Automatic | Automatic |
| Least Privilege | Limited | Strong | Strong |
| CloudTrail Visibility | Limited | Strong | Strong |
| Secret Management Required | Yes | No | No |
| Operational Complexity | Low | Medium | Low |

## My recommended approach

Organizations operating with Amazon EKS should avoid static AWS credentials whenever possible. There are some legacy applications that are just built this way and will require some static keys, which is fine to a certain degree. Perhaps we should be holding the vendors more accountable and requesting they make a more secure method instead of long lived credentials. Nonetheless, for new EKS deployments in 2026, you should be using EKS pod Identity to provide a simpler operational model. If you are planning on changing your architecture or are future proofing, then I do highly recommend going with IRSA.

## Conclusion

Identity is a foundational part of cloud security. Static credentials pose a risk to your workload but there are ways to minimize risk. Using IRSA and Pod Identity improve your security posture.

## References

- Amazon EKS Documentation
- AWS IAM Documentation
- AWS STS Documentation
- Kubernetes Service Accounts Documentation
- NIST SP 800-207 Zero Trust Architecture