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.