- TechOps Examples
- Posts
- How Kubernetes Calculates Access Permissions Using RBAC Rules
How Kubernetes Calculates Access Permissions Using RBAC Rules
Govardhana M K
July 08, 2025
TechOps Examples
Hey — It's Govardhana MK 👋
Welcome to another technical edition.
Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.
Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities and articles.
If you’re not a subscriber, here’s what you missed last week.
To receive all the full articles and support TechOps Examples, consider subscribing:
IN TODAY'S EDITION
🧠 Use Case
How Kubernetes Calculates Access Permissions Using RBAC Rules
🚀 Top News
👀 Remote Jobs
Ozone is hiring a DevOps Engineer
Remote Location: Worldwide
Ashby is hiring a Principal Site Reliability Engineer
Remote Location: EMEA
📚️ Resources
🛠️ TOOL OF THE DAY
git-graph - Command line tool to show clear git graphs arranged for your branching model.
🧠 USE CASE
How Kubernetes Calculates Access Permissions Using RBAC Rules
RBAC, or Role Based Access Control, is a critical concept every DevOps and Cloud Engineer must understand. It defines who can perform what actions on which resources.
Whether managing Kubernetes, cloud accounts, or CI/CD pipelines, it brings structure to access control, makes permissions predictable, and helps teams manage security at scale.
When a user, service account, or process tries to perform an action (verb) on a resource (like deployments) in a namespace, Kubernetes uses the following flow to determine if the action is allowed:
1. API Server Receives the Request
The request could be: GET /apis/apps/v1/namespaces/dev/deployments/nginx-deploy
It includes:
Verb: get
Resource: deployments
Namespace: dev
User identity
2. Authentication
The API server authenticates the request using one of the supported methods:
Client certificate authentication from the kube-apiserver configuration
Bearer tokens (including service account tokens)
OIDC tokens configured with an identity provider
For this example, the identity resolved is:User = [email protected]
3. Authorization
The RBAC authorizer processes the authenticated identity and evaluates it against:
RoleBindings and ClusterRoleBindings present in etcd.
Corresponding Roles or ClusterRoles defined in the cluster.
# Role allowing get on deployments in namespace dev
kind: Role
metadata:
namespace: dev
name: view-deployments
rules:
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list"]# RoleBinding assigning above role to user from techopsexamples
kind: RoleBinding
metadata:
name: deployment-reader
namespace: dev
subjects:
- kind: User
name: [email protected]
roleRef:
kind: Role
name: view-deployments
apiGroup: rbac.authorization.k8s.io4. Match Rules
The RBAC authorizer iterates through all applicable rules in the matched Roles or ClusterRoles. Checks whether any rule allows the verb on the resource in the given namespace
Each rule contains:
verbs (e.g., get, list)
resources (e.g., deployments)
apiGroups (e.g., apps)
resourceNames (optional, e.g., only certain deployments)
5. Decision
If any rule matches, the RBAC authorizer grants access
If no rule matches, the API server returns 403 Forbidden
Test the calculation:
kubectl auth can-i get deployments --as [email protected] --namespace dev