This is EKS-specific and requires the cluster's authentication mode to be CONFIG_MAP or API_AND_CONFIG_MAP.

A cluster fully migrated to API mode ignores this ConfigMap entirely.

If aws-auth doesn't exist yet (self-managed clusters, or a fresh EKS cluster before it's applied), create it directly instead of patching.

Patch or create the aws-auth ConfigMap in kube-system, mapping your AWS IAM ARN to the system:masters group

Authenticate via AWS CLI as cluster-admin

Any IAM principal whose ARN is mapped can use it, including one from another AWS account, and it needs no AWS permissions of its own to do so

The bearer token is a locally signed GetCallerIdentity request, an API that requires no allow policy, so a zero-permission identity still authenticates

Editing the node role own entry is tempting but fails wherever that role has an access entry, since access entries override aws-auth for the same principal

Removing the mapping revokes access at once, unlike the certificate paths where an issued credential cannot be recalled

Console clusters using Auto Mode are created in API mode where this is inert, while a raw CreateCluster call with no accessConfig defaults to CONFIG_MAP where it is live