Security, RBAC, and Production ReadinessLesson 6.1

Kubernetes RBAC: how to control who can do what in your cluster

RBAC resources, Role vs ClusterRole, RoleBinding vs ClusterRoleBinding, subjects (User, Group, ServiceAccount), verbs and resources, principle of least privilege, default ClusterRoles

RBAC Controls API Access

Kubernetes RBAC Subject Role Binding diagram

Role-Based Access Control (RBAC) defines what API operations (verbs) a subject can perform on which Kubernetes resources. Every kubectl command is an API call — RBAC controls which calls are allowed.

Role and RoleBinding (Namespace-Scoped)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: production
rules:
- apiGroups: [""]          # core API group
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: production
subjects:
- kind: ServiceAccount
  name: monitoring-agent
  namespace: monitoring
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRole vs Role

Use Role for namespace-scoped permissions. Use ClusterRole for cluster-wide resources (nodes, PersistentVolumes, namespaces themselves) or to reuse a role across many namespaces via ClusterRoleBinding. Kubernetes ships with built-in ClusterRoles: view, edit, admin, and cluster-admin.

# Check what a ServiceAccount can do
kubectl auth can-i list pods --as=system:serviceaccount:monitoring:monitoring-agent -n production