Kubernetes RBAC

In modern Kubernetes clusters, security is not optional — it’s foundational. One of the most powerful mechanisms Kubernetes provides for managing access control is Role-Based Access Control (RBAC).

This guide covers everything you need to know about RBAC, including roles, bindings, ClusterRoles, and how to properly use ServiceAccounts to secure workloads.

RBAC

Role-Based Access Control (RBAC) is a method of regulating access to computer or network resources based on the roles of individual users within an organization.

In Kubernetes, RBAC is used to authorize requests to the Kubernetes API server. You can define who can perform what action on which resources, providing fine-grained access control.

RBAC policies are defined using four key Kubernetes resources:

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding

Key Components

Role

Defines a set of permissions within a specific namespace.

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

ClusterRole

Similar to Role but can be used across all namespaces or for non-namespaced resources (like nodes).

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

RoleBinding

Grants the permissions defined in a Role or ClusterRole to a user or group within a specific namespace.

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

ClusterRoleBinding

Grants ClusterRole permissions cluster-wide to users, groups, or service accounts.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-read-access
subjects:
- kind: User
  name: admin-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-pod-reader
  apiGroup: rbac.authorization.k8s.io

Common Use Cases

ServiceAccounts

A ServiceAccount is a Kubernetes identity used by Pods to authenticate with the Kubernetes API. Every pod runs under a ServiceAccount, and it’s how you control programmatic access to the cluster for applications and controllers.

Kubernetes automatically creates a default ServiceAccount in every namespace:

kubectl get serviceaccounts -n default

You can define your own:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: dev

Bind a Role to a ServiceAccount

Let’s give our app running in a pod access to read pods in the dev namespace:

1. Create the ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: dev

2. Create the Role

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

3. Bind the Role to the ServiceAccount

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: bind-sa-to-role
  namespace: dev
subjects:
- kind: ServiceAccount
  name: my-app-sa
  namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

4. Use the ServiceAccount in a Pod

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  namespace: dev
spec:
  serviceAccountName: my-app-sa
  containers:
  - name: busybox
    image: busybox
    command: ["sh", "-c", "sleep 3600"]

Now, my-app pod can only perform the actions defined in the pod-reader role.

RBAC Authorization Flow

1. Authentication: Kubernetes verifies the user or service account identity.
2. Authorization: Kubernetes checks if the authenticated identity is authorized via RBAC rules.
3. Admission: If authorized, the request is admitted to the cluster.

Verifying Permissions

You can check permissions using:

kubectl auth can-i get pods --as jane -n dev
kubectl auth can-i create deployments --as system:serviceaccount:dev:my-app-sa -n dev

Best Practices for RBAC + ServiceAccounts

✅ Use dedicated ServiceAccounts for each workload.

✅ Avoid using the default ServiceAccount for production apps — it may have unwanted permissions.

✅ Grant least privilege: Only give the permissions an app or user absolutely needs.

✅ Regularly audit RBAC policies and bindings using tools like:

• rakkess – to visualize access
• kube-bench – to check against security benchmarks
• kubectl-who-can – see who has access to what

✅ Use ClusterRole and Role wisely:

• Use ClusterRole for non-namespaced or reusable permissions
• Use Role for namespace-scoped access

Summary

RBAC + ServiceAccounts give you fine-grained control over who can do what, and where, in your cluster. Combined correctly, they provide a powerful and secure access model for both human users and applications.