Someone deleted a RoleBinding used by human operators; apps keep running, but staff lose kubectl access. Why can workloads continue?
Select an answer to reveal the explanation.
Short Explanation
Apps and people wear different badges. Pods keep calling the API with their ServiceAccount token, so deleting a human RoleBinding does not stop those containers. Operators lose kubectl until their binding is restored—workloads do not need that human pass.
Full Explanation
When someone deletes a RoleBinding used by human operators, applications keep running because workloads authenticate with their ServiceAccount tokens, not with the humans’ user or group bindings. Staff lose kubectl access because their subject no longer matches an allow rule, but Pods continue calling the API with mounted or projected ServiceAccount credentials—apps and people wear different badges in the municipal cluster. Deleting a RoleBinding does not freeze the API server into a Pod-only read-only mode; authorization simply fails for subjects that lost their binding. Deployments do not embed a copy of RoleBindings inside each Pod sandbox at create time, so there is no cached human binding inside the container. Kubelet does not rewrite human users into system:nodes after binding deletion; node identity and human identity remain separate. Exam caveat: authorization is evaluated per request subject—always distinguish user/group bindings from ServiceAccount bindings when diagnosing “apps up, humans locked out.” Operational check: restore or recreate the operators’ RoleBinding/ClusterRoleBinding, verify kubectl works again, and confirm workload ServiceAccount bindings were untouched with kubectl get rolebinding,clusterrolebinding -A filtered to those ServiceAccounts.