How do you manage access to EKS clusters across L1/L2/Dev/Admin levels, and how do IAM and RBAC connect?

Think of a hospital with badge-based access. Your employee badge (IAM identity) gets you through the front door (authentication), but which rooms you can enter depends on your department and clearance level (RBAC authorization). A nurse can access patient rooms but not the pharmacy vault. A doctor can access both. The badge system and the room access system are separate but connected.

In EKS, authentication and authorization are separate layers. Authentication answers 'who are you?' using AWS IAM — users, roles, or SSO identities present AWS credentials to the EKS API server. Authorization answers 'what can you do?' using Kubernetes RBAC — Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings define permissions. The bridge between them is the EKS access entry system (or the legacy aws-auth ConfigMap) which maps IAM principals to Kubernetes usernames and groups.

The implementation involves three steps. First, create IAM roles for each access level: eks-l1-readonly, eks-l2-support, eks-developer, eks-admin. Second, map each IAM role to a Kubernetes group using EKS access entries (preferred) or the aws-auth ConfigMap. Third, create Kubernetes ClusterRoles and RoleBindings that grant appropriate permissions to each group. L1 support gets a ClusterRoleBinding to the built-in view ClusterRole (read-only across all namespaces). L2 support gets RoleBindings to the edit ClusterRole in specific namespaces. Developers get custom Roles with deploy permissions (create/update Deployments, Services, ConfigMaps) in their team namespaces. Admins get ClusterRoleBinding to cluster-admin.

At production scale, teams integrate EKS with AWS SSO (IAM Identity Center) so users authenticate through their corporate identity provider. Permission sets in AWS SSO map to IAM roles, which map to Kubernetes groups. This creates a chain: corporate identity → SSO permission set → IAM role → Kubernetes group → RBAC permissions. Monitoring should include audit logs for who accessed what, periodic access reviews, and alerts on cluster-admin usage.

The non-obvious gotcha is that the aws-auth ConfigMap is a single point of failure. If someone deletes or corrupts it, all IAM-based access to the cluster is lost (except the cluster creator's IAM principal). EKS access entries, the newer mechanism, are managed through the EKS API and are more resilient. Teams should also be aware that IAM permissions and Kubernetes RBAC are evaluated independently — having IAM access to the EKS API does not automatically grant Kubernetes permissions, and vice versa.