Kubernetes RBAC: Least Privilege + Break-Glass Model

Kubernetes RBAC tends to live at one of two extremes in most organizations: either everyone is cluster-admin (“so we don’t get incidents”) or the policies are so strict that even a small intervention takes hours. A healthy model preserves least privilege while also guaranteeing you do not get “locked out” during an incident — meaning break-glass.

This guide breaks an RBAC design that actually works in the field into three pieces:

1. Role design (according to product/operations needs)
2. Identity integration (groups and ownership)
3. Break-glass (time-boxed, auditable emergency access)

1) The goal: clarify “who needs what?”

The most useful role buckets:

• Read-only: for observability and triage
• Namespace operator: for routine work like deploy/scale/log/pod restart
• Platform operator: for platform components like ingress, CNI, and storage
• Security: policy/audit-focused (write authority is usually limited)
• Break-glass: emergency only, time-bound

2) Start with a simple role design (sample)

The samples below are not “copy-paste” — they are templates that show which doors should be open or closed.

2.1 Read-only (within a namespace)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ns-readonly
  namespace: your-namespace
rules:
  - apiGroups: [""]
    resources: ["pods", "pods/log", "services", "endpoints", "configmaps", "events"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets", "daemonsets"]
    verbs: ["get", "list", "watch"]

2.2 Namespace operator (controlled write)

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ns-operator
  namespace: your-namespace
rules:
  - apiGroups: ["apps"]
    resources: ["deployments", "statefulsets"]
    verbs: ["get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch", "delete"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create"]

3) Identity integration: bind “groups”, not “users”

For sustainable RBAC, two rules:

1. In RoleBinding / ClusterRoleBinding, bind a group, not a user
2. Manage group membership on the IdP/IAM side (on/off and audit must live there)

A binding example:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ns-operator-binding
  namespace: your-namespace
subjects:
  - kind: Group
    name: platform:ns-operators
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: ns-operator
  apiGroup: rbac.authorization.k8s.io

4) Break-glass: time-boxed and auditable access

Break-glass is not a “secret cluster-admin”. The design intent is:

• Access can be opened when needed
• It is time-bound (something like 1–4 hours)
• Open/close decisions are auditable
• It can close itself once the incident ends

4.1 The most practical model: time-boxed membership in an IdP group

The lowest-friction model in enterprise environments:

• Define a group named something like platform:breakglass
• Grant this group “high but targeted” privilege via RBAC
• During an incident, add the user to this group with a time limit (time-boxed)
• IdP audit logs together with Kubernetes audit logs become jointly reviewable

4.2 Keep the break-glass role “targeted”

For example, instead of opening everything, scope it to operational needs:

• Interventions like kubectl rollout undo / scale
• Ingress/service corrections
• Platform actions like node cordon/drain (when needed)

5) Quick verification: “do I have this permission?”

Two commands save a lot of time during an incident:

kubectl auth can-i get pods -n your-namespace
kubectl auth can-i delete pod -n your-namespace

Put these checks in the runbook; they cut down on debate.

6) Operational checklist (short)

• Are RBAC roles defined according to product team needs?
• Is exec privilege separated and audited?
• Is the break-glass activation/deactivation procedure written down?
• Is “who approves?” defined for break-glass decisions?
• Are audit logs centralized, with a sufficient retention period?

Conclusion

RBAC is not a “constraint device” wielded by the security team; it is the platform’s safe operating mode. When least privilege and break-glass are designed together, security improves and, during incidents, teams do not produce extra damage because of “no access”.