A new set of who-can-do-what questions.

Kubernetes layers five distinct security concerns on top of container-level hardening — RBAC controls who (or what) can perform which actions on which resources.

RBAC

who can act

Pod security

what privilege

Network

who can talk

Admission

what deploys

Secrets

how stored

least-privilege ci role

kind: Role
metadata: {name: deployer-role, namespace: checkout}
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "update", "patch"]
  # deliberately NOT: delete, secrets, other namespaces

kubectl auth can-i update deployments \
  --as=system:serviceaccount:checkout:ci-deployer  # yes
kubectl auth can-i delete secrets \
  --as=system:serviceaccount:checkout:ci-deployer  # no

Least privilege, concretely

Grant exactly the permissions needed, in exactly one namespace, and nothing more. A CI pipeline that only updates Deployments should never get cluster-admin "just in case."

A compromised, over-privileged ServiceAccount turns a contained incident into a full cluster compromise — least privilege is what keeps it contained.