Skip to content

Pod Identity versus IRSA for Amazon EKS - Part 1

When managing containerized applications on Amazon Elastic Kubernetes Service (EKS), a critical concern is securely granting permissions to your applications so that they can securely access AWS resources. Traditionally, AWS has provided mechanisms like IAM Roles for Service Accounts (IRSA) to enable fine-grained permissions management within EKS clusters. However, EKS Pod Identity, a newer feature, offers a more refined and efficient solution.

In this blog, we’ll explore how EKS Pod Identity differs from IRSA, and why it represents a significant improvement for identity management in Amazon EKS based environments. Let's assume our EKS cluster resident application needs to securely access data in an AWS s3 bucket.

App Accessing AWS S3

Background

AWS Identity and Access Management (AWS IAM) centralizes identity management and access control for AWS resources. It focuses on Role Based Access Control (RBAC) to create and manage AWS users, groups, and roles, and assign permissions to them.

Roles are not associated with a specific individual. It is a best practice to define the purpose of a role to a specific function/service. Roles are assumed by entities such as users or applications. They define the permissions an application or service can have while interacting with your AWS resources.

How IRSA Works

IAM Roles for Service Accounts (IRSA) is the current method provided by AWS to map Kubernetes service accounts to IAM roles. IRSA allows you to securely assign IAM roles to pods so they can access AWS resources without needing static or long-term credentials.

Here’s a high-level overview of how IRSA works:

  1. Kubernetes Service Accounts are mapped to IAM roles using an OpenID Connect (OIDC) Identity Provider.
  2. The pod assumes the IAM role associated with the service account, providing it with the permissions needed to access AWS services.

Before IRSAs, organizations were forced to operate with a poor security posture because they had to

  • Store AWS credentials in pods and
  • Enable fine-grained permissions for each workload.

While IRSA offers a robust method for securing access to AWS services, it has its limitations especially when operating very large, multi-tenant EKS clusters.

IRSA Workflow

What is EKS Pod Identity?

EKS Pod Identity introduces a new way of assigning IAM roles directly to Kubernetes pods without relying on service accounts. This brings several improvements in terms of flexibility, security, and operational efficiency.

With Pod Identity: 1. You assign IAM roles directly to pods rather than relying on a service account. 2. The pod identity controller (i.e. a daemonset running on the EKS cluster) ensures that each pod has the appropriate IAM role, without needing to link to an OpenID Connect identity provider or manage service account mappings.

Unlike IRSAs, with Pod Identity, notice that the IAM roles are decoupled from service accounts. This dramatically simplifies the permission model and offers more fine-grained control over resource access.

Pod Identity Workflow

Key Differences

We frequently encounter customers that ask us for the differences between IRSA and Pod Identity. The description below captures the primary differences.

  1. Decoupling of IAM Roles from Service Accounts:

  2. IRSA relies on mapping IAM roles to Kubernetes service accounts. This introduces a layer of complexity when managing multiple services or applications that need distinct IAM roles. In contrast, EKS Pod Identity eliminates this dependency, allowing for more direct role-to-pod assignments, making it easier to manage at scale.

  3. Scalability and Simplicity:

  4. As clusters grow, the number of service accounts and associated role mappings in IRSA can become challenging to manage. Pod Identity simplifies this by allowing you to assign IAM roles directly to pods, reducing overhead and making it easier to manage permissions for large, multi-tenant environments.

  5. Granular Control:

  6. While IRSA does offer fine-grained permissions, it can be cumbersome when you need to assign unique permissions to specific pods within the same namespace or across multiple namespaces. With EKS Pod Identity, you can assign roles on a per-pod basis, providing more granular control over permissions.

  7. Reduced Dependency on OIDC:

  8. IRSA requires setting up and managing an OpenID Connect (OIDC) provider to link Kubernetes service accounts to IAM roles. EKS Pod Identity removes this need, streamlining the setup process and reducing the operational complexity associated with managing OIDC integrations.

  9. Improved Security:

  10. By decoupling roles from service accounts and offering more fine-grained control over IAM role assignments, EKS Pod Identity reduces the risk of privilege escalation or excessive permissions within a cluster. Each pod gets the precise permissions it needs, nothing more, ensuring that security best practices are upheld.

Why EKS Pod Identity is Better

The question we get frequently from customers is "Going forward, should I standardize on Pod Identity?". Let's review areas where Pod Identity is superior to IRSA.

  1. Enhanced Security Posture: EKS Pod Identity provides a more secure and efficient way to manage permissions. By allowing direct role-to-pod assignments, it reduces the risk of misconfigurations or over-privileged roles. Additionally, since there is no reliance on service accounts, you minimize the potential attack surface that can arise from poorly configured or shared service accounts.

With IRSAs, although you can reuse a role between clusters, every pod receives all of the permissions of the role.

  1. Operational Efficiency: Managing IRSA at scale can be a complex and time-consuming process. As clusters grow, managing the relationships between service accounts and IAM roles becomes increasingly difficult. EKS Pod Identity simplifies this process, making it easier for teams to scale their Kubernetes environments without the overhead of maintaining numerous service account mappings.

With IRSAs, you need to define trust relationship between an IAM role and service account in the trust policy. It is extremely common for users to hit the max of 8 trust relationships within a single trust policy due to size limits for trust policies.

  1. Better Control for Multi-Tenant Environments: In environments where multiple teams or applications share a cluster, having fine-grained control over permissions is essential. EKS Pod Identity’s ability to assign roles on a per-pod basis offers better isolation and security for multi-tenant clusters.

  2. Simplified Onboarding and Maintenance: Setting up and managing OIDC identity providers in IRSA adds a layer of complexity that can be difficult for teams without deep Kubernetes expertise. EKS Pod Identity streamlines the process, making it easier for teams to onboard applications securely, without having to deal with OIDC-related configurations.

With Pod Identity, organizations do not have to deal with the default global limit of 100 OIDC providers per account.

Conclusion

While IRSA has been an effective solution for managing IAM roles within EKS clusters, EKS Pod Identity represents a significant evolution in how we think about securing Kubernetes workloads on AWS. By simplifying the management of IAM roles, enhancing security, and providing more granular control, EKS Pod Identity is better suited for modern, large-scale, and multi-tenant environments.

For organizations looking to improve their security posture, reduce operational complexity, and scale their Kubernetes clusters more efficiently, adopting EKS Pod Identity over IRSA is a compelling choice. As AWS continues to innovate, features like Pod Identity reflect the growing demand for more secure, scalable, and manageable cloud-native solutions.

Summary

Thanks to readers of our blog who spend time reading our product blogs. Please Contact the Rafay Product Team if you would like us to write about other topics. In parts 2 and 3 of this blog to this, my colleague will write about the following topics related to EKS Pod Identity:

  • Using Pod Identity with Rafay
  • Migrate from IRSA to Pod Identity seamlessly using Rafay

  • Free Org

    Sign up for a free Org if you want to try this yourself with our Get Started guides.

    Free Org

  • 📆 Live Demo

    Schedule time with us to watch a demo in action.

    Schedule Demo

  • Rafay's AI/ML Products

    Learn about Rafay's offerings in AI/ML Infrastructure and Tooling

    Learn More

  • Upcoming Events

    Meet us in-person in the Rafay booth in one of the upcoming events

    Event Calendar