kubectl auth can-i

When to Use kubectl auth can-i

kubectl auth can-i checks whether a specific action is permitted under the cluster's RBAC (Role-Based Access Control) policies. It is the primary tool for verifying permissions, debugging access issues, and auditing security configurations.

Basic Permission Checks

# Can I create deployments?
kubectl auth can-i create deployments
# yes

# Can I delete pods in production?
kubectl auth can-i delete pods -n production
# no

# Can I view secrets?
kubectl auth can-i get secrets
# yes

The command outputs yes or no and sets the exit code accordingly (0 for yes, 1 for no), making it ideal for scripting.

Checking Other Users' Permissions

Use --as to impersonate another user (requires impersonation permissions):

# Check a specific user
kubectl auth can-i create deployments --as=jane
kubectl auth can-i delete pods --as=john -n production

# Check a group
kubectl auth can-i create namespaces --as=ann --as-group=developers

Service Account Permission Checks

Service accounts use the format system:serviceaccount:<namespace>:<name>:

# Check if a service account can list pods
kubectl auth can-i list pods --as=system:serviceaccount:default:my-app

# Check if the default service account can get secrets
kubectl auth can-i get secrets --as=system:serviceaccount:kube-system:default

# Check if a CI service account can create deployments
kubectl auth can-i create deployments --as=system:serviceaccount:ci:deployer -n production

Listing All Permissions

The --list flag shows all allowed actions:

# All permissions in the current namespace
kubectl auth can-i --list
# Resources                          Non-Resource URLs   Resource Names   Verbs
# *.*                                []                  []               [*]
# selfsubjectaccessreviews.authorization.k8s.io  []      []               [create]

# All permissions for a service account
kubectl auth can-i --list --as=system:serviceaccount:default:my-app -n default

# Cluster-wide permissions
kubectl auth can-i --list --all-namespaces

Subresource Checks

Some operations target subresources like logs, exec, or portforward:

# Can I view pod logs?
kubectl auth can-i get pods --subresource=log

# Can I exec into pods?
kubectl auth can-i create pods --subresource=exec

# Can I port-forward?
kubectl auth can-i create pods --subresource=portforward

# Can I view container metrics?
kubectl auth can-i get pods --subresource=metrics

RBAC Debugging Workflow

When a user reports "permission denied," follow this workflow:

# 1. Reproduce the exact action
kubectl auth can-i create deployments --as=jane -n staging
# no

# 2. Check what permissions the user has
kubectl auth can-i --list --as=jane -n staging

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

# 4. Inspect the role
kubectl describe role developer -n staging
kubectl describe clusterrole developer

# 5. Fix by creating or updating the binding
kubectl create rolebinding jane-developer \
  --role=developer \
  --user=jane \
  -n staging

CI/CD Permission Validation

Validate that a deployment service account has necessary permissions before running the pipeline:

#!/bin/bash
SA="system:serviceaccount:ci:deployer"
NS="production"

REQUIRED_PERMS=(
  "create deployments"
  "update deployments"
  "get services"
  "create services"
  "get configmaps"
  "create configmaps"
)

for perm in "${REQUIRED_PERMS[@]}"; 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; then
    echo "MISSING: $SA cannot $VERB $RESOURCE in $NS"
    EXIT=1
  fi
done

[ -z "$EXIT" ] && echo "All permissions verified." || exit 1

Non-Resource URL Checks

Some permissions apply to non-resource URLs (API paths rather than resources):

# Can I access the healthz endpoint?
kubectl auth can-i get /healthz

# Can I access metrics?
kubectl auth can-i get /metrics

Security Auditing

Use can-i to audit overly broad permissions:

# Check who can delete namespaces (a dangerous permission)
for user in alice bob charlie; do
  result=$(kubectl auth can-i delete namespaces --as="$user" 2>/dev/null)
  echo "$user: $result"
done

# Check if anyone can access secrets
kubectl auth can-i get secrets --as=system:serviceaccount:default:default -n production

Regular audits using can-i help enforce the principle of least privilege and catch permission drift over time.