TL;DR: RBAC grants permissions by assigning access rights to roles rather than individual users. Because Kubernetes lacks a built-in user management system, permissions must be explicitly defined using Roles and bound to external identities or ServiceAccounts.

In system security, access control relies on two fundamental questions:

  1. Authentication: Who are you?
  2. Authorization: What are you allowed to do, and at what level?

RBAC (Role-Based Access Control) is an authorization model that manages access based on predefined roles rather than individual user accounts. Instead of assigning specific permissions directly to each user, permissions (such as read, write, update, and delete) are assigned to a Role (e.g., admin, developer, viewer). Users are then assigned to one or more roles, simplifying security management across the system.

Kubernetes RBAC

Kubernetes does not have a built-in user management system with usernames and passwords. Instead, it relies on external authentication mechanisms—most commonly X.509 client certificates for human administrators or ServiceAccounts for automated workloads.

Once a user or service is authenticated, Kubernetes uses RBAC (Role-Based Access Control) to handle Authorization. To set up RBAC in Kubernetes, you define two main components:

  1. Role (or ClusterRole): Defines what operations (verbs like get, list, create) can be performed on which resources (like pods, services).
  2. RoleBinding (or ClusterRoleBinding): Connects that Role to a specific subject (a certificate user, group, or ServiceAccount).

example

1. Define the permissions (WHAT can be done)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev-team
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

2. Assign the permissions to a user (WHO can do it)

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-binding
  namespace: dev-team
subjects:
- kind: User
  name: rathwjj
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Note:

A “user” in Kubernetes RBAC is completely separate from user accounts managed inside applications running within containers. K8s RBAC strictly controls access to the Kubernetes API, not your application’s database or business logic.

While automated pipelines (such as GitOps controllers or CI/CD runners) perform most deployment tasks in production, RBAC remains essential. Automated systems require tightly scoped ServiceAccounts with minimal RBAC permissions to interact with the cluster securely.

Another common access control model is ABAC (Attribute-Based Access Control). Unlike RBAC, which grants access based on static roles, ABAC evaluates dynamic attributes—such as the user’s department, time of day, IP address, or resource sensitivity—to make real-time access decisions. While ABAC offers finer-grained control, RBAC remains the simpler and standard model for Kubernetes cluster security.

Back to Certified Cloud Native Platform Engineering Associate Preparation