New EKS Access Controls in 2024

Hey guys, thanks for taking the time to read the following blog post. I hope it will benefit you in your Kubernetes learning path and help you create a positive impact in your organization.

Let's get into it…

The kubeAPI is responsible for managing access and authorization to the Kubernetes cluster. In EKS, up until December 2023, access to the cluster was controlled solely through the aws-auth configMap. In December, AWS introduced a native authentication and authorization mechanism called cluster access management, intended to supersede the aws-auth configMap.

Amazon EKS cluster access management is based on two new concepts: access entries and access policies. Both are tightly integrated with IAM, which will be discussed in more detail later in the post.

Cluster access management allows administrators to leverage IAM features such as logging, auditing, and multi-factor authentication. The key benefit we saw was in new EKS clusters, as there was no need to switch between AWS and kubectl commands when managing access and authentication to the cluster.

In the post, we will cover the following:

Enable EKS cluster access management
Concepts

Enable EKS Cluster Access Management

We need to upgrade to a supported version and update our EKS cluster authentication mode to enable the new authentication and authorization method. The available authentication and authorization modes are as follows:

CONFIG_MAP - Access controlled by aws-auth configMap
API_AND_CONFIG_MAP - Access controlled by aws-auth configMap and cluster access management
API - Access control by cluster access management

AWS supports transitioning to cluster access management, but reverting to the previous method is not possible. This means you can switch the authentication mode from CONFIG_MAP to API_AND_CONFIG_MAP, but you cannot revert back to CONFIG_MAP. Similarly, moving from API_AND_CONFIG_MAP to API is irreversible.

In new clusters, we can enable cluster access management with the following command:

aws eks create-cluster \
   --name <CLUSTER_NAME> \
   --role-arn <CLUSTER_ROLE_ARN> \
  --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
  --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
  --access-config authenticationMode

In existing clusters, we can execute the following command:

aws eks update-cluster-config \
   --name <CLUSTER_NAME> \
   --access-config authenticationMode

Concepts

The simplified access management introduces two new concepts:

Access Entry: Determines who can access the cluster, such as an IAM user or role.
Access Policy: Defines permissions for executing kubectl commands and their scope (cluster or namespaced level).

When creating an access entry, several fields can be filled in:

IAM Principal ARN: The ARN of an IAM user or role.
Type: Each access entry has a specific type:
- EC2_LINUX: For self-managed Linux node group roles.
- EC2_WINDOWS: For self-managed Windows node group roles.
- FARGATE_LINUX: For IAM roles used with Fargate.
- STANDARD: Default type for users and roles.
Username: Applicable only to the STANDARD type, allowing you to set a username for your access entry.
Groups: Also applicable only to the STANDARD type, allowing you to set groups and create RBAC roles in Kubernetes for them.

** NOTE: Managed nodegroups dosen’t need access entry to the cluster **

Each access entry can be linked with one or more pre-defined access policies. These policies can be applied either to a specific namespace or to the entire cluster. To see the available access policies, you can use the following command:

aws eks list-access-policies --output

** NOTE: If you encounter any errors while executing the command, ensure that you are using the latest version of the AWS CLI.

AmazonEKSClusterAdminPolicy: Cluster admin
AmazonEKSAdminPolicy: Namespace level admin
AmazonEKSEditPolicy: Editor
AmazonEKSViewPolicy: Viewer

To conclude,

Amazon EKS cluster access management is now the preferred way to manage AWS IAM principal access to Amazon EKS clusters, allowing continued use of AWS IAM principals as Amazon EKS access entries and applying Kubernetes permissions with cluster access policies.

It provides a cleaner integration with AWS IAM for authentication, with separate authorization permissions modeled after Kubernetes. Additionally, it enables Amazon EKS administrators to manage cluster access using the Amazon EKS API, streamlining automated DevSecOps processes.