Unveiling Roles in K8s with AWS

A Kubernetes cluster in production may contain several workloads for different uses to a wholesome application. These workloads need propitious security to keep every uncongenial fist away.

Let's dive into the capabilities sustained by aws IAM roles in creating users in an EKS cluster (obviously since its aws). Maybe this topic binds kubernetes RBAC but this is essential to know.

First we create our user in aws IAM,

for a practice we use AdministratorAccess and attach policy to it. We create the access key by tapping the user(lets say test) on the IAM interface.

We create the access key and get the credentials along with the arn and get it pasted in another separate file to configure the user in the Kubernetes cluster. Since we will be using the command line to connect the eks, we select the cli option to generate the access and secret access keys.

We need to set up our eks cluster here, if you are practising you can have a single node to avoid more billings.😄 And we need aws cli capability too.

We first need to login the eks as a user with admin access, to configure the role and role binding in kubernetes cluster. During setting aws cli for the first time, we configured the cli as admin, if not you can create an admin user with an administrator role to login as sudo user.

Next, we configure kubeconfig file for kubectl with the command aws eks update-kubeconfig — region us-east-1 — name eks-demo. It will update the kubeconfig as sudo user. Now, we can use kubectl as admin.

Now, we apply the role and rolebinding in the k8s cluster having our main credentials first.

Here, we declare a simple role which says that it will be in the default namespace and its rules derive for pods, which delineates that the user we will mention in rolebinding can get, watch and list the pod. In this case, there will be no association of namespaces, labels etc. It tells that the API groups must be v1.

We can also create role for the whole cluster, which would permit the user for objects around the cluster. These are known as ClusteRole.

That was the role and we need to bind it to a user for that we use rolebinding another object.

A role-binding grants permission to a user or a list of users given in the role. It contains a list of subjects like users, groups, service accounts and references to the role to be bound. Rolebinding references roles to the same namespace. We can reference clusterole in the rolebinding and use it for the same namespace.

Here, we depict the role needed to bind to the provided group. This group should be bound to the aws-auth configmap in the kube-system namespace.

We can see the configmaps in the kube-system by command the kubectl get cm -n kube-system .

We edit the aws-auth configmap by command kubectl edit cm aws-auth -n kube-system. We get to edit the word file for the configmap configuration.

We put the group that we declared in the role binding in the mapUsers section, here we write the userarn(we got while creating the user) for the test and username we named(here as test). Now save the file and close it.

Congratulations! we created a role and assigned it to the user test. This is known as Role Based Access Control.

Now, we login to the test user and can only access pods in the default namespace.

We first log into the aws cli by command aws configure — profile test(any user name), and provide the access and secret access keys we created before.

Now, we update our kubeconfig file for kubectl. The command to help here is aws eks update-kubeconfig — region us-east-1 — name eks-demo — profile test . This is a command to update the kubeconfig.

Since we declared roles for only pods to process, we can only access the pods in the default namespace to some extent. This was a short demonstration of RBAC, for further understanding, we can always refer to the RBAC concepts in Kubernetes documentation.

Thanks for reading.🧡 Hope to see you in my next blog. Keep learning keep sharing.