Managing users on AWS EKS

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.

  1. Adding an IAM user directly on Kubernetes.
  2. 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.

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 add
  • username: username within Kubernetes to map to the IAM user
  • groups: list of groups within Kubernetes to which the user is mapped to. In these examples I’m using system: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:

  1. Create an IAM role.
  2. Add it to Kubernetes using configmap/aws-auth.
  3. 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.

  1. Edit the trust relationships to add the AWS account(s) that will be allowed to assume the role.
  2. 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!

Leave a Reply

Your email address will not be published. Required fields are marked *