Amazon EKS — Kubernetes RBAC

1 minute read

Kubernetes RBAC

RBAC (Role-Based Access Control) controls who can do what inside your Kubernetes cluster. It defines permissions using Roles and ClusterRoles, then assigns them using Bindings.

RBAC Components

RBAC Model
┌──────────────────────────────────────────────────────┐
│                                                      │
│  WHO (Subject)         WHAT (Role)         WHERE     │
│  ┌──────────┐         ┌──────────┐                   │
│  │ User     │────────▶│ Role     │──▶ namespace      │
│  │ Group    │ Binding │          │                   │
│  │ ServiceAc│         │ Cluster  │──▶ cluster-wide   │
│  └──────────┘         │ Role     │                   │
│                       └──────────┘                   │
│                                                      │
│  Role = list of rules (verbs + resources)            │
│  Binding = connects subject to role                  │
└──────────────────────────────────────────────────────┘

Namespace-Level (Role + RoleBinding)

# Role: what actions are allowed
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list"]

---
# RoleBinding: who gets the role
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: dev-pod-reader
  namespace: production
subjects:
  - kind: Group
    name: developers
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Cluster-Level (ClusterRole + ClusterRoleBinding)

# ClusterRole: cluster-wide permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]

---
# ClusterRoleBinding: apply to all namespaces
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ops-node-viewer
subjects:
  - kind: Group
    name: operations
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

EKS Access Entries (New Way)

EKS now supports access entries (replacing aws-auth ConfigMap):

# Grant IAM user cluster access
$ aws eks create-access-entry \
    --cluster-name demo \
    --principal-arn arn:aws:iam::123456789012:user/developer \
    --type STANDARD

# Associate with K8s RBAC group
$ aws eks associate-access-policy \
    --cluster-name demo \
    --principal-arn arn:aws:iam::123456789012:user/developer \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy \
    --access-scope type=namespace,namespaces=production

Common Mistakes

Mistake Impact
Giving cluster-admin to all developers Any dev can delete anything
Using aws-auth ConfigMap for new clusters Deprecated — use access entries
Not auditing RBAC Permissions drift over time
Overly broad rules (* for verbs/resources) Violates least privilege

What’s Next?

Container security: Pod Security Standards.

You may also enjoy