Why Access Entries are Better for DevSecOps
The legacy aws-auth method was essentially a “black box” to AWS IAM. Kubernetes handled the mapping internally. The new API brings several improvements:
- Auditability: Every change is logged in AWS CloudTrail. You can see exactly who granted permissions and when.
- No YAML Risk: You use AWS CLI, Terraform, or Pulumi commands. No more manual editing of a sensitive system ConfigMap.
- Decoupled Permissions: You can grant access to an IAM role without having to create a corresponding Kubernetes RBAC Group manually in some cases, using Access Policies.
- Visibility: You can run
aws eks list-access-entriesto see exactly who has access to your cluster directly from the AWS Console or CLI.
How it Works: The Three Components
Instead of one giant string in a ConfigMap, the new system uses three distinct AWS resources:
- Access Entry: The “Identity” link. It tells EKS that a specific IAM Principal (User or Role) is allowed to talk to the cluster.
- Access Policy: The “Permission” set. These are AWS-managed policies (like
AmazonEKSAdminPolicyorAmazonEKSViewPolicy) that map to Kubernetes permissions. - Policy Association: The “Binding.” This links the Access Entry to the Access Policy, scoped to a specific namespace or the whole cluster.
Lab: The Modern Way (Access Entry API)
If you still have your cluster from the previous step (or create a new one with --authentication-mode API), here is how you would grant the same “Reader” access using the new API.
Prerequisites
- AWS CLI and
eksctlinstalled. - Your AWS Account ID and preferred Region.
Step 1: Provision an EKS Cluster (API Mode)
To use the modern API, we must set the authentication mode to API. This completely ignores the aws-auth ConfigMap.
eksctl create cluster \
--name modern-access-lab \
--region <YOUR_AWS_REGION> \
--nodegroup-name standard-nodes \
--node-type t3.medium \
--nodes 2 \
--authentication-mode API(Note: Provisioning takes approximately 10–15 minutes).
2. Create the Role:
aws iam create-role \
--role-name EKS-Modern-Reader \
--assume-role-policy-document file://trust-policy.jsonStep 3: Create the Access Entry
This step registers the IAM Role with the EKS cluster. Think of this as the “Identity” phase.
aws eks create-access-entry \
--cluster-name modern-access-lab \
--principal-arn arn:aws:iam::<YOUR_ACCOUNT_ID>:role/EKS-Modern-Reader \
--username modern-dev-userStep 4: Associate an Access Policy
Now we grant permissions using AWS-managed policies. We will use the AmazonEKSViewPolicy and scope it to the default namespace.
aws eks associate-access-policy \
--cluster-name modern-access-lab \
--principal-arn arn:aws:iam::<YOUR_ACCOUNT_ID>:role/EKS-Modern-Reader \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=namespace,namespaces=[default]Step 5: Verify and Test Access
We will now assume the role and verify that the permissions are active.
1. Configure the CLI Profile: Append this to your ~/.aws/config file:
[profile eks-modern]
role_arn = arn:aws:iam::<YOUR_ACCOUNT_ID>:role/EKS-Modern-Reader
source_profile = default2. Update Kubeconfig:
aws eks update-kubeconfig --region <YOUR_AWS_REGION> --name modern-access-lab --profile eks-modern3. Test Read Permissions (Should Succeed):
kubectl get pods -n default4. Test Boundary Permissions (Should Fail): Since we scoped the policy to the default namespace, trying to view pods in kube-system should be forbidden.
kubectl get pods -n kube-system(Expected output: Error from server (Forbidden)…)
Step 6: Audit the Access (DevSecOps Visibility)
One major benefit of this API is visibility. You can see all access entries directly from the CLI.
aws eks list-access-entries --cluster-name modern-access-labStep 7: Cleanup
Always delete your resources to prevent unnecessary AWS costs.
1. Restore Admin Access:
aws eks update-kubeconfig --region <YOUR_AWS_REGION> --name modern-access-lab2. Delete Cluster and Role:
eksctl delete cluster --name modern-access-lab --region <YOUR_AWS_REGION>
aws iam delete-role --role-name EKS-Modern-Reader