An access entry links an IAM principal to Kubernetes permissions, with no ConfigMap editing.

It replaces the old aws-auth ConfigMap, which was easy to break and could lock you out of your own cluster.

Three authentication modes

CONFIG_MAP (old), API_AND_CONFIG_MAP (transition; the API wins), API (recommended). Switching is one-way: forward only.

Managed policies or your own groups

AWS provides access policies (view, edit, admin, cluster admin). For custom rules map an entry to a Kubernetes group and bind it with RBAC.

IaC and audit friendly

Entries are API objects: manage them in Terraform and see changes in CloudTrail. The cluster creator no longer has a hidden admin.

grant read access to one namespace

$ aws eks create-access-entry --cluster-name shop-eu --principal-arn arn:aws:iam::111122223333:role/dev-team
$ aws eks associate-access-policy --cluster-name shop-eu --principal-arn arn:aws:iam::111122223333:role/dev-team \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy --access-scope type=namespace,namespaces=shop

IAM identities become Kubernetes permissions through access entries

Authentication on EKS uses IAM: kubectl obtains a short-lived token from the AWS CLI, and EKS verifies it. The open question is authorization: which Kubernetes permissions does that IAM principal get? Historically this was answered by editing the aws-auth ConfigMap in kube-system, a fragile, hand-edited YAML document where a typo could lock everyone out. EKS access entries replace it with API objects.

An access entry names an IAM principal (role or user) and either associates one or more AWS-managed access policies (such as view, edit, admin or cluster admin, optionally scoped to specific namespaces) or maps the principal to Kubernetes groups that you bind with ordinary RBAC. Reveal the four stages with the right arrow.

Migration is one-directional. A cluster starts in CONFIG_MAP mode, can move to API_AND_CONFIG_MAP, where entries from the API take priority, and then to API. You cannot go back, so migrate deliberately: create entries for all existing mappings, test, then switch to API.

Because access entries are API-managed, they work well with Terraform and appear in CloudTrail. Combine them with AWS IAM Identity Center (SSO) roles for humans, and use separate roles for CI. Gotcha: removing an entry for the role your pipeline uses locks the pipeline out immediately, so change them through a reviewed workflow.