DEV Community

Cover image for 🔐 Implementing Least‑Privilege Access in Amazon EKS Using Kubernetes RBAC
alok shankar
alok shankar

Posted on

🔐 Implementing Least‑Privilege Access in Amazon EKS Using Kubernetes RBAC

#aws #kubernetes #security #tutorial

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:

  1. Who is the user or service?
  2. What Kubernetes resources can they access?
  3. 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.
  1. 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

  1. 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"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Output:

{
  "accessEntry": {
    "principalArn": "arn:aws:iam::xxxxxxxxxx:user/web_deploy_qa",
    "type": "STANDARD"
  }
}
Enter fullscreen mode Exit fullscreen mode 
[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"
    }
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
[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"
    }
}
Enter fullscreen mode Exit fullscreen mode

✅ 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
Enter fullscreen mode Exit fullscreen mode 
[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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
``
Enter fullscreen mode Exit fullscreen mode

✅ 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]$
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

6️⃣ Architecture – Before RBAC

IAM User
│
▼
aws-auth (system:masters)
│
▼
FULL CLUSTER ADMIN ACCESS ❌

Before RBAC Problems:

  1. ❌ Users often had system:masters
  2. ❌ Full cluster admin access
  3. ❌ Could delete namespaces, secrets, workloads
  4. ❌ 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
Enter fullscreen mode Exit fullscreen mode

✅ Result

  1. Authentication ✅
  2. Discovery ✅
  3. Controlled mutations ✅
  4. Admin access ❌

8️⃣ Validation Before Handover

  1. 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"
}
Enter fullscreen mode Exit fullscreen mode
  1. 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
Enter fullscreen mode Exit fullscreen mode
  1. 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]$
Enter fullscreen mode Exit fullscreen mode

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]
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

❌ 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
Enter fullscreen mode Exit fullscreen mode 
[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
Enter fullscreen mode Exit fullscreen mode

🔧 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"
    ]
}
Enter fullscreen mode Exit fullscreen mode

❌ aws-auth Looks Correct but Still Fails
Cause:
aws-node cache

Fix:

kubectl rollout restart daemonset aws-node -n kube-system
Enter fullscreen mode Exit fullscreen mode 
[ec2-user@xxxxxxxxxxxxxx]$ kubectl rollout restart daemonset aws-node -n kube-system
daemonset.apps/aws-node restarted
Enter fullscreen mode Exit fullscreen mode

❌ Can Get But Cannot Patch Deployments
Cause:
ClusterRoleBinding subject mismatch
Check:

kubectl auth whoami
kubectl get clusterrolebinding -o yaml
Enter fullscreen mode Exit fullscreen mode 
[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
Enter fullscreen mode Exit fullscreen mode

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:

  1. Prevents privilege escalation
  2. Protects cluster stability
  3. 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

Top comments (0)