Scheduling & Securitycritical

RBAC

Role-Based Access Control restricts who (users, ServiceAccounts) can do what (verbs) on which resources in Kubernetes.

Memory anchor

RBAC = a building keycard system. Role = 'this card opens doors 1-5.' RoleBinding = 'give this card to Alice.' ClusterRole = 'master key for ALL floors.' The default ServiceAccount is like giving every new employee the janitor's master key — always issue specific keycards instead.

Expected depth

Four objects: Role (namespaced, defines permissions), ClusterRole (cluster-wide), RoleBinding (grants Role to subjects in a namespace), ClusterRoleBinding (grants ClusterRole cluster-wide). Subjects: User, Group, ServiceAccount. Verbs: get, list, watch, create, update, patch, delete. Pods use their ServiceAccount's token to authenticate to the API server. Default ServiceAccount in each namespace — avoid using it, create dedicated per-workload ServiceAccounts.

Deep — senior internals

RBAC is additive — no deny rules. If a subject has no binding for a resource, access is denied (default deny). ClusterRole can be bound to a namespace via RoleBinding — useful for granting cluster-wide role definitions (like view) to specific namespaces. Aggregated ClusterRoles (aggregationRule) automatically include rules from ClusterRoles with matching labels — used to extend built-in roles. ServiceAccount token projection: projected volumes with expiry (short-lived tokens, rotated automatically). Workload identity (EKS IRSA, GKE Workload Identity) links Kubernetes ServiceAccounts to cloud IAM roles — the pod gets short-lived cloud credentials without storing secrets. Audit logs capture every API call with user, resource, verb — critical for security forensics.

🎤Interview-ready answer

RBAC is Kubernetes' authorization layer. You define what a ServiceAccount (or user) can do via Role + RoleBinding. Always create dedicated ServiceAccounts per workload with minimal permissions — don't use the default ServiceAccount. For cross-namespace access, use ClusterRole + RoleBinding scoped to the target namespace. For cloud resource access from pods, use workload identity (IRSA on EKS) rather than static credentials. Audit RBAC regularly — overly permissive roles are the most common K8s security misconfiguration.

Common trap

Mounting the default ServiceAccount token gives the pod access to the Kubernetes API with the default SA's permissions — which is often more than needed. Set automountServiceAccountToken: false on pods that don't need API access, and use dedicated minimal-permission SAs for those that do.