Read Time 2 mins | Written by: Daoqi | Celeste Shao
Amazon EKS identity management includes two parts: Authentication and Authorization. In this article, we will discuss AWS’s best practice for cluster authentication and authorization, the reason behind this, and how ASCENDING applies it to real-life applications.
Best Practice
When it comes to identity management in Amazon Elastic Kubernetes Service (Amazon EKS), one of the best practices is to create the EKS cluster with a dedicated IAM role. This allows for better control and security over cluster access. In addition, it is recommended to use AWS IAM for cluster authentication and to create specific IAM roles for different types of users that need varying permissions on the cluster. These IAM roles can then be mapped to Kubernetes roles and rolebindings in the aws_auth config map for authorization.
Another important aspect to consider is the relationship between IAM and Kubernetes RBAC. While Amazon EKS uses IAM for authentication, it still relies on native Kubernetes RBAC for authorization. This means that IAM is only used to validate entities, while all permissions for interacting with the EKS cluster's Kubernetes API are managed through the native Kubernetes RBAC system.
When creating an Amazon EKS cluster, the IAM entity user or role to create the cluster will be automatically granted system:masters permissions in the cluster's RBAC configuration. This access cannot be removed and is not managed through the aws-auth ConfigMap.
ASCENDING Approach
At ASCENDING, we take this Amazon EKS best practice one step further by creating a dedicated EKS creator role with the least access necessary to create an EKS cluster. This role is only used to initially set up cluster admins and is deleted after the config map is configured. Additionally, we create IAM roles for each group of users, such as read-only and power-user access, and map these roles to k8s roles with the least privileged access. This approach ensures that our EKS clusters are secure and that access is granted only to those who need it.
We will also create IAM roles for each kind of user-group, such as read-only, and power-user access. These roles are mapped to k8s’s roles and will be created with the least privileged access.
