Every kubectl command is an HTTP request to the API server, and the API server asks two questions before it does anything.

Who are you?

Authentication. Your kubeconfig carries a client certificate, a token, or a plugin that fetches one. The API server turns it into a username and a list of groups. Ask what it decided:

kubectl auth whoami

ATTRIBUTE   VALUE
Username    learner
Groups      [system:masters system:authenticated]

Pods have identities too: ServiceAccounts, next lesson. Users do not exist as objects; they are whatever the certificate or token says.

May you?

Authorization. With an identity in hand, the API server checks whether some rule allows this verb on this resource in this namespace. The rules are RBAC objects, the subject of the rest of this chapter. No rule, no action:

Error from server (Forbidden): pods is forbidden: User "dev" cannot list resource "pods" in API group "" in the namespace "citadel"

The message is precise: the verb (list), the resource (pods), the API group ("", the core group) and the namespace. Each of those is a field in the rule that would have allowed it.

Asking without doing

kubectl auth can-i delete pods -n citadel
kubectl auth can-i create deployments --as dev -n citadel

can-i sends the question and prints yes or no. --as asks on behalf of someone else, and works on any command: kubectl get pods --as dev runs the real request as dev. That is how you test a policy before the person it is for finds the gap.

Why you never see it

Your identity is in system:masters. That group is bound to cluster-admin, which allows everything everywhere. It is the emergency key, which is why the people and Pods you create in this chapter get something smaller.