## TL;DR
EKS does not know your IAM identity until it is mapped into the cluster, and unmapped identities get exactly this error. Add your IAM user or role to the aws-auth ConfigMap (or create an access entry on newer clusters), wait a moment for it to propagate, and kubectl starts working. Also double-check you are using the right AWS profile and region before assuming the mapping is missing.

```text
EKS "your current user or role does not have access to Kubernetes objects on this EKS cluster"
```

## Steps

1. Confirm which IAM identity you are actually calling with.
   Expected: you see the exact user ARN or role ARN that EKS is rejecting, which is what you need to map.

2. Check the AWS profile and region your kubectl is using against the cluster's real region.
   Expected: profile and region match the cluster; a surprising number of these errors are just the wrong profile.

3. Read the cluster's aws-auth ConfigMap and look for your identity in the user and role mappings.
   Expected: your ARN is absent, which confirms the diagnosis - the mapping is missing, not broken.

4. Add a mapping for your IAM user or role, granting the appropriate Kubernetes groups.
   Expected: the ConfigMap (or access entry) now contains your ARN; on newer clusters prefer the access entries API over editing the ConfigMap.

5. Wait briefly for propagation, then verify access with a harmless read.
   Expected: kubectl can list namespaces or run an auth check successfully - access granted.

6. If it still fails, check whether the cluster uses access-entry-only authentication mode, which ignores the ConfigMap entirely.
   Expected: you find the mode mismatch and create the access entry instead of editing a ConfigMap the cluster never reads.

## Use this when
- kubectl returns the "does not have access" error on an EKS cluster
- onboarding a new team member or CI role to EKS
- a previously working role assumption or SSO setup changed

## Not for this skill when
- kubeconfig points at the wrong cluster - the error would look different, fix the context
- the token is expired - re-authenticate rather than remapping
- you can reach the cluster but a specific action is forbidden - that is RBAC inside the cluster, not IAM mapping

## Variant phrasings
- EKS unauthorized your current user or role
- aws-auth configmap add user EKS
- EKS access entry vs aws-auth
- kubectl access denied EKS new cluster

## Why it happens
EKS authenticates the TLS connection with IAM, then authorizes against Kubernetes RBAC - but the bridge between the two is the identity mapping. The cluster creator is mapped automatically; everyone else must be added explicitly, and there is no default that lets arbitrary IAM identities in.

## Edge cases
- SSO roles have session names appended to the ARN; map the role ARN pattern, not one session
- A cluster created by a different AWS account needs cross-account role mapping, not just a local user entry
- Access entries and the ConfigMap can both exist; know which authentication mode the cluster uses or edits go nowhere
- Mapping with overly broad groups (like cluster-admin) for a CI role is a standing privilege problem - grant the narrowest groups that work

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BShsS55qQUgw0BCZRrB14Q