EKS Identity Mapping and RBAC

By /

Scenario: You are the DevSecOps Architect. You need to grant a newly hired developer (eks-developer) read-only access strictly to the dev-team namespace in your EKS cluster. They should not be able to view or modify anything in the default or kube-system namespaces.

Prerequisites

  • An AWS Account with administrative privileges.
  • aws-cli installed and configured.
  • kubectl installed.
  • eksctl installed (we will use this to quickly spin up a test cluster).

Step 1: Provision the EKS Lab Cluster

First, let’s spin up a small, single-node cluster. The IAM user/role you use to run this command will automatically become the implicit system:masters administrator.

Bash
# Create a basic EKS cluster (This takes about 15 minutes)
eksctl create cluster \
  --name eks-auth-lab \
  --region us-east-1 \
  --nodes 1 \
  --node-type t3.medium

Verify your admin access once it finishes:

Bash
kubectl get nodes

Step 2: Create the “Developer” IAM Identity

We need an external AWS identity to map. For this lab, we will create an IAM User (though in production, you would map an IAM Role assumed via AWS SSO).

Bash
# 1. Create the IAM User
aws iam create-user --user-name eks-developer

# 2. Create Access Keys for the user
aws iam create-access-key --user-name eks-developer

Important: Note the AccessKeyId and SecretAccessKey from the JSON output.

Configure a new local AWS profile for this developer:

Bash
aws configure --profile eks-developer
# Paste the Access Key ID
# Paste the Secret Access Key
# Default region name: us-east-1
# Default output format: json

Get your AWS Account ID and note the developer’s full ARN (you will need this in Step 4):

Bash
aws sts get-caller-identity --profile eks-developer
# The ARN will look like: arn:aws:iam::111122223333:user/eks-developer

Step 3: Create the Kubernetes RBAC (The Locks)

Now, acting as the Cluster Admin (your default AWS profile), create the namespace, the Role, and the RoleBinding inside Kubernetes.

1. Create the Namespace:

Bash
kubectl create namespace dev-team

2. Create the Role (role.yaml): This defines what actions are allowed.

Bash
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: dev-reader
rules:
- apiGroups: [""]
  resources: ["pods", "services"]
  verbs: ["get", "watch", "list"]

Apply it: kubectl apply -f role.yaml

3. Create the RoleBinding (rolebinding.yaml): This binds the Role to a specific Kubernetes group called dev-team-group.

Bash
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev-team
subjects:
- kind: Group
  name: dev-team-group # This is the badge color we will hand out!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: dev-reader
  apiGroup: rbac.authorization.k8s.io

Apply it: kubectl apply -f rolebinding.yaml

Step 4: The Translation (EKS Access Management API)

At this moment, the IAM user exists, and the Kubernetes RBAC exists, but they are completely disconnected. Let’s bridge them using the modern EKS Access API.

We are going to tell EKS: “If anyone authenticates as arn:aws:iam::111122223333:user/eks-developer, hand them the Kubernetes group badge called dev-team-group.”

Bash
# Replace <YOUR_ACCOUNT_ID> with your actual AWS Account ID
aws eks create-access-entry \
  --cluster-name eks-auth-lab \
  --principal-arn arn:aws:iam::<YOUR_ACCOUNT_ID>:user/eks-developer \
  --kubernetes-groups dev-team-group

Note: Because we are using the modern API, we do not need to touch the dangerous aws-auth ConfigMap!

Step 5: Test and Verify the Flow

Now, put on your “Developer” hat. You will attempt to access the cluster using the eks-developer AWS profile.

1. Update the local kubeconfig as the developer:

Bash
aws eks update-kubeconfig \
  --name eks-auth-lab \
  --region us-east-1 \
  --profile eks-developer

2. Test 1: Authorized Access (Success)

Attempt to list pods in the assigned namespace.

Bash
kubectl get pods -n dev-team

Result: No resources found in dev-team namespace. (Success! You authenticated, and RBAC authorized you to look, even if nothing is there yet).

3. Test 2: Unauthorized Namespace (403 Forbidden)

Attempt to look at the default namespace.

Bash
kubectl get pods -n default

Result: Error from server (Forbidden): pods is forbidden: User "..." cannot list resource "pods" in API group "" in the namespace "default" (Success! Authentication passed, but Kubernetes RBAC successfully blocked you).

4. Test 3: Unauthorized Action (403 Forbidden)

Attempt to delete a pod in the allowed namespace.

Bash
kubectl delete pod fake-pod -n dev-team

Result:Error from server (Forbidden): pods "fake-pod" is forbidden: User "..." cannot delete resource "pods" in API group "" in the namespace "dev-team"(Success! RBAC proves that read-only means read-only).

Step 6: Lab Cleanup

To avoid AWS charges, destroy the resources you created. Switch back to your administrator terminal/profile to run these.

Bash
# Delete the cluster (Takes ~10 minutes)
eksctl delete cluster --name eks-auth-lab --region us-east-1

# Delete the IAM Developer User and Keys
aws iam delete-access-key --access-key-id <YOUR_ACCESS_KEY> --user-name eks-developer
aws iam delete-user --user-name eks-developer

This lab perfectly complements your theoretical article by allowing your readers to experience the “Airport Border Control vs. Conference Room Locks” analogy in a real terminal.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top