2.4 Role-Based Access Control (RBAC): Roles & RoleBindings

Role-Based Access Control (RBAC): Roles & RoleBindings

Role-Based Access Control (RBAC) is the standard authorization engine in Kubernetes (rbac.authorization.k8s.io/v1). It regulates access to cluster resources based on the roles assigned to authenticated subjects (Users, Groups, or ServiceAccounts).

In this section, we examine namespace-scoped RBAC constructs: Role and RoleBinding.

---

1. RBAC Core Building Blocks: Verbs, Resources, & API Groups

Every RBAC policy rule is a tuple composed of four dimensions:

+-----------------------------------------------------------------------------------------+
|                                RBAC RULE SPECIFICATION                                  |
|                                                                                         |
|   apiGroups: ["apps"]     ---> Which API Group contains the resource?                   |
|                                ("" = core, "apps", "batch", "networking.k8s.io")        |
|                                                                                         |
|   resources: ["deployments"]-> Which object type or subresource is targeted?            |
|                                ("pods", "services", "pods/log", "pods/exec")             |
|                                                                                         |
|   resourceNames: ["web-app"]-> (Optional) Which specific named instances are allowed?  |
|                                                                                         |
|   verbs: ["get", "list"]  ---> Which operational actions are permitted?                |
|                                ("get", "list", "watch", "create", "update", "delete")  |
+-----------------------------------------------------------------------------------------+

API Groups Reference Table

Standard RBAC Verbs

• Read Operations: get (single item by name), list (collection of items), watch (stream real-time updates).
• Write Operations: create (new item), update (replace entire item), patch (delta update), delete (remove single item), deletecollection (batch delete).
• Wildcard: * represents all verbs or all resources.

---

2. Operational Subresources & Permissions

In Kubernetes, several crucial administrative operations are performed on subresources rather than top-level objects:

• pods/log: Allows reading container logs via kubectl logs.
• pods/exec: Allows creating interactive command execution sessions via kubectl exec (requires verb create).
• pods/portforward: Allows forwarding local network ports to a pod via kubectl port-forward (requires verb create).
• pods/status & deployments/status: Allows controllers to update status fields without modifying the desired spec.
• deployments/scale: Allows reading and modifying replica counts via kubectl scale.

# Example granting log inspection and exec without pod deletion privileges
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]
- apiGroups: [""]
  resources: ["pods/exec", "pods/portforward"]
  verbs: ["create"]

---

3. Roles: Defining Namespaced Permissions

A Role always belongs to a single namespace. It contains an array of rules defining what actions are permitted within that namespace.

Complete Role YAML Manifest

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: engineering
  name: developer-role
rules:
# Rule 1: Read pods, services, and view pod logs in core group
- apiGroups: [""]
  resources: ["pods", "pods/log", "services"]
  verbs: ["get", "list", "watch"]
# Rule 2: Execute commands inside pods
- apiGroups: [""]
  resources: ["pods/exec"]
  verbs: ["create"]
# Rule 3: Full control over deployments in apps group
- apiGroups: ["apps"]
  resources: ["deployments", "deployments/scale"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
# Rule 4: Access ONLY a specific ConfigMap named 'app-config'
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["get", "update"]

[!CAUTION] The resourceNames Limitation: resourceNames restricts access to existing specific instances (e.g., get, update, delete, patch). However, resourceNames cannot be used with create or list verbs. When creating a resource, the object does not yet exist; when listing resources, the API server cannot filter by name at the authorization layer.

---

4. RoleBindings: Binding Roles to Subjects

A RoleBinding grants the permissions defined in a Role (or a ClusterRole) to a list of Subjects within a specific namespace.

Subjects Can Be:

1. User: A named human or external identity.
2. Group: A group string (e.g., system:authenticated, frontend-devs).
3. ServiceAccount: A service account in the cluster (MUST specify namespace).

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-rolebinding
  namespace: engineering
subjects:
- kind: User
  name: alice
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: build-pipeline-sa
  namespace: engineering
roleRef:
  kind: Role
  name: developer-role
  apiGroup: rbac.authorization.k8s.io

[!IMPORTANT] Immutability of roleRef: Once a RoleBinding is created, its roleRef field is immutable. You cannot change which Role it points to. If you need to point to a different Role, you must delete the existing RoleBinding and create a new one.

---

5. Imperative RBAC Creation (CKA Speed Tactics)

During the CKA exam, always use kubectl create role and kubectl create rolebinding to generate manifests rapidly without syntax errors:

# 1. Create a Role with multiple verbs and resources in namespace 'dev'
kubectl create role pod-reader \
  --verb=get,list,watch \
  --resource=pods,pods/log \
  -n dev

# 2. Create a Role with apps group resources
kubectl create role deployment-admin \
  --verb=* \
  --resource=deployments,deployments/scale \
  -n dev

# 3. Create a Role with specific resourceNames
kubectl create role config-manager \
  --verb=get,update \
  --resource=configmaps \
  --resource-name=app-settings \
  -n dev

# 4. Create RoleBinding for a User
kubectl create rolebinding bind-pod-reader-user \
  --role=pod-reader \
  --user=alice \
  -n dev

# 5. Create RoleBinding for a Group
kubectl create rolebinding bind-pod-reader-group \
  --role=pod-reader \
  --group=frontend-engineers \
  -n dev

# 6. Create RoleBinding for a ServiceAccount
kubectl create rolebinding bind-pod-reader-sa \
  --role=pod-reader \
  --serviceaccount=dev:pipeline-sa \
  -n dev

---

6. Testing Authorization with kubectl auth can-i

Administrators can verify whether a subject has permission to execute specific actions using kubectl auth can-i:

# Check your own permissions
kubectl auth can-i create deployments --namespace dev
# Output: yes / no

# Impersonate a human user
kubectl auth can-i delete pods --namespace dev --as=alice

# Impersonate a ServiceAccount
kubectl auth can-i get secrets --namespace dev --as=system:serviceaccount:dev:pipeline-sa

# Impersonate a group
kubectl auth can-i list services --namespace dev --as=alice --as-group=dev-team

# Check subresource permissions specifically
kubectl auth can-i create pods/exec --namespace dev --as=alice

# List all permissions for a user in a namespace
kubectl auth can-i --list --as=alice --namespace=dev