EKS aws-auth ConfigMap Lab
This lab will guide you through creating an IAM role, defining Kubernetes RBAC permissions, and manually mapping the two using the aws-auth ConfigMap.
Here are the step-by-step commands and YAML files you need to successfully complete the lab.
Make sure you replace with your actual AWS Account ID and with your preferred region (e.g., us-east-1) and `` with your user before running the commands.
Step 1: Provision an EKS Cluster (Legacy Mode Enabled)
We need to create a cluster that explicitly allows the aws-auth ConfigMap using the API_AND_CONFIG_MAP authentication mode.
Bash
eksctl create cluster \
--name legacy-iam-lab \
--region \
--nodegroup-name standard-nodes \
--node-type t3.medium \
--nodes 2 \
--authentication-mode API_AND_CONFIG_MAP
``
eksctl create cluster \
--name legacy-iam-lab \
--region \
--nodegroup-name standard-nodes \
--node-type t3.medium \
--nodes 2 \
--authentication-mode API_AND_CONFIG_MAP
(Note: This step will take about 10-15 minutes to provision the cluster and nodes).
Step 2: Create a New AWS IAM Role
1. Create the Trust Policy File: Create a file named trust-policy.json. This policy allows your own AWS account to assume this role.
trust-policy.json:
Bash
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::"
},
"Action": "sts:AssumeRole"
}
]
}
``
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam:::"
},
"Action": "sts:AssumeRole"
}
]
}
2. Create the Role via AWS CLI:
Bash
aws iam create-role \
--role-name EKS-Dev-Reader \
--assume-role-policy-document file://trust-policy.json
``
aws iam create-role \
--role-name EKS-Dev-Reader \
--assume-role-policy-document file://trust-policy.json
Step 3: Create Kubernetes RBAC (The Authorization)
Now we define what the Kubernetes group dev-reader-group is allowed to do.
1. Create the RBAC File: Create a file named rbac.yaml. This creates a Role (permissions) and a RoleBinding (attaching the permissions to the group).
rbac.yaml:
Bash
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: default
subjects:
- kind: Group
name: dev-reader-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
``
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: default
subjects:
- kind: Group
name: dev-reader-group
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
2. Apply the RBAC to the Cluster:
Bash
kubectl apply -f rbac.yaml
``
kubectl apply -f rbac.yaml
Step 4: The Legacy Mapping (aws-auth ConfigMap)
This is the manual, error-prone step of mapping the AWS Role to the Kubernetes Group.
1. Open the ConfigMap for editing:
Bash
kubectl edit configmap aws-auth -n kube-system
``
kubectl edit configmap aws-auth -n kube-system
2. Modify the ConfigMap: Your editor will open. Look for the mapRoles block under data. You need to carefully append the new role. Pay strict attention to the YAML indentation.
Make it look like this (adding the bottom block):
YAML
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam:::role/eksctl-legacy-iam-lab-nodegroup-NodeInstanceRole-XXXXXXX
username: system:node:{{EC2PrivateDNSName}}
- rolearn: arn:aws:iam:::role/EKS-Dev-Reader
username: dev-user
groups:
- dev-reader-group
``
apiVersion: v1
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
rolearn: arn:aws:iam:::role/eksctl-legacy-iam-lab-nodegroup-NodeInstanceRole-XXXXXXX
username: system:node:{{EC2PrivateDNSName}}
- rolearn: arn:aws:iam:::role/EKS-Dev-Reader
username: dev-user
groups:
- dev-reader-group
Save and close the editor (usually :wq if it opens in vim). You should see: configmap/aws-auth edited.
Step 5: Test the Access (The Handshake)
1. Configure a temporary AWS profile: Open your AWS config file (~/.aws/config) in a text editor and append the following profile at the bottom:
~/.aws/config addition:
Bash
[profile eks-dev]
role_arn = arn:aws:iam:::role/EKS-Dev-Reader
source_profile = default
``
[profile eks-dev]
role_arn = arn:aws:iam:::role/EKS-Dev-Reader
source_profile = default
2. Update your kubeconfig to use this new identity:
Bash
aws eks update-kubeconfig --region --name legacy-iam-lab --profile eks-dev
``
aws eks update-kubeconfig --region --name legacy-iam-lab --profile eks-dev
3. Run the Authorization Test (Should Succeed):
Bash
kubectl get pods -n default
``
kubectl get pods -n default
(Expected output: "No resources found in default namespace" — this means you authenticated successfully, there just aren't any pods yet).
4. Run the Boundary Test (Should Fail):
Bash
kubectl get nodes
``
kubectl get nodes
(Expected output: Error from server (Forbidden): nodes is forbidden: User "dev-user" cannot list resource "nodes" in API group...)
Step 6: Cleanup
To avoid charges, clean up the resources. First, switch back to your admin profile so you have permission to delete the cluster.
1. Restore your kubeconfig to your admin profile:
Bash
aws eks update-kubeconfig --region --name legacy-iam-lab
``
aws eks update-kubeconfig --region --name legacy-iam-lab
2. Delete the EKS Cluster:
Bash
eksctl delete cluster --name legacy-iam-lab --region
``
eksctl delete cluster --name legacy-iam-lab --region
3. Delete the IAM Role:
Bash
aws iam delete-role --role-name EKS-Dev-Reader
``
aws iam delete-role --role-name EKS-Dev-Reader