Amazon EKS Cross-Account Access

Many times we need to give access to users in other AWS accounts to do some tasks related to applications running on our EKS Clusters. In this demo, we will see how we can provide access for EKS Clusters to another AWS account using Switch Roles, AWS IAM permissions, and Kubernetes RBAC. Without wasting our time, let’s start this demo.

Okay, for this demo, I have two AWS accounts. My first account ends with 5196. And I have created an IAM user called nClouds with full administrator access. And my second account is ending with 9520. In this account, I also created an IAM user called client with full administrator access. To keep this demo simple and understandable, let’s assume that nClouds got a new client. And now nClouds wants access to the EKS Clusters running on the client’s AWS account. So this is our nClouds account. And this is our client’s AWS account. And this is the EKS cluster. As you can see here, eks-demo-1 is running fine. And we can see all the resources running in this cluster.

We are now going to provide access for this EKS cluster to the nClouds account. For this, we need to create an access role, which is a Switch Role. Let me create a role. For that trusted entity type, I’m going to choose the AWS account. And here I’m going to choose another AWS account. Here in the account ID, we need to put the ID of the account for which we are creating this access. In this case, I’m going to copy the nClouds account ID. Let me paste it here. Click on next. For the permissions, I have created a custom policy, which is EKS full access, and I’m giving the EKS full access for this role. And additionally, I have provided an IAM list roles permission so that every IAM user in the nClouds account can list all the IAM roles in the client’s AWS account. Let me choose this policy. And click on next. I’m giving this role a name, nClouds-EKS-cluster-access. Everything looks good here. Let me create this role. Our role is created successfully. As you can see here, the permissions are E for EKS full access, and in trusted relationships, we can see that the account ID is for the nClouds account. Now we have to switch that role from the nClouds AWS account, so I’m going to switch that role. Let me switch that role here. For the account ID, we need to put here the client’s AWS account ID. Let me copy this and paste it here. For the role, we need to provide the role that we created recently. In this case, this is the nClouds EKS access role. And for the display name, we can provide any name here. Let me provide here, the client’s EKS account. Switch this role. Okay, from our nClouds account, we are now accessing the client’s AWS account.

Let me click on the Elastic Kubernetes Service. And here you can see that we are able to list down all the clusters. In this case, there is one cluster which is eks-demo-1. When we click on this cluster, you can see all the basic information here regarding that cluster. But when you click on the Resources, you are not able to see the workloads running on that cluster. As you can see here, there are zero pods running, no deployments, and no replica sets, and over here you get a little warning that your current user or role does not have access to the Kubernetes objects on this EKS Cluster. Basically, this means that we are authenticated to this cluster, but we are not authorized to this EKS cluster.

Basically, providing access to the EKS cluster is a two-step task. The first step is to provide the AWS IAM permissions. In this case, we have provided the full EKS permission to this rule. And the second step is to provide the Kubernetes RBAC permissions. And these permissions are for the authorization for this cluster. Now we have to provide these Kubernetes RBAC permissions. Let’s do that. Okay, in this terminal, I am currently logged in as a client’s IAM user from the client’s AWS account. As you can see here, my user’s details. To provide the Kubernetes RBAC permissions, we need to add that role in a Kube config map. Let me show you that config map. The name of the config map is AWS auth. And this config map is responsible for all the RBAC-related permissions. Basically, when we create an EKS cluster, this config map gets created automatically. And here you can see that there is a section called Map roles and we need to add that role in this section. Let us add that role in this section. And this config map AWS auth is in the Kube system namespace. We need to define that role in this section, which is map roles. Let me edit this.

For the groups, we need to add this role in the groups called system masters. Basically, this group, which is system masters, has all the permissions related to the admin level. When we create an EKS cluster, there is by default a cluster role and cluster role binding created by default, and all the admin level access is provided in that cluster role. Here we need to add the ARN of that role that we created earlier. Let me copy that role’s ARN from the client’s AWS account. Let me paste it here. And we need to provide a username. We can specify any username here. In this case, I’m going to provide nClouds. This means that we are adding this role to this group which is system masters and after adding this role which is nClouds EKS access we’ll have all the admin level permissions with this EKS cluster. Let me save this.

Before, we said that we don’t have any permissions to see the workloads running on these clusters. Let me refresh this page. Okay, great. As you can see here, we are now able to list down all the workloads running in this cluster. This means that we are now authorized to this EKS Cluster. This is all from the AWS console. If we want to switch to or resume that role in the terminal, we have to edit the profile names in the file called AWS credentials. In this case, I have created two profiles. The first one is client and I have mentioned the role that we created on the client-side which is nClouds EKS access the source profile for this is nClouds and in the nClouds profile, I have provided the access key ID and the secret access key for the nClouds IAM user. When I export this profile which is the client here and when we check the caller entity, we will see that we have started our session behind the scenes. This means from the nClouds account. As you can see here, this session is created. This means that we can now execute any commands related to Kubernetes from this terminal from the nClouds account to the client’s account. Let me first update my Kube config to the profile client. And now we are getting the pods information from the nClouds account as you can see here. By doing this, we can provide cross-account access for our EKS cluster to another AWS account. This is all from my side. Thank you everyone for your time.