How Do You Use kubectl auth can-i to Test RBAC Permissions?

Detailed Answer

kubectl auth can-i is the built-in tool for testing whether a subject is authorized to perform a specific action. It sends a SubjectAccessReview to the API server and returns yes or no.

Basic Syntax

kubectl auth can-i VERB RESOURCE [--namespace NAMESPACE]

Testing Your Own Permissions

# Can I create Deployments in the current namespace?
kubectl auth can-i create deployments

# Can I delete Pods in the production namespace?
kubectl auth can-i delete pods -n production

# Can I get nodes (cluster-scoped resource)?
kubectl auth can-i get nodes

# Can I create namespaces?
kubectl auth can-i create namespaces

# Can I do everything? (wildcard check)
kubectl auth can-i '*' '*'

The output is a simple yes or no. The exit code is 0 for allowed and 1 for denied, making it scriptable.

Impersonating Other Subjects

The --as flag is what makes this tool powerful for RBAC debugging. You can check permissions as any user, group, or ServiceAccount without switching contexts.

# Check as a specific user
kubectl auth can-i create pods --as=jane -n development

# Check as a ServiceAccount
kubectl auth can-i list secrets \
  --as=system:serviceaccount:production:app-sa \
  -n production

# Check as a group member
kubectl auth can-i delete deployments \
  --as=developer --as-group=team-backend \
  -n staging

The ServiceAccount format follows a strict pattern:

system:serviceaccount:<namespace>:<serviceaccount-name>

Listing All Permissions

The --list flag shows every permission a subject has in a namespace:

# List all your permissions in the default namespace
kubectl auth can-i --list

# List permissions for a ServiceAccount in a specific namespace
kubectl auth can-i --list \
  --as=system:serviceaccount:monitoring:prometheus \
  -n monitoring

Example output:

Resources                                       Non-Resource URLs   Resource Names   Verbs
pods                                            []                  []               [get list watch]
pods/log                                        []                  []               [get]
services                                        []                  []               [get list watch]
configmaps                                      []                  []               [get list watch]
selfsubjectaccessreviews.authorization.k8s.io   []                  []               [create]
selfsubjectrulesreviews.authorization.k8s.io    []                  []               [create]

Checking Subresources

Some resources have subresources (like pods/log, pods/exec, deployments/scale). You can check these with the --subresource flag:

# Can this ServiceAccount exec into pods?
kubectl auth can-i create pods \
  --subresource=exec \
  --as=system:serviceaccount:dev:debug-sa \
  -n dev

# Can this user view pod logs?
kubectl auth can-i get pods \
  --subresource=log \
  --as=jane \
  -n production

# Can this user scale deployments?
kubectl auth can-i update deployments \
  --subresource=scale \
  --as=jane \
  -n production

Using in Scripts and CI/CD

Because kubectl auth can-i returns proper exit codes, it integrates well into automation:

#!/bin/bash
# Pre-deployment permission check
SA="system:serviceaccount:ci-cd:deployer"
NS="production"

REQUIRED_PERMISSIONS=(
  "create deployments.apps"
  "update deployments.apps"
  "get services"
  "create services"
  "get configmaps"
  "create configmaps"
)

for perm in "${REQUIRED_PERMISSIONS[@]}"; do
  verb=$(echo "$perm" | awk '{print $1}')
  resource=$(echo "$perm" | awk '{print $2}')
  if ! kubectl auth can-i "$verb" "$resource" --as="$SA" -n "$NS" > /dev/null 2>&1; then
    echo "MISSING: $SA cannot $verb $resource in $NS"
    exit 1
  fi
done

echo "All required permissions verified."

SelfSubjectAccessReview API

Under the hood, kubectl auth can-i creates a SelfSubjectAccessReview (or SubjectAccessReview when impersonating). You can also submit these directly:

apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    namespace: production
    verb: create
    group: apps
    resource: deployments

kubectl create -f - <<EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
  resourceAttributes:
    namespace: production
    verb: create
    group: apps
    resource: deployments
EOF

Limitations

1. RBAC only — auth can-i checks authorization rules but does not evaluate admission controllers, OPA/Gatekeeper policies, or Pod Security Standards.
2. No deny visibility — since RBAC is additive, the tool cannot tell you which specific binding granted or denied access.
3. Impersonation requires permission — the user running --as must have the impersonate verb on users, groups, or serviceaccounts.

Common Debugging Workflow

When a user reports "access denied," follow this sequence:

# 1. Verify the denial
kubectl auth can-i create deployments --as=jane -n production
# no

# 2. List what they CAN do
kubectl auth can-i --list --as=jane -n production

# 3. Check existing bindings
kubectl get rolebindings -n production -o wide
kubectl get clusterrolebindings -o wide | grep jane

# 4. Inspect the role they should have
kubectl describe role deployment-manager -n production

# 5. Create or fix the binding
kubectl create rolebinding jane-deploy \
  --role=deployment-manager \
  --user=jane \
  -n production

# 6. Verify the fix
kubectl auth can-i create deployments --as=jane -n production
# yes