kubectl auth can-i checks whether an identity may perform a specified Kubernetes API action. It returns a simple yes or no, making it useful for verifying Role and RoleBinding configuration before troubleshooting access. section 3.1.1
Use the command to test common authorization scenarios:
- Check a user's permission: kubectl auth can-i get pods -n default --as carol. section 3.1.1
- Test a denied action with the same identity: kubectl auth can-i delete pods -n default --as carol. section 3.1.1
- List all permissions available to the current identity with kubectl auth can-i --list. section 3.1.2
- Test a ServiceAccount by using its RBAC username: kubectl auth can-i list pods --as system:serviceaccount:default:nomount-sa. section 3.3
Verify a RoleBinding
After binding the pod-reader role to user carol, run kubectl auth can-i get pods -n default --as carol and expect yes. Testing delete separately can confirm that the binding grants only the intended action. section 3.1.1
$ kubectl auth can-i -h
Check whether an action is allowed.
VERB is a logical Kubernetes API verb like 'get', 'list', 'watch',
'delete', etc. TYPE is a Kubernetes resource.
Shortcuts and groups will be resolved. NONRESOURCEURL is a
partial URL that starts with "/". NAME is the name of a
particular Kubernetes resource.
Examples:
# Check to see if I can create pods in any namespace
kubectl auth can-i create pods --all-namespaces
# Check to see if I can list deployments in my current namespace
kubectl auth can-i list deployments.apps
# Check to see if I can do everything in my current namespace
("*" means all)
kubectl auth can-i '*' '*'
# Check to see if I can get the job named "bar" in namespace "foo"
kubectl auth can-i list jobs.batch/bar -n foo
# Check to see if I can read pod logs
kubectl auth can-i get pods --subresource=log
# Check to see if I can access the URL /logs/
kubectl auth can-i get /logs/
# List all allowed actions in namespace "foo"
kubectl auth can-i --list --namespace=foo
Review the command help for resource shortcuts, API groups, namespaces, subresources, wildcards, and additional authorization-check examples. section 3.1.1
