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

> kubectl auth can-i checks whether the current credentials may perform an action. RBAC preflight in CI, --list and --as, and the false-negative traps.

Source: https://latchkey.dev/learn/command-reference/kubectl-auth-can-i  
Updated: 2026-06-25

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

```Terminal
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.

## 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.

```Terminal
# 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
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

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

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 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.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt