Hi People!

Hope you're happy managing your EKS clusters. There is this one thing we all do in our EKS related shenanigans - To provide an IAM entity access to your EKS Cluster. I personally find this annoying as I have to go and manually edit a ConfigMap called aws-auth

from the official docs:

One more thing is that whoever IAM entity (User or Role) creates the EKS cluster, automatically becomes the owner of that EKS Cluster. In some cases, we don't really want that, because it may become hard to track sometimes who created the cluster as this is not visible in any configuration in AWS.

In Dec 2023, AWS announced, new feature in Elastic Kubernetes Service (EKS), which helps cluster administrators to simplify mapping and configuration of AWS Identity and Access Management (IAM) users and roles with Kubernetes clusters.

But let's understand this deprecated approach first

What is aws-auth ConfigMap

This ConfigMap resides in the kube-system namespace and controls the access of IAM principals who are allowed to access the cluster.

Internally it uses AWS IAM Authenticator in Control plane which reads it's configuration from this aws-auth ConfigMap.

This ConfigMap looks something like below :

Limitations of aws-auth ConfigMap

This feature comes with a burden to manage complex ConfigMap for every IAM Principal. You may end up messing up this ConfigMap and hence, losing access to your cluster 🤷‍♂️

Also, It does not come with IAM audit logging.

What is EKS IAM Access Entry

This is a new set of APIs, which added another yet native way to setup authentication between your Kubernetes Cluster and IAM entities.

You can setup this during or after cluster creation. Also, At the time of writing this article, we have option to use either aws-auth ConfigMap or IAM Access Entries or both.

Create IAM Access Entry in EKS

You can either configure this at the time of cluster creation or afterwards for an existing EKS cluster as well.

Let's take example when creating a fresh cluster :

1. I have created a fresh EKS Cluster, It is important to note that, In the Cluster access section you have to keep config like below:

   

^ Here you can See I have selected Disallow cluster administrator access and In Cluster authentication mode, I have selected EKS API.

It ensures that whoever (IAM User or Role) creating this cluster does not get the admin/owner access by default. And when you select EKS API only in the cluster auth mode, you are opting here to utilize IAM Access Entries rather than aws-auth ConfigMap.

2. Once Cluster creation is done, try creating your first IAM access entry as show below.

3. We see a screen with bunch of inputs. Let's try to understand it :

   

   1. IAM Principal - select the IAM entity for which you want to grant access. (similar to mapUsers and mapRoles from aws-auth ConfigMap) In our case, we have selected an IAM user - test-user

   2. Type (optional) - as we are creating this for our test IAM user, we can keep this as Standard , Other Options are : EC2 Linux, EC2 Windows and FARGATE_LINUX
      note from the docs - If you create an access entry with typeEC2 LinuxorEC2 Windows, the IAM principal creating the access entry must have theiam:PassRolepermission.

   3. Username (optional) - username to be used while authenticating with K8s APIs.

   4. Groups (optional) - You can mention any group if you are using one in RoleBinding or ClusterRoleBinding subjects. I was wondering how to bind a user, and in this documentation, I found out (It does not apply to EKS but just in case) :

      

      also, FYI

      You don't need to create an access entry for an IAM role used by a managed node group or a Fargate profile. Amazon EKS automatically adds entries for these roles to the aws-auth ConfigMap, regardless of your cluster's platform version.

      For more info on these inputs, check the table below from AWS Docs.

      

4. Choose Access Policy. This will define your access level in your EKS Cluster.

   

   Here, you can select some of the pre-defined access policies.

   1. AmazonEKSAdminPolicy

   2. AmazonEKSClusterAdminPolicy

   3. AmazonEKSAdminViewPolicy

   4. AmazonEKSEditPolicy

   5. AmazonEKSViewPolicy

   6. AmazonEMRJobPolicy

Either you can grant the access using policies at cluster level or you can bind a namespace rather than whole cluster for more fine-grained controls. (as shown below)

Select your policy and choose scope and then you have to click on Add Policy to add all the policies one by one. (shown below)

5. Coming back to our example, For our test-user I am selecting AmazonEKSAdminPolicy policy.

6. To test this, I logged in as test-user in AWS CLI.

   

7. Also I downloaded the kubeconfig using following command.

    aws eks update-kubeconfig --name kratik-testing-iam-access-entries --alias kratik-testing-iam-access-entries
   

8. Before creating the IAM access Entry, I used to see this.

9. After creating the IAM Access Entry (as we did in Step #5)

woohoo! we were able to delegate IAM permissions to our test-user using IAM Access Entry.

Advantages

1. Visibility in Console about the access about the IAM Principals having the access.

2. Saves you from messing up the EKS Access by not managing complex entries in AWS ConfigMap.

and anyways, as aws-auth is deprecated you should migrate to EKS IAM Access Entries.

---

Thank you for reading this article 🌻

Let me know if you have any feedback or suggestions.

Peace out!

References

1. https://aws.github.io/aws-eks-best-practices/security/docs/iam/

2. https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html

3. https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html

4. https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html

5. https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html

6. https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html