Map IAM Users and Roles to EKS RBAC Permissions (2026)

AWS IAM users and roles can be mapped to Kubernetes RBAC permissions by configuring the aws-auth ConfigMap in your EKS cluster.

Here’s how you can map IAM users and roles to EKS RBAC permissions, allowing you to control access to your Kubernetes cluster using AWS IAM identities.

Let’s see this in action with a typical aws-auth ConfigMap configuration. Imagine you have an EKS cluster and you want to grant your developers IAM group edit access to all namespaces, and a specific IAM user, jane.doe@example.com, admin access to the kube-system namespace.

apiVersion: v1
kind: ConfigMap
metadata:
  name: aws-auth
  namespace: kube-system
data:
  mapRoles: |
    - rolearn: arn:aws:iam::111122223333:role/eks-cluster-admins
      username: cluster-admin
      groups:
        - system:masters
    - rolearn: arn:aws:iam::111122223333:role/kubernetes-read-only
      username: read-only-user
      groups:
        - viewers
  mapUsers: |
    - userarn: arn:aws:iam::111122223333:user/jane.doe@example.com
      username: jane.doe
      groups:
        - admins
    - userarn: arn:aws:iam::111122223333:user/developer.team@example.com
      username: developer.team
      groups:
        - developers

This ConfigMap is the central piece of how EKS integrates with IAM for authentication and authorization. When a user or service attempts to interact with the Kubernetes API server, EKS uses the aws-auth ConfigMap to determine if the incoming IAM identity is authorized.

The core problem this solves is bridging the gap between AWS’s identity management (IAM) and Kubernetes’s authorization model (RBAC). Without this mapping, you’d have to manage Kubernetes Users and Groups separately, which is cumbersome and duplicates effort. By leveraging IAM, you can use your existing AWS security practices to govern access to your EKS cluster.

Internally, the Kubernetes API server in EKS consults the aws-auth ConfigMap for every request. It checks if the authenticated IAM principal (user or role) matches any entries in mapUsers or mapRoles. If a match is found, the specified username and groups are assigned to that request. These Kubernetes-native users and groups are then used by Kubernetes RBAC (Role-Based Access Control) policies to grant or deny permissions.

Let’s break down the key components:

• mapRoles: This section maps IAM roles to Kubernetes users and groups.
  • rolearn: The Amazon Resource Name (ARN) of the IAM role.
  • username: The Kubernetes username that will be associated with this role.
  • groups: A list of Kubernetes groups that the user will be a member of. This is crucial for RBAC.
• mapUsers: This section maps IAM users to Kubernetes users and groups.
  • userarn: The ARN of the IAM user.
  • username: The Kubernetes username.
  • groups: The Kubernetes groups the user belongs to.

Once these mappings are in place, you define Kubernetes Roles or ClusterRoles and RoleBindings or ClusterRoleBindings to grant specific permissions to these Kubernetes groups. For example, to give the developers group edit access to all namespaces, you would create a ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: developers-edit-all-namespaces
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit # A built-in ClusterRole that grants edit access
subjects:
- kind: Group
  name: developers # This group name comes from the aws-auth ConfigMap
  apiGroup: rbac.authorization.k8s.io

And to give jane.doe (mapped to the admins group) admin access to kube-system:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: jane-doe-kube-system-admin
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin # A built-in ClusterRole that grants admin access
subjects:
- kind: User
  name: jane.doe # This username comes from the aws-auth ConfigMap
  apiGroup: rbac.authorization.k8s.io

The most surprising thing about this mechanism is that the aws-auth ConfigMap isn’t just about mapping; it’s also the only place where you can define the initial cluster administrators. If you forget to map at least one user or role to the system:masters group, you can lock yourself out of your cluster. The system:masters group is a special Kubernetes group that is granted full administrative privileges by default, and the aws-auth ConfigMap is how you associate IAM principals with that powerful group.

After successfully configuring your aws-auth ConfigMap and corresponding RBAC roles, the next challenge is often managing dynamic group memberships or implementing more granular access control for specific application resources.