I'm trying to understand how EKS Access Entries interact with native Kubernetes RBAC. Suppose an IAM role such as `dev-pod-reader` has an EKS Access Entry with the `AmazonEKSViewPolicy` access policy, and the entry also maps the role to a Kubernetes group called `dev-readers`:
```yaml
principal: arn:aws:iam::123456789012:role/dev-pod-reader
kubernetesGroups:
- dev-readers
```
That group could then be referenced by a Kubernetes `RoleBinding` or `ClusterRoleBinding`:
```yaml
kind: RoleBinding
subjects:
- kind: Group
name: dev-readers
roleRef:
kind: Role
name: pod-reader
```
If both the EKS access policy and Kubernetes RBAC grant permissions, are the permissions additive? In other words, does the IAM role receive the union of permissions granted by the EKS policy and the Kubernetes `RoleBinding`?
I'm also interested in production patterns for organizations with hundreds or thousands of developers and multiple EKS clusters. Do teams typically use IAM Identity Center groups mapped to IAM roles, EKS Access Entries, Kubernetes groups, and RBAC bindings? Or is it better to choose either EKS access policies or Kubernetes RBAC and avoid mixing them?
What approaches work well for centrally managing access without creating an unmanageable number of individual Access Entries and bindings?
3 Answers
Yes, access is effectively additive. EKS evaluates its cluster access authorization and Kubernetes RBAC authorization, and a request is allowed if either mechanism grants it. A role can therefore receive permissions from an associated EKS access policy as well as from Kubernetes `RoleBinding` or `ClusterRoleBinding` objects through the groups in its Access Entry.
That flexibility also means overlapping permissions can become difficult to audit. A common approach is to use EKS access policies for broad, standardized cluster access and Kubernetes RBAC for namespace-specific or application-specific permissions. Keep the mapping from identity groups to roles and Kubernetes groups consistent, and avoid granting broad permissions through both systems unless there is a clear reason.
The main scaling trick is to manage groups and reusable roles, not people. Map identity-provider groups to a limited number of IAM roles, map those roles to stable Kubernetes group names, and bind those groups to standard ClusterRoles or namespace Roles. Keep cluster-specific differences in configuration and deploy the access definitions through Terraform, GitOps, or another controlled automation process.
It’s also worth separating human access from pod access. Developers should use short-lived IAM credentials for cluster access, while workloads should use EKS Pod Identity or carefully scoped alternatives for AWS API access. That keeps application permissions from becoming mixed up with human Kubernetes permissions.
For larger environments, IAM Identity Center groups combined with short-lived IAM roles and EKS Access Entries is a strong foundation. It lets the central identity team manage who can access each cluster while avoiding long-lived credentials and manual `aws-auth` ConfigMap changes.
Organizations commonly standardize a small set of access profiles—such as read-only, namespace developer, operator, and cluster administrator—and reuse those profiles across clusters. Automation can create the Access Entries and RBAC bindings from group or role definitions instead of managing each developer individually. More detailed Kubernetes authorization can then be handled with RBAC policy managed as code, and tools such as Kyverno may help when the built-in EKS access policies are not fine-grained enough.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures