kubectl auth can-i: the answer is this question

The command is the question

can-i prints yes or no for one check. The verb, the resource, the namespace flag, and the subject after --as are the question. A yes is permission for that question. It is not a list of every verb the subject holds.

If the paste dropped the command and kept only yes, write “question not recorded.” A bare yes cannot be filed as a permission.

A different noun is a different question

Yes for listing pods in one namespace does not say anything about secrets, about another namespace, or about cluster-scoped resources. Those are checks you did not run. Write “not asked” instead of copying the yes.

This page does not grant permissions and does not try verbs you have not already recorded. It only stops one answer from being widened.

What to write down

File the full command, the yes or no, and the context if you have it. When you mention a permission, repeat the verb and the namespace from that command. Do not summarize several checks as one yes.

Lab: yes for pods read as yes for secrets

A lab note shows: kubectl auth can-i list pods -n team-a --as=system:serviceaccount:team-a:ci-bot, and the output yes. A draft says ci-bot can read secrets in kube-system because the account is allowed in team-a.

The note quotes yes for list pods in team-a for that subject. Secrets were not in the command. kube-system was not in the command. Those checks stay unasked. The draft sentence is removed.

command: kubectl auth can-i list pods -n team-a --as=system:serviceaccount:team-a:ci-bot
output: yes
secrets: not asked
kube-system: not asked
write: yes for that one question
not: secrets in kube-system