Stretching as far back as version 1.8 (in September of 2017), Kubernetes has supported a fine-grained access control mechanism called RBAC. Nothing gets done via the Kubernetes API that isn’t governed by some sort permission or another, and there are a lot of them.
Couple that with per-deployment service accounts, named user access credentials, and project-specific namespaces, and you’ve got the makings of a complex authorization scenario.
At times, you’ll wonder precisely which permissions you, or a service account you use, have been granted – that’s when you should reach for
kubectl auth can-i.
To see everything you can do:
$ kubectl auth can-i --listResources Non-Resource URLs Resource Names Verbs *.*   [*] [*]  [*] selfsubjectaccessreviews.authorization.k8s.io   [create] selfsubjectrulesreviews.authorization.k8s.io   [create] [/api/*]  [get] [/api]  [get] [/apis/*]  [get] [/apis]  [get] [/healthz]  [get] [/healthz]  [get] [/livez]  [get] [/livez]  [get] [/openapi/*]  [get] [/openapi]  [get] [/readyz]  [get] [/readyz]  [get] [/version/]  [get] [/version/]  [get] [/version]  [get] [/version]  [get]
You can also just ask the API to see if a given action is allowed:
$ kubectl auth can-i get pods -n default yes $ kubectl auth can-i get pods -n kube-system yes $ echo $? 0
These commands exit 0 if such access would be allowed, and 1 if not, making them handy for use inside of shell scripts or other automation:
if ! kubectl auth can-i create secrets; then echo >&2 "You cannot create secrets. Please contact your k8s admin." exit 4 fi # etc.
Check out the Video!
Want more? Curious what happens when an unprivileged
ServiceAccount is involved? Then check out the video and learn you some access control!