# kubectl auth can-i: Command Reference for CI/CD

> Reference for kubectl auth can-i: check whether the current credentials may perform an action before attempting it, a clean RBAC preflight for CI deploy jobs.

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

Preflight RBAC: confirm CI may do a thing before it tries.

kubectl auth can-i answers whether the current credentials are allowed to perform a verb on a resource, without performing it. It is a clean RBAC preflight for a deploy job so a permission gap fails early with a clear message. This reference covers it.

## Common flags and usage

- auth can-i <verb> <resource>: yes/no for the current user
- auth can-i <verb> <resource> -n <ns>: scope to a namespace
- --list: list every permission the current credentials hold
- --as <user> / --as-group: check on behalf of another subject
- Exits 0 for yes, non-zero for no (script-friendly)

## Example

```shell
for verb in get create patch; do
  kubectl auth can-i $verb deployments -n prod >/dev/null \
    || { echo "missing $verb on deployments"; exit 1; }
done
```

## In CI

Run can-i checks at the top of a deploy job so a missing RBAC binding fails with a precise message instead of a confusing Forbidden mid-deploy. The exit code is scriptable; auth can-i --list documents exactly what the pipeline service account can do.

## 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: Command Reference for CI/CD?

kubectl auth can-i answers whether the current credentials are allowed to perform a verb on a resource, without performing it. It is a clean RBAC preflight for a deploy job so a permission gap fails early with a clear message. This reference covers it.

### In CI?

Run can-i checks at the top of a deploy job so a missing RBAC binding fails with a precise message instead of a confusing Forbidden mid-deploy. The exit code is scriptable; auth can-i --list documents exactly what the pipeline service account can do.

---

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