1. Introduction
As Kubernetes adoption grows across organizations, controlling who can do what inside a cluster becomes critical. In Amazon EKS, this challenge is compounded by the interaction between AWS IAM, EKS authentication, and Kubernetes RBAC.
In many teams, developers only need to deploy and update applications, but not manage cluster infrastructure or access sensitive data like secrets. Granting them full admin access increases risk and violates the principle of least privilege.
In this blog, i will walk through a real‑world, production‑ready RBAC implementation in Amazon EKS that allows a QA/deployment user to:
- Update deployments
- Monitor rollouts
- Push images to ECR
…while explicitly restricting all administrative and destructive actions.
2. What is RBAC and Why Do We Need It?
RBAC (Role‑Based Access Control) is a Kubernetes authorization mechanism that controls who can access which resources and perform which actions inside a cluster.
RBAC answers three key questions:
- Who is the user or service?
- What Kubernetes resources can they access?
- Which actions (verbs) can they perform on those resources?
Without RBAC:
- Every authenticated user may become a de facto admin
- Accidental deletes can take down environments
- Auditing and compliance become difficult RBAC provides fine‑grained, auditable, and secure access control.
- Benefits of RBAC Implementing RBAC provides several tangible benefits:
✅ Least Privilege – users get only what they need
✅ Blast Radius Reduction – mistakes don’t bring down clusters
✅ Security Compliance – aligns with SOC2, ISO, PCI controls
✅ Clear Separation of Duties – infra vs application teams
✅ Auditable Access – easy to review who can do what
- Prerequisites Before starting, ensure the following are in place:
✅ Amazon EKS cluster (Test/QA environment)
✅ Admin access to the EKS cluster
✅ AWS CLI and kubectl configured
✅ An IAM user for deployment (example: web_deploy_qa)
✅ ECR repository for application images
5. Step‑by‑Step Implementation
5.1 Create IAM Policy for Deployment User
This policy allows:
- ECR push
- EKS cluster discovery
Why needed
Without this, the user cannot:
- authenticate to EKS
- push images during deployments
IAM Policy (web-deploy-policy-qa)
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "ecr:GetAuthorizationToken",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ecr:BatchCheckLayerAvailability",
"ecr:InitiateLayerUpload",
"ecr:UploadLayerPart",
"ecr:CompleteLayerUpload",
"ecr:PutImage"
],
"Resource": "arn:aws:ecr:us-west-2:xxxxxxxxxxxx:repository/web-qa-ecr"
},
{
"Effect": "Allow",
"Action": "eks:DescribeCluster",
"Resource": "arn:aws:eks:us-west-2:xxxxxxxxxxxx:cluster/web-qa-eks"
}
]
}
Attach this policy to IAM user web_deploy_qa.
5.2 (Modern EKS) Create EKS Access Entry
Newer EKS clusters use EKS Access Management.
Why needed
In new EKS clusters, aws-auth alone is not enough—Access Entries are mandatory.
✅ Without this step, users get Unauthorized even with correct RBAC.
aws eks create-access-entry \
--cluster-name web-qa-eks \
--principal-arn arn:aws:iam::xxxxxxxxxxx:user/web_deploy_qa \
--region us-west-2
Output:
{
"accessEntry": {
"principalArn": "arn:aws:iam::xxxxxxxxxx:user/web_deploy_qa",
"type": "STANDARD"
}
}
[ec2-user@ip-xxxxxxxxxxxx xxxxxxxxxxxx]$ aws eks create-access-entry \
--cluster-name web-qa-eks \
--principal-arn arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa \
--region us-west-2
{
"accessEntry": {
"clusterName": "web-qa-eks",
"principalArn": "arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa",
"kubernetesGroups": [],
"accessEntryArn": "arn:aws:eks:us-west-2:xxxxxxxxxxxx:access-entry/web-qa-eks/user/xxxxxxxxxxxx/web_deploy_qa/3acedc95-6cab-f7fd-bd78-d84fdac46546",
"createdAt": "2026-01-23T07:08:06.401000+00:00",
"modifiedAt": "2026-01-23T07:08:06.401000+00:00",
"tags": {},
"username": "arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa",
"type": "STANDARD"
}
}
5.3 Associate EKS View Policy (Required for kubectl discovery)
This allows read‑only cluster discovery (namespaces, API resources).
Why needed
kubectl requires read‑only discovery access.
aws eks associate-access-policy \
--cluster-name web-qa-eks \
--principal-arn arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster \
--region us-west-2
[ec2-user@ip-xxxxxxxxxxxx ]$ aws eks associate-access-policy \
--cluster-name web-qa-eks \
--principal-arn arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa \
--policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
--access-scope type=cluster \
--region us-west-2
{
"clusterName": "web-qa-eks",
"principalArn": "arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa",
"associatedAccessPolicy": {
"policyArn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy",
"accessScope": {
"type": "cluster",
"namespaces": []
},
"associatedAt": "2026-01-23T07:08:59.134000+00:00",
"modifiedAt": "2026-01-23T07:08:59.134000+00:00"
}
}
✅ This does NOT grant admin rights.
5.4 Create ClusterRole (Deployment Only)
Why needed
Defines what actions are allowed.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: qa-deployment-clusterrole
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs:
- get
- list
- watch
- patch
- update
- apiGroups: ["apps"]
resources: ["deployments/status", "replicasets"]
verbs:
- get
- list
- watch
[ec2-user@ip-xxxxxxxxxxxx xxxxxxxxxxxx]$ cat <<EOF > qa-deployment-clusterrole.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: qa-deployment-clusterrole
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "patch", "update"]
- apiGroups: ["apps"]
resources: ["deployments/status", "replicasets"]
verbs: ["get", "list", "watch"]
EOF
[ec2-user@ip-xxxxxxxxxxxx xxxxxxxxxxxx]$ ll
total 8
-rw-r--r--. 1 ec2-user ec2-user 317 March 23 05:58 qa-deployment-clusterrole.yaml
[ec2-user@ip-xxxxxxxxxxxx xxxxxxxxxxxx]$ kubectl apply -f qa-deployment-clusterrole.yaml
clusterrole.rbac.authorization.k8s.io/qa-deployment-clusterrole created
Verification -
[ec2-user@ip-xxxxxxxxxxxx xxxxxxxxxxxx]$ kubectl get clusterrole qa-deployment-clusterrole
kubectl get clusterrolebinding qa-deployment-clusterbinding
NAME CREATED AT
qa-deployment-clusterrole 2026-03-23T05:58:46Z
NAME ROLE AGE
qa-deployment-clusterbinding ClusterRole/qa-deployment-clusterrole 15s
5.5 Map IAM User in aws-auth ConfigMap
Why needed
This bridges AWS IAM → Kubernetes identity.
mapUsers: |
- userarn: arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa
username: arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa
groups:
- qa-deployers
``
✅ Proper indentation is critical for EKS authentication.
[ec2-user@xxxxxxxxxxxxxx]$ cat <<EOF > aws-auth-fixed.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/EKS-EC2-Role
username: eks-ec2-role
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::xxxxxxxxxxxx:user/devops-admin
username: devops-admin
groups:
- system:masters
- userarn: arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa
username: web_deploy_qa
groups:
- qa-deployers
EOF
[ec2-user@xxxxxxxxxxxxx]$ ll
total 16
-rw-r--r--. 1 ec2-user ec2-user 518 Apr 23 06:43 aws-auth-fixed.yaml
-rw-r--r--. 1 ec2-user ec2-user 303 Apr 23 05:59 qa-deployment-clusterbinding.yaml
-rw-r--r--. 1 ec2-user ec2-user 317 Apr 23 05:58 qa-deployment-clusterrole.yaml
[ec2-user@xxxxxxxxxxxx]$ kubectl apply -f aws-auth-fixed.yaml
Warning: resource configmaps/aws-auth is missing the kubectl.kubernetes.io/last-applied-configuration annotation which is required by kubectl apply. kubectl apply should only be used on resources created declaratively by either kubectl create --save-config or kubectl apply. The missing annotation will be patched automatically.
configmap/aws-auth configured
[ec2-user@xxxxxxxxxxxxxxxxxxx]$
Verification -
[ec2-user@xxxxxxxxxxxxxxxxxxxxxxx]$ kubectl get configmap aws-auth -n kube-system -o yaml
apiVersion: v1
data:
mapRoles: |
- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/EKS-EC2-Role
username: eks-ec2-role
groups:
- system:masters
mapUsers: |
- userarn: arn:aws:iam::xxxxxxxxxxxx:user/devops-admin
username: devops-admin
groups:
- system:masters
- userarn: arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa
username: web-deploy-qa
groups:
- qa-deployers
kind: ConfigMap
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","data":{"mapRoles":"- rolearn: arn:aws:iam::xxxxxxxxxxxx:role/EKS-EC2-Role\n username: eks-admin-ec2-role\n groups:\n - system:masters\n","mapUsers":"- userarn: arn:aws:iam::xxxxxxxxxxxx:user/devops-admin\n username: devops-admin\n groups:\n - system:masters\n\n- userarn: arn:aws:iam::xxxxxxxxxxxx:user/web_deploy_qa\n username: web-deploy-qa\n groups:\n - qa-deployers\n"},"kind":"ConfigMap","metadata":{"annotations":{},"name":"aws-auth","namespace":"kube-system"}}
creationTimestamp: "2026-04-13T07:07:43Z"
name: aws-auth
namespace: kube-system
resourceVersion: "4329198"
uid: 5bda06d5-f977-4c52-b3d2-556bdd8f5da1
6️⃣ Architecture – Before RBAC
IAM User
│
▼
aws-auth (system:masters)
│
▼
FULL CLUSTER ADMIN ACCESS ❌
Before RBAC Problems:
- ❌ Users often had system:masters
- ❌ Full cluster admin access
- ❌ Could delete namespaces, secrets, workloads
- ❌ High risk of accidental outages
7️⃣ Final Architecture -After RBAC
IAM User (web_deploy_qa)
↓
EKS Access Entry (STANDARD)
↓
AmazonEKSViewPolicy (discovery only)
↓
Kubernetes ClusterRole + ClusterRoleBinding
↓
Controlled deployment updates
✅ Result
- Authentication ✅
- Discovery ✅
- Controlled mutations ✅
- Admin access ❌
8️⃣ Validation Before Handover
- Configure aws IAM user in bastion server-
[ec2-user@xxxxxxxxxxx ~]$ aws configure --profile web_deploy_qa
AWS Access Key ID [None]: xxxxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: xxxxxxxxxxxx
Default output format [None]: json
[ec2-user@xxxxxxxxxxxx ~]$ aws sts get-caller-identity --profile web_deploy_qa
{
"UserId": "xxxxxxxxxxxxxx",
"Account": "xxxxxxxxxxxxx",
"Arn": "arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa"
}
- Update EKS kubeconfig to add profile web_deploy_qa
[ec2-user@xxxxxxxxxxxxxxxxxxx]$ aws eks update-kubeconfig \
--region us-west-2 \
--name web-qa-eks \
--profile web_deploy_qa \
--alias web-deploy-eks-qa
Updated context web-deploy-eks-qa in /home/ec2-user/.kube/config
- Switch to QA context.
[ec2-user@xxxxxxxxxxxxxxxxxxxxx]$ kubectl config use-context web-deploy-eks-qa
Switched to context "web-deploy-eks-qa".
[ec2-user@xxxxxxxxxxxxxxxxxxxxx]$
4.Verify identity:
[ec2-user@xxxxxxxxxxxxxxxxxxxxxxxxxxx]$ kubectl auth whoami
ATTRIBUTE VALUE
Username arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa
UID aws-iam-authenticator:xxxxxxxxxxxxx:xxxxxxxxxxxxx
Groups [system:authenticated]
Extra: accessKeyId [xxxxxxxxxxxxx]
Extra: arn [arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa]
Extra: canonicalArn [arn:aws:iam::xxxxxxxxxxxxx:user/web_deploy_qa]
Extra: principalId [xxxxxxxxxxxxx]
Extra: sessionName []
Extra: sigs.k8s.io/aws-iam-authenticator/principalId [xxxxxxxxxxxxx]
9️⃣ Validation Checklist (Commands)
✅ Allowed
kubectl auth can-i patch deployments --all-namespaces
kubectl auth can-i update deployments --all-namespaces
kubectl auth can-i watch replicasets --all-namespaces
kubectl auth can-i get deployments --all-namespaces
OutPut :
[ec2-user@xxxxxxxxxxxxxx]$ kubectl auth can-i patch deployments --all-namespaces
yes
[ec2-user@xxxxxxxxxxxxxx]$ kubectl auth can-i update deployments --all-namespaces
yes
[ec2-user@xxxxxxxxxxxxxx]$ kubectl auth can-i watch replicasets --all-namespaces
kubectl auth can-i get deployments --all-namespaces
yes
yes
❌ Restricted
kubectl auth can-i delete deployments --all-namespaces
kubectl auth can-i get secrets --all-namespaces
kubectl auth can-i exec pods --all-namespaces
kubectl auth can-i update configmap aws-auth -n kube-system
[ec2-user@xxxxxxxxxxxxxx]$ kubectl auth can-i delete deployments --all-namespaces
kubectl auth can-i create deployments --all-namespaces
kubectl auth can-i get secrets --all-namespaces
kubectl auth can-i exec pods --all-namespaces
no
no
no
no
🔧 Troubleshooting Section
❌ Unauthorized Error
Cause:
- Missing EKS Access Entry
- Checking access entry and add it if required
[ec2-user@xxxxxxxxxxxxxx]$ aws eks list-access-entries --cluster-name web-qa-eks --region us-west-2 {
"accessEntries": [
"arn:aws:iam::xxxxxxxxxxxxxx:role/EKS-EC2-Role",
"arn:aws:iam::xxxxxxxxxxxxxx:role/aws-service-role/eks.amazonaws.com/AWSServiceRoleForAmazonEKS",
"arn:aws:iam::xxxxxxxxxxxxxx:user/devops_admin",
"arn:aws:iam::xxxxxxxxxxxxxx:user/web_deploy_qa"
]
}
❌ aws-auth Looks Correct but Still Fails
Cause:
aws-node cache
Fix:
kubectl rollout restart daemonset aws-node -n kube-system
[ec2-user@xxxxxxxxxxxxxx]$ kubectl rollout restart daemonset aws-node -n kube-system
daemonset.apps/aws-node restarted
❌ Can Get But Cannot Patch Deployments
Cause:
ClusterRoleBinding subject mismatch
Check:
kubectl auth whoami
kubectl get clusterrolebinding -o yaml
[ec2-user@xxxxxxxxxxxxxx]$ kubectl auth whoami
ATTRIBUTE VALUE
Username arn:aws:iam::xxxxxxxxxxxxxx:user/web_deploy_qa
UID aws-iam-authenticator:xxxxxxxxxxxxxx:AIDA3TR7NTEIQMP4HFBAZ
Groups [system:authenticated]
Extra: accessKeyId [xxxxxxxxxxxxxxxxxxxxx]
Extra: arn [arn:aws:iam::xxxxxxxxxxxxxx:user/web_deploy_qa]
Extra: canonicalArn [arn:aws:iam::xxxxxxxxxxxxxx:user/web_deploy_qa]
Extra: principalId [xxxxxxxxxxxxxxx]
Extra: sessionName []
Extra: sigs.k8s.io/aws-iam-authenticator/principalId [AIDA3TR7NTEIQMP4HFBAZ]
[ec2-user@xxxxxxxxxxxxxxx]$ kubectl patch clusterrolebinding qa-deployment-clusterbinding \
--type='json' \
-p='[{"op":"replace","path":"/subjects/0/name","value":"arn:aws:iam::xxxxxxxxxxxxxxxxxxxxx:user/web_deploy_qa"}]'
clusterrolebinding.rbac.authorization.k8s.io/qa-deployment-clusterbinding patched
10. Conclusion
By combining:
✅ IAM policies
✅ EKS Access Entries
✅ AmazonEKSViewPolicy
✅ Kubernetes RBAC
we achieved a secure, least‑privilege, production‑grade access model for application deployment teams.
This approach:
- Prevents privilege escalation
- Protects cluster stability
- Provides a clean operational boundary between infra and dev teams
RBAC is not optional in Kubernetes — it is foundational.
When implemented correctly in EKS, it enables safe scaling of teams without sacrificing security or control.
Happy Orchestrating & Bulletproof K8s! 🛠️
Follow me on LinkedIn: www.linkedin.com/in/alok-shankar-55b94826