Previously Providing access to an EKS cluster or specific application-based access can be a complex process. Kubernetes leverages Role-Based Access Control (RBAC) to manage these permissions, allowing cluster administrators to assign access based on user roles within the organization. EKS integrates RBAC with AWS IAM roles, which makes it highly effective for handling authorization.

Consider this scenario: different teams may require various levels of access to the cluster—like the monitoring team needing access to the monitoring namespace, or the development team requiring read-only access to the dev namespace. In such cases, the administrator defines these permissions using RBAC, mapping AWS IAM identities to Kubernetes roles. This mapping is achieved through a ConfigMap called aws-auth, located in the kube-system namespace, where AWS roles are linked to Kubernetes users and groups.

This combination of RBAC and AWS IAM provides a flexible, scalable, but a complex process to manage fine-grained access control in EKS clusters, simplifying how permissions are handled for multiple teams with distinct access needs.

Historically, cluster creation was handled via Amazon EKS APIs, but administrators had to switch to the Kubernetes API to define mappings between AWS IAM users and their Kubernetes permissions. This approach introduced complexity, making the process of granting access to EKS clusters cumbersome and leaving “shadow administrator” (root-level) permissions with the principal who created the cluster.

In December 2023, AWS launched a new feature called EKS Cluster Access Management. This simplifies the process of granting and managing access within EKS clusters. Instead of relying on the aws-auth ConfigMap, access can now be managed through the AWS API directly. This new feature is supported in EKS versions starting from v1.23.

What is Shadow administrator: In Amazon EKS, the user who initially creates the cluster is automatically granted administrative privileges, although this access isn't explicitly visible in the usual permission settings. This user, often referred to as a "shadow administrator," has full control over the cluster by default. EKS Cluster Access Management introduces a solution for identifying and managing these shadow administrators, making their presence visible within the IAM access entries on the cluster’s access management page. This feature allows administrators to audit, modify, or revoke these hidden privileges, enhancing transparency and control over cluster access.

two key concepts—'access entries' and 'access policies'—form the foundation for managing permissions

Access Entries: When you grant access to an AWS principal (such as a user or service), you create an access entry specific to that principal. This entry serves as a gateway for assigning permissions through Kubernetes groups or by linking it to access policies. The access entry centralizes control over what an AWS principal can do within the EKS cluster.

Access Policies: These are EKS-specific policies designed to control Kubernetes permissions for access entries. Unlike AWS IAM policies, they are defined within Amazon EKS and offer flexibility in how permissions are granted. You can apply an access policy either at the cluster level (similar to a Kubernetes ClusterRole) or the namespace level (analogous to a Role). Each policy defines a set of Kubernetes permissions curated by AWS, simplifying the assignment of access rights.

Kubernetes access management in Amazon EKS is governed by a cluster-wide setting known as the authentication mode. In EKS, there are three distinct authentication modes that determine how access permissions are managed:

API_AND_CONFIG_MAP: Both the aws-auth ConfigMap and Access Entries are considered in this mode. However, if an AWS principal is defined in both the ConfigMap and an Access Entry, the Access Entry takes precedence, and the permissions granted in the ConfigMap are ignored. This mode provides a hybrid approach, combining traditional ConfigMap-based access with Access Entries for more flexibility. By default, API_AND_CONFIG_MAP is selected for clusters using the latest versions of EKS, offering an optimal balance of control and convenience.

CONFIG_MAP: In this mode, the control plane solely relies on the aws-auth ConfigMap to manage access. No Access Entries can be created within the cluster, and all permissions must be explicitly defined in the ConfigMap.

API: This mode bypasses the aws-auth ConfigMap entirely, relying exclusively on Access Entries to manage permissions. This is ideal for organizations looking to centralize access control directly within the EKS environment.

CLI Commands for Managing AWS EKS Access

To ensure compatibility with AWS EKS commands, make sure you're using the latest version of the AWS CLI. Some commands may not work with older versions.

Modify the Authentication Mode:
aws eks update-cluster-config --name <CLUSTER_NAME> --access-config authenticationMode=API

List Access Policies:
aws eks list-access-policies

List Access Entries in Your Cluster:
aws eks list-access-entries --cluster-name <cluster-name>

Create an Access Entry for an IAM User:
aws eks create-access-entry --cluster-name demo-cluster \
--principal-arn arn:aws:iam::${ACCOUNT_ID}:user/cluster-admin

Associate AmazonEKSClusterAdminPolicy to the Access Entry:
aws eks associate-access-policy --cluster-name demo-cluster \
--principal-arn arn:aws:iam::${ACCOUNT_ID}:user/cluster-admin \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
--access-scope type=cluster

When creating access entries in Amazon EKS, you have several options tailored to different types of IAM principals:

STANDARD: This is the default type, used for IAM users and roles. You can also utilize Kubernetes RBAC authorization with STANDARD access entries, allowing you to assign one or more Kubernetes group names to the entry.

EC2 Linux, EC2 Windows, and FARGATE_LINUX: These types are specific to different compute environments.

However, there are important considerations to keep in mind:

Service Linked Roles: Access entries cannot be created for service-linked roles.

Unique IAM Principal: Each access entry must include the Amazon Resource Name (ARN) of a single, unique IAM principal. An IAM principal cannot be associated with more than one access entry.

Immutability: Once an access entry is created, you cannot change its IAM principal or type.

Deletion of IAM Principals: If an IAM principal is deleted, the associated access entry will not be automatically removed. You must manually delete the access entry.

Understanding these constraints ensures effective management of access entries and helps maintain a secure and organized cluster environment.

Switching authentication modes

on an existing EKS cluster is a one-way operation, with specific pathways for transition:

CONFIG_MAP to API_AND_CONFIG_MAP: You can move from the CONFIG_MAP mode to API_AND_CONFIG_MAP, which allows for a combined approach using both the aws-auth ConfigMap and Access Entries.

API_AND_CONFIG_MAP to API: You can also transition from API_AND_CONFIG_MAP to API, which focuses solely on Access Entries and ignores the aws-auth ConfigMap.

However, once you make these transitions, reverting to a previous mode is not permitted:

API to CONFIG_MAP or API_AND_CONFIG_MAP: You cannot switch back to CONFIG_MAP or API_AND_CONFIG_MAP after moving to API.

API_AND_CONFIG_MAP to CONFIG_MAP: Similarly, once you have transitioned from CONFIG_MAP to API_AND_CONFIG_MAP, reverting directly to CONFIG_MAP is not allowed.

This one-way nature of authentication mode changes ensures that once a new access management approach is adopted, it cannot be reversed, allowing for a consistent and predictable security posture.

Note

Access entries and access policies take precedence over configurations in the aws-auth ConfigMap. For example, if a user has read-only access assigned in the aws-auth ConfigMap but has been granted ClusterAdmin access via the AWS API, the user will be granted ClusterAdmin privileges.