Why EKS API Mode Says ‘Provide Credentials’ Even with Admin Access – The Hidden Access Entry Issue

AWS Elastic Kubernetes Service (EKS) supports two authentication modes: the traditional CONFIG_MAP (aws-auth) and the newer API mode that authenticates directly via IAM. In API mode, a user may encounter the error “the server has asked for the client to provide credentials” even when the IAM principal has AdministratorAccess. This summary explains the cause and provides a concrete remediation.

Case background

A prod cluster was created in the ap-southeast-1 region. The cluster uses API authentication, kubectl v1.32.3 and AWS CLI aws-cli/2.24.24. Initial attempts with the root account failed with the credential error. Switching to an IAM user dave (granted AdministratorAccess) and configuring a profile prod-dave updated the kubeconfig to use client.authentication.k8s.io/v1beta1 and the aws eks get-token command.

error: You must be logged in to the server (the server has asked for the client to provide credentials)

The command

aws eks get-token --cluster-name prod --region ap-southeast-1 --profile prod-dave

successfully generated a token, but kubectl get nodes still returned the same error.

Root cause: Access Entries

In API mode EKS no longer relies on the aws-auth ConfigMap. Each IAM identity must have an explicit Access Entry linked to an access policy (e.g., AmazonEKSClusterAdminPolicy). Without an Access Entry, even an IAM user with broad permissions cannot authenticate.

{
  "accessEntries": []
}

Why this happens

Explicit authorization : Every IAM principal must be registered via create-access-entry or the console.

Permission separation : An Access Entry binds the principal to a specific policy that defines the allowed actions.

Security enforcement : By default, any identity lacking an Access Entry is denied, even if it holds AdministratorAccess or eks:* permissions.

Solution

1. Create Access Entry

aws eks create-access-entry \
  --cluster-name prod \
  --region ap-southeast-1 \
  --principal-arn arn:aws:iam::accountid:user/dave \
  --profile prod

2. Associate Access Policy

aws eks associate-access-policy \
  --cluster-name prod \
  --region ap-southeast-1 \
  --principal-arn arn:aws:iam::accountid:user/dave \
  --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy \
  --access-scope type=cluster \
  --profile prod

3. Verify

List Access Entries again:

aws eks list-access-entries --cluster-name prod --region ap-southeast-1 --profile prod

{
  "accessEntries": [
    "arn:aws:iam::accountid:user/dave"
  ]
}

4. Test access

kubectl get nodes

After the Access Entry is added, the command succeeds and the cluster nodes are listed.

Best‑practice recommendations

Avoid root user : Use IAM users or roles for EKS operations.

Check Access Entries early : After cluster creation, run aws eks list-access-entries to confirm required identities are authorized.

Automate configuration : Incorporate Access Entry creation into CI/CD pipelines or IaC tools (e.g., Terraform) to prevent manual oversights.

Keep tools updated : Upgrade AWS CLI (e.g., to 2.15.x) to ensure compatibility with the latest EKS features.

Scope permissions precisely : Assign specific policies such as AmazonEKSViewPolicy for read‑only users instead of blanket admin rights.

Reference

https://docs.aws.amazon.com/eks/latest/userguide/access-entries.html