I'm trying to understand how EKS Access Entries interact with native Kubernetes RBAC. Suppose an IAM role such as `dev-pod-reader` is registered with an EKS Access Entry and mapped to a Kubernetes group called `dev-readers`. That group is then referenced by a `RoleBinding` or `ClusterRoleBinding`.
If the Access Entry also has an EKS access policy such as `AmazonEKSViewPolicy`, are the permissions from the EKS policy and Kubernetes RBAC combined? In other words, does the role receive the union of whatever either authorization system grants?
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 RoleBindings? Or do they generally choose either EKS access policies or Kubernetes RBAC instead of mixing both?
What is a maintainable way to centralize access without creating thousands of manually managed Access Entries and RoleBindings?
3 Answers
The important distinction is between human access to the cluster and AWS permissions needed by workloads. Use IAM roles with temporary credentials for people, and manage pod-to-AWS access separately with EKS Pod Identity or carefully scoped IRSA where required. Keeping those two concerns separate makes the access model easier to audit and prevents developer cluster permissions from being confused with application permissions.
Yes, access is generally additive: if an identity is authorized by either the EKS access policy path or Kubernetes RBAC, the request can be allowed. That means combining an EKS access policy with group-based RoleBindings can grant the union of both sets of permissions, so overlapping or overly broad bindings need to be reviewed carefully. For large environments, short-lived IAM roles are preferred over long-lived IAM user credentials, and IAM Identity Center combined with the EKS Cluster Access Management API is a common foundation for centrally managing access across many clusters.
At larger scale, teams usually standardize a small set of access roles and groups rather than creating one Access Entry per person. Identity Center groups can map to roles, and those roles can be assigned consistently across clusters. Kubernetes RBAC then handles finer namespace or resource-level permissions, with the bindings managed declaratively through GitOps. For more advanced policy requirements, an admission or policy engine such as Kyverno can complement the basic EKS and RBAC model.
A practical model is to use IAM Identity Center groups for coarse cluster access, map those groups to reusable Kubernetes groups through Access Entries, and keep namespace-specific permissions in Git-managed RoleBindings. That avoids creating a separate policy design for every individual developer.