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 = pareek.platform@gmail.com

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: pareek.platform@gmail.com roleRef: kind: Role name: view-deployments apiGroup: rbac.authorization.k8s.io 

4. 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 pareek.platform@gmail.com --namespace dev