Interactive Explainer

🎯Key Takeaways

RBAC is a matrix of subject × resource × verb; define roles with minimal permissions and bind them to subjects

ServiceAccounts are Pod identities; tokens are automatically mounted and used for API authentication

Least-privilege access limits blast radius: never grant cluster-admin to application Pods

Audit logging and admission controllers enforce RBAC policy and prevent misuse

Kubernetes RBAC: Role-Based Access Control and Least-Privilege

RBAC controls who can do what in a Kubernetes cluster. Roles, ClusterRoles, RoleBindings, and ClusterRoleBindings implement least-privilege access.

~2 min read

Be the first to complete!

What you'll learn

RBAC is a matrix of subject × resource × verb; define roles with minimal permissions and bind them to subjects
ServiceAccounts are Pod identities; tokens are automatically mounted and used for API authentication
Least-privilege access limits blast radius: never grant cluster-admin to application Pods
Audit logging and admission controllers enforce RBAC policy and prevent misuse

Lesson outline

RBAC Basics

RBAC answers: who (Subject) can perform what action (Verb) on which resources (Object)?

Subjects: Users, ServiceAccounts, Groups.

Verbs: get, list, watch, create, update, patch, delete, etc.

Resources: pods, deployments, services, configmaps, secrets, etc.

Roles and ClusterRoles

Role: namespace-scoped set of permissions. E.g., "can get/list pods in namespace X".

ClusterRole: cluster-wide permissions. E.g., "can get/list nodes across all namespaces".

RoleBindings and ClusterRoleBindings

RoleBinding: attaches a Role to a Subject (user, SA, group) in a specific namespace.

ClusterRoleBinding: attaches a ClusterRole to a Subject cluster-wide.

ServiceAccounts and Pod Identity

Every Pod runs as a ServiceAccount. If not specified, it runs as "default".

ServiceAccounts are used for Pod-to-API authentication. The service account token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

Applications use this token to call the Kubernetes API (e.g., reading ConfigMaps, listing Pods).

Least-Privilege Practices

Default: create a restrictive role with only necessary permissions. Deny by default, allow exceptions.

Use namespace-level Roles (not ClusterRoles) when possible to limit blast radius.

Audit RBAC decisions: enable API audit logging to see who accessed what.

Key takeaways

RBAC is a matrix of subject × resource × verb; define roles with minimal permissions and bind them to subjects
ServiceAccounts are Pod identities; tokens are automatically mounted and used for API authentication
Least-privilege access limits blast radius: never grant cluster-admin to application Pods
Audit logging and admission controllers enforce RBAC policy and prevent misuse

🧠Mental Model

💡 Analogy

RBAC is like a building access control system. Subjects (people) have badges (tokens). Roles are job titles (e.g., "janitor" can access storage rooms). RoleBindings assign job titles to people. ClusterRoles are company-wide job titles. ServiceAccounts are like a Pod's corporate identity card.

⚡ Core Idea

RBAC is a matrix of subject × resource × verb. Roles define permissions templates. RoleBindings grant those permissions to subjects.

🎯 Why It Matters

Least-privilege access limits blast radius when credentials are compromised. In multi-tenant clusters, RBAC prevents one team from accessing another's resources.

Ready to see how this works in the cloud?

Switch to Career Paths for structured paths (e.g. Developer, DevOps) and provider-specific lessons.

View role-based paths

Discussion

Questions? Discuss in the community or start a thread below.

Join Discord

In-app Q&A

ServiceAccounts and Pod Identity

Every Pod runs as a ServiceAccount. If not specified, it runs as "default".

ServiceAccounts are used for Pod-to-API authentication. The service account token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token.

Applications use this token to call the Kubernetes API (e.g., reading ConfigMaps, listing Pods).