visit
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 --list
Resources 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]
$ kubectl auth can-i get pods -n default
yes
$ kubectl auth can-i get pods -n kube-system
yes
$ echo $?
0
if ! kubectl auth can-i create secrets; then
echo >&2 "You cannot create secrets. Please contact your k8s admin."
exit 4
fi
# etc.
Want more? Curious what happens when an unprivileged
ServiceAccount
is involved? Then check out the video and learn you some access control!Previously published at