# EKS IAM Access Entries -
End of aws-auth ConfigMap!

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`

![Steve Harvey Judge GIF by ABC Network](https://media2.giphy.com/media/v1.Y2lkPTc5MGI3NjExbTE0ZzkxYmNlMmUzeW5vaXdrc3JsOTJuOHNmbW54NWphNDg0ZmRldiZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/wPqYQ87iJKVJzyK7QW/giphy.gif align="center")

from the [official docs](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html):

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1723260495809/061675d3-a54c-4c68-ab9d-861f899de738.png align="center")

![homer simpson episode 10 GIF](https://media3.giphy.com/media/v1.Y2lkPTc5MGI3NjExeGFna3pjZGIyOG9lN3dsbjI2MmU2a2F4MXFsZGFyYmtuYjltMGhtdiZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/3orif0P7UxBkXQJBuM/giphy.gif align="center")

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](https://aws.amazon.com/about-aws/whats-new/2023/12/amazon-eks-controls-iam-cluster-access-management/), 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](https://github.com/kubernetes-sigs/aws-iam-authenticator#readme) in Control plane which reads it's configuration from this aws-auth ConfigMap.

This ConfigMap looks something like below :

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722766299781/99258df7-efe3-4c70-b2e9-0ec9a21782d6.png align="center")

# 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:
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722913981760/75540996-251a-4008-bd81-e03120d0759d.png align="center")
    

^ 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.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722773200895/090abf80-d2d0-417f-9c5c-13389a694fcc.png align="center")

3. We see a screen with bunch of inputs. Let's try to understand it :
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722779752985/e0554838-388d-4586-93e4-b04a069aa616.png align="center")
    
    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 type*`EC2 Linux`*or*`EC2 Windows`*, the IAM principal creating the access entry must have the*`iam:PassRole`*permission.*
        
    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](https://kubernetes-tutorial.schoolofdevops.com/configuring_authentication_and_authorization/), I found out (It does not apply to EKS but just in case) :
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722916061466/482879cd-a53f-4797-9cbf-0861826ffeeb.png align="center")
        
        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.
        
        ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722915123769/c8f053f4-62f3-47e7-8333-1f7cc26aa021.png align="center")
        
4. Choose **Access Policy.** This will define your access level in your EKS Cluster.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722779821525/cbb81c67-17ca-4e7d-91f2-e1f27c591dc9.png align="center")
    
    Here, you can select some of the pre-defined access policies.
    
    1. AmazonEKSAdminPolicy
        
    2. AmazonEKSClusterAdminPolicy
        
    3. AmazonEKSAdminViewPolicy
        
    4. AmazonEKSEditPolicy
        
    5. AmazonEKSViewPolicy
        
    6. AmazonEMRJobPolicy
        

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722779842551/dd9bf428-17d6-4a78-9a43-2a0dce50f03a.png align="center")

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)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722779929479/778ec8c7-690a-4ded-baf7-e7b73a672594.png align="center")

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)

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722780115058/c7ca531c-3732-49fd-9ffc-f0fb08baddfb.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722788724088/b5590437-b703-4fbe-8098-317877980aef.png align="center")

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722792356103/850ad912-7ffc-434c-a0aa-f5d60035b84c.png align="center")

6. To test this, I logged in as `test-user` in AWS CLI.
    
    ![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722793663188/a534e52e-10e8-46d0-a45a-6ee9b97faf24.png align="center")
    
7. Also I downloaded the **kubeconfig** using following command.
    
    ```bash
    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.
    

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722793186396/c19cb084-bd68-43b0-8ea0-49fd99fbc08e.png align="center")

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

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1722793200707/0f06f73f-4732-40a2-8a86-e8745380b2ae.png align="center")

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

![The Office gif. Actor Steve Carell as Michael in The Office hangs his mouth open in happy shock and is blown back by surprise. ](https://media4.giphy.com/media/v1.Y2lkPTc5MGI3NjExMmxuamk4YTJueTdmZThycDBuZGNyeGU2b3dzd3BrOXJqdDd5dmRrMSZlcD12MV9pbnRlcm5hbF9naWZfYnlfaWQmY3Q9Zw/tkApIfibjeWt1ufWwj/giphy.gif align="center")

# 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/](https://aws.github.io/aws-eks-best-practices/security/docs/iam/)
    
2. [https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html](https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html)
    
3. [https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html](https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html)
    
4. [https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html](https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html)
    
5. [https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html](https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html)
    
6. [https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html](https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html)