The Point

RBAC (Role-Based Access Control) is a permissions model where you first define what roles can do, then assign roles to people. K8s uses RBAC to control who can perform which operations on which resources. CD tools use RBAC to control who can deploy to which environment.

Explanation

Three core elements of RBAC

Subject (who)  →  RoleBinding (assignment)  →  Role (what they can do)

• Subject: a user, group, or service account (programmatic identity)
• Role: defines a set of permissions (which operations on which resources)
• RoleBinding: assigns a Role to a Subject

Intuitive analogy: a Role is a job title (engineer, manager), a RoleBinding is the “appointment letter,” and the Subject is the person being appointed.

RBAC in Kubernetes

K8s RBAC controls “who can do what against the K8s API.”

Resources & Verbs

1rules:
2- apiGroups: [""]
3  resources: ["pods", "services"]   # resource types
4  verbs: ["get", "list", "watch"]   # allowed operations

Common verbs: get list watch create update patch delete

Role vs ClusterRole

 1# Role: only effective in the production namespace
 2kind: Role
 3metadata:
 4  namespace: production
 5  name: pod-reader
 6rules:
 7- apiGroups: [""]
 8  resources: ["pods"]
 9  verbs: ["get", "list"]
10
11---
12# RoleBinding: assign this Role to alice
13kind: RoleBinding
14metadata:
15  namespace: production
16subjects:
17- kind: User
18  name: alice
19roleRef:
20  kind: Role
21  name: pod-reader

Service Account: identity for programs

Programs running in pods (like a CD tool agent) are not people. K8s uses Service Accounts to give them an identity, then uses RoleBinding to control what they can do:

CD tool agent (Pod)
  → uses ServiceAccount: octopus-agent
  → RoleBinding → ClusterRole: deploy-permissions
  → can apply manifests, update Deployments

RBAC in CD Tools (Octopus)

The CD tool has its own RBAC layer, controlling “who can operate which project / environment”:

Engineer alice
  → belongs to Team: backend-team
  → Team is assigned Role: deployer (can deploy, cannot change project settings)
  → restricted to Environment: dev, staging (cannot touch prod)

Typical role hierarchy:

Knowledge Sugar

Why does K8s need RBAC?

The K8s API can do a lot – delete Pods, modify Secrets, scale Deployments. Without access control, anyone or any program that can connect to the cluster can do anything. RBAC lets you:

• Restrict devs to only operate within their own namespace
• Give CI/CD agents only manifest apply permission, not Secret deletion
• Give SRE cluster-level read access without prod write access

Principle of Least Privilege

The design philosophy behind RBAC: give each subject only the minimum permissions needed to do its job. If a CD tool agent only needs apply, do not give it delete.

For CD tool background, see the WarpCD vs Octopus Deploy post.