Kubernetes RBAC (original) (raw)

Last Updated : 30 Apr, 2026

Kubernetes RBAC (Role‑Based Access Control) is a security mechanism used to manage permissions and control access to resources within a Kubernetes cluster. It ensures that users and applications can only perform actions they are authorized for, improving security and governance. Every request made to the Kubernetes API server passes through a sequence of three stages:

1. Authentication

This stage identifies **who is making the request. Kubernetes verifies identity through external methods rather than an internal user database.

• **Client Certificates: Verified by the cluster’s Certificate Authority (CA), typically for system components.
• **Service Account Tokens: Used by applications running inside the cluster’s Pods.
• **OIDC Tokens: Used for integration with external identity providers like Okta or Google.
• **Basic Auth: Username and password credentials, though rarely used due to security risks.
• **Identity Mapping: Successful authentication assigns a **Username, **UID, and **Groups to the request.

This stage determines **what the authenticated user is allowed to do by checking their specific permissions.

• **Policy Check: The server evaluates if the user has the rights to perform a specific verb (like get or create) on a specific resource.
• **RBAC: The standard authorization mode where permissions are defined in **Roles and assigned via **Bindings.
• **Rejection: If the user does not have an explicit permission for the action, the request is denied immediately.
• 3. Admission Control (Final Checks)

3. Admission Control

This is the final gatekeeper that enforces cluster-wide policies before the request is saved to **etcd.

• **Mutation: Some controllers modify the request, such as automatically adding default resource limits to a Pod.
• **Validation: Other controllers strictly verify the request, such as ensuring an image comes from a trusted registry.
• **Enforcement: This stage can reject requests even if the user is fully authorized, ensuring the cluster remains compliant with global configurations.
• **Persistence: Once cleared, the request is finally committed to the cluster’s state.

The Core Components of RBAC

RBAC is built upon four key API objects. They can be divided into two categories: defining _what can be done (Roles) and defining _who can do it (Bindings).

Roles and ClusterRoles

These objects define a set of permissions. The rules inside them are purely additive (there are no "deny" rules).

• **Role: A **Role grants permissions **within a single namespace. It contains rules that define a set of operations (verbs) on a set of resources.
• **ClusterRole: A **ClusterRole is just like a Role, but it is **not namespaced. It can be used for two main purposes:
• Granting permissions to cluster-scoped resources like Nodes, PersistentVolumes, or Namespaces themselves.
• Granting permissions to namespaced resources (like Pods or Deployments) but across **all namespaces in the cluster.

RoleBindings and ClusterRoleBindings: Granting Permissions

These objects "bind" a Role or ClusterRole to a subject (a user, group, or ServiceAccount), thereby granting them the permissions defined in that role.

• **RoleBinding: A **RoleBinding grants the permissions of a Role to a subject **within a specific namespace.9 You must have a RoleBinding in the same namespace as the Role it is granting.
• **ClusterRoleBinding: A **ClusterRoleBinding grants the permissions of a ClusterRole to a subject **across the entire cluster.

Subjects, Verbs, and Resources

• Subjects refer to the entity that performs an action. This can be a user, group, or service account.
• Verbs represent a subject's actions, such as 'get', 'create', and 'delete'.
• Resources represent the objects on which the actions can be performed, such as 'pods', 'services', 'and nodes.

Roles

In Kubernetes, a Role is a declaration of the operations that can be performed on a type of Kubernetes resource within a particular namespace. A simple example of a Role could be: You might need to do some pre-checks as below:

**Roles. yaml: This Role, named 'pod-reader', provides read-only access to Pods in the default namespace.

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader
rules:

• apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBindings

It actually grants the permissions defined in a Role to a user or set of users. It holds a list of subjects and a reference to the Role being granted. Here's an example of a RoleBinding:

**RoleBindings.yaml: In this RoleBinding, the 'pod-reader' Role is assigned to the user 'john'. This means that 'john' can now read Pods in the default namespace.

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default
subjects:

• kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
  roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoles

ClusterRole is similar to Role. However, while a Role is namespace-specific, a ClusterRole is not. This means that you can define permissions that apply across all namespaces in your cluster. Here's an example of a ClusterRole.

**ClusterRoles.yaml: In this ClusterRole, reading Nodes across the cluster is allowed.

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: node-reader
rules:

• apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "watch", "list"]

ClusterRoleBindings

Similar to a RoleBinding, a ClusterRoleBinding grants the permissions defined in a ClusterRole to a set of users, but it applies cluster-wide.

**ClusterRoleBindings.yaml: In this ClusterRoleBinding, the 'node-reader' ClusterRole is assigned to the user 'john', allowing 'john' to read Node information across the entire cluster.

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-nodes
subjects:

• kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
  roleRef:
  kind: ClusterRole
  name: node-reader
  apiGroup: rbac.authorization.k8s.io

RBAC Usage Scenarios

RBAC can be used in various scenarios to isolate team access, limit resource access, restrict operations, control admin access, and manage service account permissions.

**Isolating Team Access

• Suppose we have multiple teams working in the same Kubernetes cluster but on different applications.
• You can use RBAC to ensure that the developers from one group don't accidentally (or intentionally) modify the resources of another team.
• You do this by creating roles that have access to only specific namespaces and binding those roles to the respective teams.

**Limiting Resource Access

• We might have certain sensitive resources in your cluster, like secrets or config maps, that should only be accessed by certain individuals or applications.
• With RBAC, you can restrict access to these resources to only those who absolutely need it.

**Restricting Operations

• Not every user or application needs to perform every type of operation. For example, you might have a CI/CD pipeline that only needs to be able to create and delete pods, or a monitoring tool that only needs to be able to read the status of all resources.
• With RBAC, you can create roles that have only the necessary permissions and no more.

**Admin Access Control

• We might want to give certain users the ability to administer the cluster, but not all users should have this ability.
• With RBAC, you can create a ClusterRole that has administrative permissions and bind that role to only the appropriate users.

**Service Account Permissions

• Service accounts are a particular type of user that represent applications rather than humans. RBAC can be used to control what these service accounts can do, which is important for maintaining the security of your cluster.