Managing EKS authentication with IAM groups and assigning a RBAC to the group

As a DevOps engineer, you’re likely tasked with managing access to a Kubernetes cluster. Your goal is to ensure that each user has the appropriate permissions they need to do their work without granting unnecessary access that could lead to potential security risks. You want to achieve this in a scalable and manageable way, especially if you’re working with a large team or a rapidly growing organization.

In my own experience managing access to Kubernetes clusters, I encountered a significant challenge: while you can manage users or roles through aws-auth in Kubernetes, it’s not possible to manage groups. This limitation can make it difficult to manage access at scale, as you have to manually manage each user’s permissions.

In this article, we’ll discuss how to overcome this challenge by managing Kubernetes Role-Based Access Control (RBAC) with AWS Identity and Access Management (IAM).

By using a combination of IAM and RBAC, we can manage access at the group level, making it easier to manage permissions for a large number of users. This approach has several benefits:

• Granular Access Control: Using both IAM and RBAC, you can control access at a granular level, ensuring that users have the exact permissions they need and nothing more. This principle of least privilege enhances the security of your cluster.
• Scalability: This approach is highly scalable. As your team grows, you can easily add new users to the IAM group, and they will automatically have the necessary access to the Kubernetes cluster.
• Ease of Management: Managing access through IAM groups rather than individual users simplifies administration. You can easily modify permissions by changing the role, and the changes will apply to all users in the group.

However, it’s important to note that this process requires full access to the Kubernetes cluster. You need to be able to create and modify roles and role bindings in the cluster, which typically requires admin privileges. Always ensure you follow best practices for managing access to your cluster to maintain its security and integrity.

In the following sections, we’ll walk through each step of the process in detail, providing a practical solution to the challenge of managing group-level access in a Kubernetes cluster.

Prerequisites:

Before you begin, make sure you have the following:

1. An AWS account with administrative access.
2. A Kubernetes cluster is configured and running.
3. The AWS CLI is installed and configured on your computer.
4. eksctl command line tool installed on your computer.
5. Full access to the Kubernetes cluster: You need to be able to create and modify roles and role relationships in the cluster, which usually requires administrator privileges.

Step 1: Create a Group

First, we need to create a group that represents the users we want to give access to. For this example, let’s create a group called EKS-RnD.

Step 2: Create a Role

We create a role that gives only trusted entities. For this example, let’s name the role RnD-Role. The role doesn’t need permission for anything in AWS, all the settings are going to be inside the cluster. What do you need? Define who can consume it.

Here’s an example of the trust policy of the role:

Step 3: Create two policies that you will grant to the group

• A policy that gives access to run commands on AWS CLI for EKS.

• A policy that gives access to assume the role that we created.

This means anyone who joins this group can get permission to run as the role.

Step 4: Update the aws-auth

Now, we need to update the aws-auth:

eksctl create iamidentitymapping —-cluster <cluster-name> -—arn <RnD-Role-arn> —-group <EKS-RnD> —-username <RnD>

This command adds the mapRoles, which says that anyone identifying with the role we created in AWS will receive the identity of the group EKS-RnD.

Step 5: Create Role and Binding

Finally, the last step is to create the role and binding in the Kubernetes cluster. This will allow the users in the EKS-RnD group to perform specific actions in the cluster.

Step 6: Update the Kubeconfig

To run the kubeconfig as the role, we simply run the following command:

aws eks update-kubeconfig —-region <region> --name <cluster-name> --role-arn <role-arn>

This command will update the config to run with the role that we created. We will get an error if we don’t have access to this role.

Conclusion: Streamlining access management in Kubernetes

This article explored a method to manage group-level access to a Kubernetes cluster using AWS IAM and Kubernetes RBAC. This approach allows us to manage access at a granular level, ensuring that users have the exact permissions they need and nothing more. It’s also scalable and simplifies administration by managing access through IAM groups rather than individual users.

By overcoming the limitation of group management using aws-auth, we have provided a practical solution to the challenge of group-level access management in a Kubernetes cluster. This approach improves the security of your cluster and makes it easier to manage permissions for many users.

Remember, the key to effective access management is understanding the needs of your users. This involves knowing the tasks they need to perform and the resources they need to access to do their jobs effectively. It’s about striking a balance between providing them with the necessary permissions to perform their tasks, without granting unnecessary access that could lead to potential security risks.

For example, a developer might need access to deploy applications to certain namespaces, but they don’t need access to the entire cluster. On the other hand, a cluster administrator might need broader permissions to manage the cluster’s resources. By understanding these needs, you can assign the appropriate roles and permissions to each user or group, enhancing the security and efficiency of your Kubernetes cluster.

As your team grows and evolves, continue to review and update your access management strategies to ensure they meet your organization’s needs. Drawing from personal experience, I can attest to the effectiveness of this approach in managing group-level access in a Kubernetes cluster, and I hope this guide proves useful in your own access management endeavors.