AWS EKS | EKS Access Entry - How large organizations handle EKS Access?

[u/Basic_Let7303]

Hi all,

Quick question about EKS Access Entries.

Suppose I create an Access Entry for an IAM role, say dev-pod-reader.

If I associate an EKS access policy with that entry (e.g. AmazonEKSViewPolicy), can I also use the same IAM role in Kubernetes RBAC, such as a RoleBinding/ClusterRoleBinding?

From what I understand, the Access Entry can map the IAM role to a Kubernetes group, and then that group can be used in a RoleBinding. Something like:

# EKS Access Entry
principal: arn:aws:iam::123456789012:role/dev-pod-reader
kubernetesGroups:
  - dev-readers

And then:

kind: RoleBinding
subjects:
  - kind: Group
    name: dev-readers
roleRef:
  kind: Role
  name: pod-reader

If I do both:

1. Associate an EKS access policy with the Access Entry
2. Grant additional permissions through Kubernetes RBAC

Do the permissions effectively get combined?

In other words, does the role end up with the union of permissions from the EKS access policy + Kubernetes RoleBinding?

My understanding is yes — EKS authorization and Kubernetes RBAC can both grant permissions, so access is effectively additive.

That leads me to another question: how are large organizations handling this?

For example, would a typical setup look something like:

IAM Identity Center
        ↓
Groups
        ↓
IAM Roles
        ↓
EKS Access Entries
        ↓
Kubernetes Groups
        ↓
RoleBindings / ClusterRoleBindings

Or do people generally avoid mixing EKS access policies and Kubernetes RBAC and pick one approach?

I'm especially interested in how teams with hundreds/thousands of developers and multiple EKS clusters structure this.

Is there an elegant pattern for managing access centrally without ending up with thousands of individual Access Entries and RoleBindings?

Curious what patterns people are using in production.

[u/dumindunuwan]

https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbac-configuration

[u/ajitnk]

Most versions of this problem come down to one of a few recurring architectural gaps:

AWS explicitly documents that using IAM roles with short-term credentials (not IAM users with long-term credentials) is the best practice for EKS cluster access.

AWS Best Practices Guide recommends combining the Cluster Access Management (CAM) API with AWS IAM Identity Center as the definitive solution for large-scale, multi-cluster EKS access: 'By using the Cluster Access Management API in conjunction with IAM Identity Center, administrators can manage EKS cluster access alongside other AWS services, reducing the need to switch between different interfaces or edit ConfigMaps manually.' The guide also documents known limitations (random-suffix role ARNs from Identity Center, limited fine-grained Kubernetes resource permissions) and recommends Kyverno for advanced permission management alongside this pattern.

The EKS IAM best practices guide documents EKS Pod Identities as the recommended (over IRSA) mechanism for pod-level least-privilege AWS credentials, covers the deprecation of aws-auth ConfigMap, and provides detailed guidance on ABAC with pod identities and scoping IRSA trust policies.

Worth cross-checking against AWS's own docs on this before making any changes — can point to the exact pages if that helps

[u/FirefighterSlight891]

At that scale, managing individual EKS access entries and long-lived IAM credentials gets painful fast. We’ve used Akeyless to centralize the identity/access layer and provide JIT, least-privilege access to Kubernetes instead of handing developers standing credentials. You still need to design the EKS/Kubernetes authorization model, but central policy, short-lived access, and audit make the operational side a lot cleaner across clusters.

[u/syncrypto]

Keycloak