kubectl auth can-i

kubectl auth can-i

Auditing Permissions with kubectl auth can-i

kubectl 5,150 auth can-i asks the API server's authorizer directly (a SelfSubjectAccessReview, or a SubjectAccessReview when you impersonate), so it answers with the cluster's real rules. --list prints everything a subject may do in a namespace, and --as with the system:serviceaccount: form audits a ServiceAccount. Here is Jenkins 8,793 ' account from Connecting Jenkins before it gets any rights in booknest:

What Jenkins' ServiceAccount may do, in its namespace and in BookNest'sYAML

SA=system:serviceaccount:jenkins:jenkins
kubectl auth can-i --list --as=$SA -n jenkins | grep -v -e selfsubject -e '^ ' \
  | cut -c1-48,105-
kubectl auth can-i create pods --as=$SA -n jenkins
kubectl auth can-i patch deployments --as=$SA -n booknest

Output

Resources                                       Verbs
pods/exec                                       [create delete get list patch update watch]
pods                                            [create delete get list patch update watch]
pods/log                                        [get list watch]
clustertrustbundles.certificates.k8s.io         [get list watch]
secrets                                         [get]
events                                          [watch]
yes
no

The list is the Role from Connecting Jenkins plus the rules every authenticated identity gets, and nothing in booknest. Put such checks in CI as assertions that fail the build when a change widens access.

MENU