RBAC

Task 8: RBAC, Access Control & Security in AWS EKS (Real-Time Scenarios)

Why is Security Critical in Kubernetes?

• Prevent unauthorized access to Kubernetes API

• Secure applications using RBAC, IAM, and Service Accounts

• Protect data using Network Policies & Secrets Management

• Detect threats using Audit Logs & Runtime Security

---

🔹 Step 1: Role-Based Access Control (RBAC) for Users

AWS EKS does not use Kubernetes RBAC for users directly. Instead, IAM users & roles are mapped to Kubernetes RBAC.

1️⃣ Verify the AWS IAM Authenticator

kubectl get configmap -n kube-system aws-auth -o yaml

This maps AWS IAM users/roles to Kubernetes users.

---

2️⃣ Grant a User Read-Only Access to EKS

1️⃣ Create an IAM Role & Attach Policies

aws iam create-role --role-name EKSReadOnlyRole \
    --assume-role-policy-document file://trust-policy.json

trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT_ID:user/JaneDoe"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Attach ReadOnly Policy:

aws iam attach-role-policy --role-name EKSReadOnlyRole \
    --policy-arn arn:aws:iam::aws:policy/AmazonEKSReadOnlyAccess

2️⃣ Map IAM Role to Kubernetes RBAC Edit aws-auth ConfigMap:

kubectl edit configmap -n kube-system aws-auth

Add:

mapRoles:
  - rolearn: arn:aws:iam::ACCOUNT_ID:role/EKSReadOnlyRole
    username: readonly-user
    groups:
      - system:view

3️⃣ Apply RBAC in Kubernetes

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: readonly-role
rules:
  - apiGroups: [""]
    resources: ["pods", "services"]
    verbs: ["get", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: readonly-binding
  namespace: default
subjects:
  - kind: User
    name: readonly-user
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: readonly-role
  apiGroup: rbac.authorization.k8s.io

✅ User now has read-only access to pods & services.

---

🔹 Step 2: Secure Application Access using Service Accounts

1️⃣ Create a Service Account for an Application

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-service-account
  namespace: default

kubectl apply -f app-service-account.yaml

2️⃣ Grant the Service Account Access to Secrets

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: secret-reader
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secret-reader-binding
  namespace: default
subjects:
  - kind: ServiceAccount
    name: app-service-account
    namespace: default
roleRef:
  kind: Role
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

✅ Now, only this application can access secrets.

---

🔹 Step 3: AWS IAM Roles for Service Accounts (IRSA)

To allow Kubernetes workloads to use AWS services securely without hardcoding credentials.

1️⃣ Create an IAM Role with an OIDC Trust Policy

eksctl utils associate-iam-oidc-provider --cluster eks-cluster --approve

aws iam create-role --role-name EKSIRSA-Role --assume-role-policy-document file://trust-policy.json

trust-policy.json:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::ACCOUNT_ID:oidc-provider/OIDC_PROVIDER"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "OIDC_PROVIDER:sub": "system:serviceaccount:default:app-service-account"
        }
      }
    }
  ]
}

2️⃣ Attach S3 Access to the Role

aws iam attach-role-policy --role-name EKSIRSA-Role \
    --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

3️⃣ Associate the Role with a Service Account

eksctl create iamserviceaccount \
  --name app-service-account \
  --namespace default \
  --cluster eks-cluster \
  --attach-role-arn arn:aws:iam::ACCOUNT_ID:role/EKSIRSA-Role \
  --approve

✅ Now, any Pod using this service account can access S3 securely.

---

🔹 Step 4: Network Security with Network Policies

Use NetworkPolicies to restrict traffic between namespaces & pods.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

This blocks all traffic. To allow specific access:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: database
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - protocol: TCP
      port: 5432

✅ Now, only backend pods can talk to database pods.

---

🔹 Step 5: Kubernetes Secrets Encryption

Enable encryption at rest for secrets.

1️⃣ Generate Encryption Key

head -c 32 /dev/urandom | base64

2️⃣ Edit Encryption Config

kind: EncryptionConfiguration
apiVersion: apiserver.config.k8s.io/v1
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: BASE64_ENCODED_SECRET
      - identity: {}

3️⃣ Enable Encryption

kubectl get secrets -n default -o yaml

✅ Now, secrets are encrypted at rest.

---

🔹 Step 6: Enable Kubernetes Audit Logs

To track security events & API access.

1️⃣ Enable Audit Logging in EKS

aws eks update-cluster-config --name eks-cluster \
    --logging '{"clusterLogging":[{"types":["audit"],"enabled":true}]}'

2️⃣ Check Audit Logs in CloudWatch

aws logs describe-log-groups | grep eks

✅ Now, all API calls are logged.

---

Common Security Issues & Fixes

Issue	Cause	Fix
Unauthorized error when using kubectl	RBAC role missing.	Assign correct role.
Pod has access to AWS resources it shouldn’t	IRSA misconfigured.	Check IAM role & Service Account.
NetworkPolicy blocks all traffic	Policy too strict.	Allow necessary ingress/egress.
Secrets stored in plain text	No encryption enabled.	Use encryption at rest.
Pods can talk to each other freely	No Network Policies.	Implement zero-trust networking.

---

Final Summary

✔ IAM Users mapped to RBAC roles ✔ Applications use Service Accounts securely ✔ Pods use AWS resources via IRSA ✔ Network Policies restrict communication ✔ Secrets are encrypted at rest ✔ Audit Logs track security events

---

NEXT: Do you want to proceed with Container Runtime Security (Falco, Kyverno, etc.)? 🚀