kubectl auth can-i: Usage, Options & CI Errors
Ask the API server whether you are allowed to do something.
kubectl auth can-i queries the cluster's RBAC to tell you yes or no for an action, without performing it. In CI it is the preflight that turns a confusing mid-deploy Forbidden into an explicit, early failure.
What it does
kubectl auth can-i VERB RESOURCE returns yes/no (and exits 0/1) for whether the current identity may perform that action, optionally scoped with -n or a resource name. --as / --as-group impersonate another subject to test their access; can-i --list dumps everything you can do. auth reconcile applies RBAC objects, ensuring rules are complete.
Common usage
kubectl auth can-i create deployments -n prod
kubectl auth can-i '*' '*' # am I admin here?
kubectl auth can-i list secrets --as=system:serviceaccount:ci:deployer
kubectl auth can-i --list -n prodCommon errors in CI
Run can-i as a preflight so the job fails clearly instead of dying halfway with "Error from server (Forbidden): ... cannot create resource". The most useful pattern: kubectl auth can-i create deployments -n prod --as=system:serviceaccount:ci:deployer to verify the CI service account before the deploy step. "forbidden: User ... cannot impersonate" on the --as form means your own identity lacks impersonate rights, not that the target lacks the permission. A "no" exit (1) under set -e will abort the script, so branch on it deliberately.
Using this in CI
A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods
# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info
# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes