RBAC and the Governance of Power

Doctrine

Authority is the highest-risk asset in a Kubernetes platform. RBAC is how you define, review, and constrain that authority.

Kubblai doctrine is strict: every privilege must have an owner and a reason.

Least privilege in the real world

Least privilege is not achieved by denying everything. It is achieved by understanding workflows and encoding only what is required—then iterating when reality changes.

A rigid RBAC posture that blocks operations will be bypassed. Bypass is worse than permission.

Break-glass access as an institution

Incidents require elevated access. If you do not design for it, engineers will create ad-hoc privilege in the worst moment.

Break-glass should be time-bound, audited, and rare.

Concrete example

A minimal read-only role for pods in a namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "events"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
subjects:
  - kind: ServiceAccount
    name: reader
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Review discipline

RBAC is code. Review it. Test it. Audit it. Treat accidental privilege escalation as a platform defect, not as a user mistake.

Institutional power should be visible.