How do you control who can access an EKS cluster? Explain access entries and the aws-auth ConfigMap.

Summary

Authentication uses IAM: kubectl sends a token derived from the caller's IAM identity. Authorisation inside Kubernetes then maps that identity to permissions. The old method mapped IAM roles to Kubernetes groups in the aws-auth ConfigMap; the newer access entries API manages these mappings through EKS itself, with optional AWS-managed access policies, and is the recommended approach.

Longer Answer

aws-auth was fragile: a typo could lock everyone out, it was edited with kubectl rather than IAM tooling, and the cluster creator had invisible admin rights. Access entries are managed through the EKS API (and IaC), can attach access policies such as AmazonEKSClusterAdminPolicy or namespace-scoped view/edit policies, and work alongside Kubernetes RBAC for fine-grained rules.

Best practices: grant access to IAM roles (assumed through SSO), not individual users; avoid permanent cluster-admin for people; use break-glass roles; and audit access with CloudTrail and the EKS audit logs.

Key Points

• IAM authentication, Kubernetes authorisation.
• aws-auth ConfigMap is legacy and fragile.
• Access entries via the EKS API.
• Roles via SSO; least privilege; audit.