Enabling IAM users/roles Access on Amazon EKS cluster

It’s only been few years since AWS launched its own fully managed Kubernetes service EKS which has gotten popular as it offers a lot of benefits, especially not having to worry about managing your control plane but mostly focus on the application workloads running on the cluster. My experience of using EKS has been mostly pleasant but at times confusing when it came to managing access related things on EKS as the process of providing access to IAM/federated users is somewhat different compared to the Kubernetes. So I decided to go through all those extensive AWS documents and help fellow engineers who are struggling like me at one point at providing or getting access.

Photo by Ihor Dvoretskyi on Unsplash

Note: This article is only about providing access to EKS to IAM users/roles and does not cover any other features of EKS and Kubernetes in depth. Also recommended that you already have access to the cluster either as a cluster creator or administrative access. It is also assumed that the reader has administrator/superuser access to the AWS account to perform IAM operations.

Prerequisites:

1. EKS cluster ready
2. kubectl, eksctl, aws-cli installed on Local Machine

When you create an EKS cluster, the IAM user/role that creates the cluster is automatically granted access to the system:masters Group(cluster admin) in the EKS cluster’s RBAC configuration. For the AWS user’s to interact with the cluster, you need to edit the aws-auth ConfigMap, and create the roles/clusterroles and rolebindings/clusterrolebindings with the group that you will specify in the aws-auth.

1. Using MapRoles

First create an IAM Role which will be used for accessing the cluster. In this example, I have created a role named KubeAdmin. Make sure this role has sufficient permissions related to cluster. I have allowed read-only access here.

KubeAdmin IAM Role

Permissions of KubeAdmin Role

Make sure that you are adding the trust relationship to this role for the account to AssumeRole.

Once the role is created, create IAM user/group which will be provided access, with policy allowing AssumeRole on the KubeAdmin Role.

Users in my group test-users

IAM policy attached to test-users group

Now that we have the IAM users with group and Role ready, all that is needed to be done is to add this role in the aws-auth ConfigMap. Since you are the cluster creator, you can edit the aws-auth using command:
kubectl -n kube-system edit configmap aws-auth
and then add the role as per below screenshot:

aws-auth configuration

Add the arn of the KubeAdmin Role under the mapRoles section with group system:masters (for full EKS cluster access with all privileges). Now that the access is granted, let’s test this.
Using aws cli, call the assumed role as follows:

aws sts assume-role --role-arn arn:aws:iam::<aws_account_id>:role/KubeAdmin --role-session-name KubeAdmin --profile test1.test1

In the Above command, I am calling KubeAdmin Role to be assumed by the user test1.test1 from the group test-users. This will generate the temporary credentials which are to be configured in the AWS credentials file.

Add these credentials to the AWS credentials file. I have added these credentials under new profile name called ‘assumedrole’

aws credentials file found under the .aws folder in your local machine

Update your Kube context using below command:

aws eks update-kubeconfig --name <cluster-name> --profile <profile-name> --region <region-name>

You can verify the current context using kubectl config view --minify

check current context

Note: Every time the session is expired, you need to regenerate the token using the aws sts assume-role command and update the values in the aws credentials file with the new token and keys. Also, need to update the kube-context as well using previous command.

2. Using MapUsers

This is another way of providing access directly to the IAM users instead of AssumedRoles. This is relatively easy but also a bit cluttered and not usually an organized practice, as the number of users increases, it will also add more lines to the aws-auth ConfigMap making it more messy. Also, using AssumedRole is much more secure way of communicating with the cluster than directly using the IAM user, as the temporary credentials give you access to the cluster only for a limited time until you regenerate the token.

For this, you just need to add the arn of the IAM user under the mapUser Section of the ConfigMap and the User gets the access to the cluster.

aws-auth ConfigMap for Mapping Users

Here you can see that the user ‘radmin’ has the cluster admin access whereas the users test1.test1 and test2.test2 have limited access. Groups eks-console-dashboard-full-access-group and eks-console-dashboard-restricted-access-group were created in order to give access to the complete or restricted access to the EKS dashboard on AWS EKS Console to view the workloads and nodes, using the AWS manifests using below commands.

For Full access to the dashboard:

curl -o eks-console-full-access.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-full-access.yaml

For access to the specific namespace:

curl -o eks-console-restricted-access.yaml https://amazon-eks.s3.us-west-2.amazonaws.com/docs/eks-console-restricted-access.yaml

You will have to update the namespace in the manifest in above link if you want to give access to specific namespace other than the default one.

Once you download and update the manifests appropriately, you can apply the changes using:

kubectl apply -f eks-console-full-access.yaml
kubectl apply -f eks-console-restricted-access.yaml

After this add the groups to the MapUsers section along with the appropriate user to whom you want to give the access as shown in previous screenshot. The manifest eks-console-full-access.yaml creates clusterrole and clusterrolebinding whereas the eks-console-restricted-access.yaml manifest creates role and rolebinding as the scope is namespace-wise.

References:

Enabling IAM user and role access to your cluster

Using RBAC Authorization

AssumeRole

This is my very first technical article on Medium, ergo please drop your feedback on how this article can be improved and do let me know if this was helpful to you readers. My objective was for readers to get a comprehensive understanding on not only the Access to the cluster but also manage IAM operations required in order to do so, along with examples. Until next time!