Skip to content

Update service-accounts.adoc #1058

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 19, 2025
Merged

Update service-accounts.adoc #1058

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
bca508f
Update service-accounts.adoc
liwadman Jul 10, 2025
5ff43f5
add xref and aws entity
geoffcline Jul 11, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
9 changes: 9 additions & 0 deletions latest/ug/manage-access/aws-access/service-accounts.adoc
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,6 +90,11 @@ EKS Pod Identity offers cluster administrators a simplified workflow for authent

At a high level, both EKS Pod Identity and IRSA enables you to grant IAM permissions to applications running on Kubernetes clusters. But they are fundamentally different in how you configure them, the limits supported, and features enabled. Below, we compare some of the key facets of both solutions.

[NOTE]
====
{aws} recommends using EKS Pod Identities to grant access to {aws} resources to your pods whenever possible. For more information, see <<pod-identities>>.
====

[%header,cols="3"]
|===
|Attribute
Expand All @@ -109,6 +114,10 @@ At a high level, both EKS Pod Identity and IRSA enables you to grant IAM permiss
|EKS Pod Identity doesn't require users to define trust relationship between IAM role and service account in the trust policy, so this limit doesn't apply.
|In IRSA, you define the trust relationship between an IAM role and service account in the role's trust policy. By default, the length of trust policy size is `2048`. This means that you can typically define 4 trust relationships in a single trust policy. While you can get the trust policy length limit increased, you are typically limited to a max of 8 trust relationships within a single trust policy.

|STS API Quota Usage
|EKS Pod Identity simplifies delivery of {aws} credentials to your pods, and does not require your code make calls with the {aws} Security Token Service (STS) directly. The EKS service handles role assumption, and delivers credentials to applications written using the {aws} SDK in your pods without your pods communicating with {aws} STS or using STS API Quota.
|In IRSA, applications written using the {aws} SDK in your pods use tokens to call the `AssumeRoleWithWebIdentity` API on the {aws} Security Token Service (STS). Depending on the logic of your code on the {aws} SDK, it is possible for your code to make unneccesarry calls to {aws} STS and receive throttling errors.

|Role reusability
|{aws} STS temporary credentials supplied by EKS Pod Identity include role session tags, such as cluster name, namespace, service account name. Role session tags enable administrators to author a single IAM role that can be used with multiple service accounts, with different effective permission, by allowing access to {aws} resources based on tags attached to them. This is also called attribute-based access control (ABAC). For more information, see <<pod-id-abac>>.
|{aws} STS session tags are not supported. You can reuse a role between clusters but every pod receives all of the permissions of the role.
Expand Down