Search for a command to run...
Understand how IAM Access Entries can replace aws-auth for managing EKS IAM authentication.
Hey, Y'all 👋 Kratik Here :)
Hailing from The City of Lakes, India.
I love to learn and share stuff about DevOps, SRE, Security, Cost Optimization, etc.
Join me on this journey where we will learn together with the help bunch of interesting blogs.
thanks buddy :)
DNS Search Domains, ndots, and Kubernetes Resolver Behavior
Effective Techniques for Providing IAM Access to EKS Pods
Ever wondered how can you create your own custom Github Action and publish it to the GitHub Marketplace? Let's learn it step by step in this blog.
Let's setup Vault with External-secrets to manage secrets in Kubernetes like never before!
Hi People!
Hope you're happy managing your EKS clusters. There is this one thing we all do in our EKS related shenanigans - To provide an IAM entity access to your EKS Cluster. I personally find this annoying as I have to go and manually edit a ConfigMap called aws-auth
from the official docs:
One more thing is that whoever IAM entity (User or Role) creates the EKS cluster, automatically becomes the owner of that EKS Cluster. In some cases, we don't really want that, because it may become hard to track sometimes who created the cluster as this is not visible in any configuration in AWS.
In Dec 2023, AWS announced, new feature in Elastic Kubernetes Service (EKS), which helps cluster administrators to simplify mapping and configuration of AWS Identity and Access Management (IAM) users and roles with Kubernetes clusters.
But let's understand this deprecated approach first
This ConfigMap resides in the kube-system namespace and controls the access of IAM principals who are allowed to access the cluster.
Internally it uses AWS IAM Authenticator in Control plane which reads it's configuration from this aws-auth ConfigMap.
This ConfigMap looks something like below :
This feature comes with a burden to manage complex ConfigMap for every IAM Principal. You may end up messing up this ConfigMap and hence, losing access to your cluster 🤷♂️
Also, It does not come with IAM audit logging.
This is a new set of APIs, which added another yet native way to setup authentication between your Kubernetes Cluster and IAM entities.
You can setup this during or after cluster creation. Also, At the time of writing this article, we have option to use either aws-auth ConfigMap or IAM Access Entries or both.
You can either configure this at the time of cluster creation or afterwards for an existing EKS cluster as well.
Let's take example when creating a fresh cluster :
I have created a fresh EKS Cluster, It is important to note that, In the Cluster access section you have to keep config like below:
^ Here you can See I have selected Disallow cluster administrator access and In Cluster authentication mode, I have selected EKS API.
It ensures that whoever (IAM User or Role) creating this cluster does not get the admin/owner access by default. And when you select EKS API only in the cluster auth mode, you are opting here to utilize IAM Access Entries rather than aws-auth ConfigMap.
We see a screen with bunch of inputs. Let's try to understand it :
IAM Principal - select the IAM entity for which you want to grant access. (similar to mapUsers and mapRoles from aws-auth ConfigMap) In our case, we have selected an IAM user - test-user
Type (optional) - as we are creating this for our test IAM user, we can keep this as Standard , Other Options are : EC2 Linux, EC2 Windows and FARGATE_LINUX
note from the docs - If you create an access entry with typeEC2 LinuxorEC2 Windows, the IAM principal creating the access entry must have theiam:PassRolepermission.
Username (optional) - username to be used while authenticating with K8s APIs.
Groups (optional) - You can mention any group if you are using one in RoleBinding or ClusterRoleBinding subjects. I was wondering how to bind a user, and in this documentation, I found out (It does not apply to EKS but just in case) :
also, FYI
You don't need to create an access entry for an IAM role used by a managed node group or a Fargate profile. Amazon EKS automatically adds entries for these roles to the aws-auth ConfigMap, regardless of your cluster's platform version.
For more info on these inputs, check the table below from AWS Docs.
Choose Access Policy. This will define your access level in your EKS Cluster.
Here, you can select some of the pre-defined access policies.
AmazonEKSAdminPolicy
AmazonEKSClusterAdminPolicy
AmazonEKSAdminViewPolicy
AmazonEKSEditPolicy
AmazonEKSViewPolicy
AmazonEMRJobPolicy
Either you can grant the access using policies at cluster level or you can bind a namespace rather than whole cluster for more fine-grained controls. (as shown below)
Select your policy and choose scope and then you have to click on Add Policy to add all the policies one by one. (shown below)
test-user I am selecting AmazonEKSAdminPolicy policy.
To test this, I logged in as test-user in AWS CLI.
Also I downloaded the kubeconfig using following command.
aws eks update-kubeconfig --name kratik-testing-iam-access-entries --alias kratik-testing-iam-access-entries
Before creating the IAM access Entry, I used to see this.
woohoo! we were able to delegate IAM permissions to our test-user using IAM Access Entry.
Visibility in Console about the access about the IAM Principals having the access.
Saves you from messing up the EKS Access by not managing complex entries in AWS ConfigMap.
and anyways, as aws-auth is deprecated you should migrate to EKS IAM Access Entries.
Thank you for reading this article 🌻
Let me know if you have any feedback or suggestions.
Peace out!
https://aws.github.io/aws-eks-best-practices/security/docs/iam/
https://docs.aws.amazon.com/eks/latest/userguide/creating-access-entries.html
https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html
https://docs.aws.amazon.com/eks/latest/userguide/access-policies.html
https://docs.aws.amazon.com/eks/latest/userguide/migrating-access-entries.html
https://docs.aws.amazon.com/eks/latest/userguide/auth-configmap.html