kubectl get pods fails for a clerk using a kubeconfig whose client certificate no longer matches any known user, while a coworker with a valid user but no RoleBinding sees Forbidden. How do these failures differ?
Select an answer to reveal the explanation.
Short Explanation
First the front desk has to recognize who you are; then security checks what you are allowed to touch. Bad kubeconfig identity never gets past recognition. A known user with no RoleBinding is recognized and then told no.
Full Explanation
kubectl get pods failing for a clerk whose kubeconfig client certificate no longer matches any known user is an authentication failure: the API cannot establish identity. A coworker with a valid user but no RoleBinding who sees Forbidden authenticated successfully and then failed authorization. These failures differ at the authn versus authz boundary, which matters when municipal IT decides whether to renew certificates or fix RBAC bindings.
Treating both as authorization failures—and claiming authentication only applies to ServiceAccounts—fails because human users authenticate too, and bad client certificates never reach RBAC as that user. Treating both as authentication failures—and claiming Forbidden always means the TLS handshake failed—fails because Forbidden is the standard authorization denial after identity is known. Blaming NetworkPolicy for the clerk and an admission webhook for the coworker misattributes kubectl API errors to data-plane and admission mechanisms that do not explain these two kubeconfig symptoms.
Exam caveat: expired OIDC tokens can present as authn errors differently from x509 problems, but they remain distinct from RBAC Forbidden. Operational check: replace or renew the clerk's client certificate in kubeconfig; create a RoleBinding for the coworker; retest kubectl get pods for each person and confirm only the intended failure mode is gone.