kubectl auth can-i: Usage, Options & Common CI Errors

Ask the API server whether you are allowed to do something.

kubectl auth can-i queries the SelfSubjectAccessReview API to tell you whether the current credentials may perform a verb on a resource. It is the right preflight to fail a CI job early with a clear RBAC message instead of a cryptic Forbidden mid-deploy.

What it does

kubectl auth can-i VERB RESOURCE answers yes/no (and exits non-zero on no with --quiet) for the active user. -n scopes to a namespace; --list dumps everything you can do; --as / --as-group impersonate another subject to test their permissions (if you may impersonate).

Common usage

kubectl auth can-i create deployments -n prod
kubectl auth can-i '*' '*' --all-namespaces       # am I cluster-admin?
kubectl auth can-i list secrets -n prod --quiet   # exit code only
kubectl auth can-i create pods --as=system:serviceaccount:ci:deployer -n prod
kubectl auth can-i --list -n prod

Common errors in CI

A can-i "yes" is not an absolute guarantee: admission webhooks, quotas, and field-level policy can still reject the real request, so can-i checks RBAC only. Conversely a "no" in CI often means the service account token mounted in the runner is not the identity you expected - confirm with kubectl auth whoami. Subresources need explicit naming (pods/log, deployments/scale), so can-i get pods says nothing about reading logs. Use --quiet in scripts to gate on the exit code rather than parsing the "yes"/"no" string.

Related guides