EKS Best Practice - Authentication & Authorization
Amazon EKS identity management includes two parts: Authentication and Authorization. In this article, we will discuss AWS’s best practice for cluster authentication and authorization, the reason behind this, and how ASCENDING applies it to real-life applications.
Best Practice
When it comes to identity management in Amazon Elastic Kubernetes Service (Amazon EKS), one of the best practices is to create the EKS cluster with a dedicated IAM role. This allows for better control and security over cluster access. In addition, it is recommended to use AWS IAM for cluster authentication and to create specific IAM roles for different types of users that need varying permissions on the cluster. These IAM roles can then be mapped to Kubernetes roles and rolebindings in the aws_auth config map for authorization.
Another important aspect to consider is the relationship between IAM and Kubernetes RBAC. While Amazon EKS uses IAM for authentication, it still relies on native Kubernetes RBAC for authorization. This means that IAM is only used to validate entities, while all permissions for interacting with the EKS cluster’s Kubernetes API are managed through the native Kubernetes RBAC system.
When creating an Amazon EKS cluster, the IAM entity user or role to create the cluster will be automatically granted system:masters permissions in the cluster’s RBAC configuration. This access cannot be removed and is not managed through the aws-auth ConfigMap.
ASCENDING Approach
At ASCENDING, we take this Amazon EKS best practice one step further by creating a dedicated EKS creator role with the least access necessary to create an EKS cluster. This role is only used to initially set up cluster admins and is deleted after the config map is configured. Additionally, we create IAM roles for each group of users, such as read-only and power-user access, and map these roles to k8s roles with the least privileged access. This approach ensures that our EKS clusters are secure and that access is granted only to those who need it.
We will also create IAM roles for each kind of user-group, such as read-only, and power-user access. These roles are mapped to k8s’s roles and will be created with the least privileged access.
Beyond the aws-auth ConfigMap
The aws-auth ConfigMap described above was for years the only way to map IAM identities to Kubernetes subjects, and it carries a well-known operational hazard: it is a single YAML object in kube-system, edited in place, with no validation. A malformed edit can lock every human operator out of the cluster at once, and recovery means going back to the IAM identity that created the cluster.
Amazon EKS later added a cluster access management API that addresses this directly. Instead of editing a ConfigMap, you create an access entry for an IAM principal and attach an access policy to it. AWS publishes a set of managed policies — cluster admin, admin, edit, and view — that map onto the permission levels most teams were previously hand-rolling in RBAC. Because access entries are first-class API objects, they can be created with CloudFormation or Terraform, audited in CloudTrail, and removed without touching cluster state.
A cluster’s authenticationMode decides which mechanism is live. CONFIG_MAP preserves the original behaviour, API uses access entries exclusively, and API_AND_CONFIG_MAP honours both — which is what makes a gradual migration possible. Move one group at a time, confirm access, then narrow the mode. Note that the transition is one-directional: you can move toward API, not back.
The cluster creator’s implicit system:masters grant behaves differently here too. With access entries, that bootstrap admin permission becomes an explicit flag set at cluster creation rather than an invisible property of whichever principal happened to run the create call.
Give Pods Their Own AWS Identity
Everything above governs who can talk to the Kubernetes API. A separate question — what AWS permissions the workloads themselves hold — is answered by different machinery, and conflating the two is a common source of over-permissioned clusters.
The pattern to avoid is attaching application permissions to the node’s instance profile. Every Pod on that node inherits them, including Pods that have no business touching the resource, and the blast radius of a compromised container becomes the union of everything any workload on the node needs.
IAM Roles for Service Accounts (IRSA) fixes this by registering the cluster’s OIDC provider with IAM and letting a Kubernetes service account assume a specific role. Permissions follow the workload rather than the host. EKS Pod Identity is a later approach to the same problem that drops the OIDC provider setup in favour of an EKS-managed agent, which makes it easier to reuse a role across clusters. Either is a substantial improvement over node-level credentials.
Make Access Reviewable
Least-privilege configuration decays unless someone can see it. Two things make that practical.
Turn on the EKS control plane audit log. It records every request reaching the Kubernetes API server, including the identity behind it, and it is the only way to answer “who deleted that deployment” after the fact. Ship it to CloudWatch Logs and set a retention period deliberately — the default keeps data forever and the bill follows.
Then read your effective permissions rather than your intended ones. kubectl auth can-i --list --as=<subject> reports what a subject can actually do, resolving the full chain of roles and bindings. Run it against each mapped role after a change; it routinely surfaces a ClusterRoleBinding that grants more than the reviewer assumed.
