
One of the many things we need to do when we work with an EKS cluster is adding or removing users so they can interact with the system. On this post we will go through two different options.
- Adding an IAM user directly on Kubernetes.
- Managing users with IAM groups and roles.
To do any of this we need edit a ConfigMap
: aws-auth.
Using kubectl
with an IAM user able to access the cluster:
$ kubectl -n kube-system edit configmaps aws-auth
Depending on wether it’s been edited before or not, we will see different sections. There will be one called mapRoles
and there might or might not be one called mapUsers
. Seeing this, let’s being witht he first way of adding someone to EKS. For these examples I will use the admins group.
Note: When we create an EKS cluster, the user that created it receives automatic admin access. That user will not be affected by the changes we will make here, so if something goes wrong we can restore normal access with it. AWS tech support’s advice is using a “generic” account to create EKS cluster and keep the details save. Do not use a regular person’s account, they can leave the company and then you coud loose access to that safe account.
Table of Contents
1. Adding an IAM user
To add an IAM user we simply need to use the following information:
userarn
: the ARN of the IAM user to addusername
: username within Kubernetes to map to the IAM usergroups
: list of groups within Kubernetes to which the user is mapped to. In these examples I’m usingsystem:masters
, admin access.
Example of adding a user to aws-auth
:
mapUsers: | - userarn: arn:aws:iam::xxxxxxxx:user/daveops username: daveops groups: - system:masters
This is a YAML list, if you need to add more users just append the structure after the first user.
This method works but I don’t recommend it. In my opinion it’s not very robust. Every time you need to add or remove a user you need to edit the configmap
. In my case, I made a change I had made a hundred times before to a cluster I inherited from a previous DevOps engineer. I made a mistake and we completely lost access to it. The account used to create the cluster was no longer available and it was impossible for us to recover access, we had to contact AWS support and after all, the fastest solution was spinning up a new cluster and migrating all our stuff to it.
2. Use IAM roles and groups
For me, this is the best way to manage our users in EKS. We need to:
- Create an IAM role.
- Add it to Kubernetes using
configmap/aws-auth
. - Create a group to control who can assume the role we’ve just created.
Creating an IAM role
This is the easiest part of all the process. We need to create a role, but we don’t need to give it any sort of permissions.
- Edit the trust relationships to add the AWS account(s) that will be allowed to assume the role.
- Take a note of the role ARN, we will need it later.
Adding the role to Kubernetes
This is almost exactly the same as what we did with the users earlier, except that we won’t edit mapUsers
this time, we will change mapRoles
.
$ kubectl -n kube-system edit configmaps aws-auth
mapRoles: | - rolearn: arn:aws:iam::xxxxxxxx:role/KubernetesClusterAdmin username: KubernetesClusterAdmin groups: - system:masters
Creating an IAM group to control access
We now need to create a group to control which users are allowed to assume the role. This is the easiest way to grant or forfeit access. Instead of editing a configmap on Kubernetes, we simply add or remove to/from a group.
The Group Policy we need to add to that group should be similar to the one below. Change the Resource
value for your role ARN and you should be good to go.
{ "Version": "2012-10-17", "Statement": [ { "Sid": "123", "Effect": "Allow", "Action": [ "sts:AssumeRole" ], "Resource": [ "arn:aws:iam::xxxxxxxx:role/KubernetesClusterAdmin" ] } ] }
And we just need to add users to the group now. Once they have permissions to assume the role, they’ll be able to use the cluster.
If you’ve reached this point, thank you very much! This is the first post in my blog, I hope it’s been helpful in some way. In the next post I’ll explain how to configure the AWS client and kubectl
to be able to access Kubernetes.
See you next time!