Kubernetes RBAC
RBAC controls what actions authenticated identities can perform inside the cluster.
Once IAM has authenticated a user, RBAC (Role-Based Access Control) decides what they may do inside Kubernetes. RBAC is standard Kubernetes — EKS doesn't change it.
The four objects
- Role — permissions within a single namespace.
- ClusterRole — permissions cluster-wide.
- RoleBinding — grants a Role to a user/group in a namespace.
- ClusterRoleBinding — grants a ClusterRole cluster-wide.
Tying it to IAM
An access entry or aws-auth mapping puts an IAM identity into a Kubernetes group; a RoleBinding then grants that group permissions. This is how you give, say, a developer read-only access to one namespace.
Example
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: dev
subjects:
- kind: Group
name: dev-team
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioWhen to use it
- A platform team creates a developer Role in each namespace that allows pods and logs access but prevents secret reads, enforcing least privilege for all engineers.
- A security team audits ClusterRoleBindings to find any subjects bound to cluster-admin and replaces them with narrower roles.
- A CI/CD pipeline uses a dedicated ServiceAccount bound to a Role with only deploy permissions, preventing the pipeline from accessing unrelated namespaces.
More examples
Create a namespace-scoped Role
A Role that lets developers list pods, read logs, and update deployments within a single namespace without access to secrets or cluster resources.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
namespace: team-a
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "services"]
verbs: ["get", "list", "watch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "update", "patch"]Bind Role to IAM-mapped user
Binds the developer Role to user 'alice', whose name comes from the aws-auth ConfigMap mapping of her IAM identity.
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: developer-binding
namespace: team-a
subjects:
- kind: User
name: alice # matches aws-auth username
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.ioAudit RBAC permissions for a user
Uses kubectl's impersonation to check what actions a specific user can perform, validating RBAC rules without requiring the user to log in.
kubectl auth can-i list pods \
--namespace team-a \
--as alice
kubectl auth can-i get secrets \
--namespace team-a \
--as alice
Discussion