How to give limited access of your EKS cluster to users through RBAC
This blog post outlines a process for implementing Role-Based Access Control (RBAC) to manage user and group permissions within EKS Kubernetes clusters. If you’re tasked with overseeing EKS Kubernetes clusters, it’s crucial to provide access to others without risking errors or unauthorized access to sensitive areas. This is where RBAC plays a pivotal role.
A scenario we often encounter is the need for developers to swiftly access logs or obtain information about pods and services directly from the cluster, especially during major incidents. RBAC efficiently enables developers to quickly gather the necessary information with minimal risk.
In this guide, we’ll assume you’re working with two AWS Accounts. The first, referred to as the iam_account, is where the IAM users are set up. The second, the workload_account, contains the EKS cluster and its dependencies (such as VPC, EC2 instances, Application Load Balancers, and roles).
Prerequisites :
To actively follow along with this blog and apply the steps in a hands-on manner, you will need to meet the following requirements:
- Two AWS accounts to set up the necessary infrastructure and permissions.
- A running EKS (Elastic Kubernetes Service) cluster within one of your AWS accounts, which will be the environment you’ll manage access to.
- Terraform installed on your local machine, which will be used for automating the deployment and management of your AWS resources.
- The
kubectlcommand-line tool, enabling you to interact directly with your EKS cluster and manage Kubernetes resources.
These prerequisites are essential for setting up a secure and functional environment where you can effectively implement RBAC to control access to your Kubernetes cluster.
So let’s go
Step 1 — Create User, Group, and policy in iam_account
In the iam_account, we set up a structured approach to manage access and permissions. Here's how it's done:
Create User in iam_account
Create Users and Groups: Begin by creating IAM (Identity and Access Management) users within the iam_account. These users are the individuals who will need access to the Kubernetes cluster managed in the workload_account.
Create a Group and assign a user call developer to that group
Then Organize Users into Groups: For easier management, organize these IAM users into groups based on their roles or the level of access they require. For example, all developers can be added to a group named DevelopersGroup. This organization simplifies the management of permissions, as changes can be made at the group level rather than individually.
Enable Role Assumption and Assign Policy to Groups.
Users in the DevelopersGroup are granted the ability to assume the Dev-Cross-Account-Role. This setup allows developers to switch contexts and gain the access rights defined by the role, enabling them to interact with resources in the workload_account securely. The assumption of this role is governed by policies that ensure only authorized users can assume it, enhancing the security of cross-account resource access.
Step 2— Create IAM roles for accessing resources in workload_account
In workload_account, we create a role Dev-Cross-Account-Role that are assumed by the user located in iam_account in the group DevelopersGroup.
Define a Role for Cross-Account Access: Create a role, such as Dev-Cross-Account-Role, within the workload_account. This role is designed to grant the necessary privileges to iam_accountfor accessing resources in the workload_account. The role's permissions should be carefully scoped to ensure it provides just enough access to fulfill the users' needs without exceeding them. In the sample below only the permissions to perform actions on eks is granted
After configuring the IAM side for cross-account access, the next crucial step involves setting up the necessary permissions within Kubernetes itself. This ensures that the users, now able to assume the appropriate IAM roles, can interact with the Kubernetes cluster in a controlled and secure manner.
To carry out the following setup, you will need administrator-level access to the Kubernetes cluster. This access is essential for creating and modifying the cluster’s role-based access control (RBAC) settings.
Step 3— Create a mapping between Kubernetes Group and IAM
Creating a mapping between an IAM role and a Kubernetes group is a crucial step in integrating AWS IAM with Kubernetes RBAC, enabling users who assume specific IAM roles to access the Kubernetes cluster based on their group memberships. Here’s a step-by-step guide to achieve this integration:
Backup the Existing aws-auth ConfigMap:
Before making any changes, it's essential to back up the existing aws-auth ConfigMap. This ConfigMap contains the current mappings and permissions, and backing it up ensures you can revert to the original state if needed.
To backup the aws-auth ConfigMap, you can use the following
kubeclt get configmap/aws-auth -n kube-system -o yaml > aws-auth-backup.yaml`
After backing up, you need to edit the aws-auth ConfigMap to add the mapping between the IAM role ARN and the Kubernetes group.
You can edit the ConfigMap directly or use eksctl command as below. The command below create mapping for developper-group located inside kubernetes cluster and the IAM Role Dev-Cross-Account-Role`
Check that the Iamidentitymapping is created eksctl get iamidentitymapping --cluster $clustername --region=$region`
Step 3 — Create the RBAC Role
The role.yaml file instructs Kubernetes to establish a role named application-access within the application namespace. This role is endowed with permission to perform get, list, and watch operations on resources such as logs, pods, and services. Additionally, a second rule within this role authorizes the deletion of pods.
Step 4— Create the RBAC Role Binding
Creating an RBAC RoleBinding in Kubernetes is a critical step to assign specific permissions to users, groups, or service accounts. This assignment enables them to perform operations within the cluster as defined by a Role or ClusterRole. Below, we assign a cluster user named developer to the role application-access, which grants permissions as defined in a role.yaml from a previous step.
Step 5— User can test their access
To validate the access, the users created in iam_account can assume role Dev-Cross-Account-Role of workload_account
Then update their kubeconfig file with the command aws eks update-kubeconfig -- name $clustername`aws eks update-kubeconfig — name clustername`
And finally, validate that they are able to perform allowed actions
kubectl get pod -n application
If the configuration is correct and the user has the necessary permissions, this command will display the pods within the application namespace, confirming that access has been properly established.
I’m Hervé-Gaël KOUAMO, Founder and CTO of HK-TECH, a French tech company specializing in designing, building, and optimizing applications. Our mission is to assist businesses throughout their cloud migration journey, ensuring seamless transitions and maximizing their digital potential. You can follow me on LinkedIn : https://www.linkedin.com/in/herv%C3%A9-ga%C3%ABl-kouamo-157633197/
