Skip to main content
In this lesson, we explore how to troubleshoot Kubernetes RBAC permissions using the “kubectl auth can-i” command. Previously, we discussed commands for troubleshooting common resources such as pods, deployments, and services. Now, we’ll shift our focus to analyzing permissions around roles, role bindings, and service accounts within the RBAC framework. The basic command structure is:
The image shows a terminal window with a command prompt labeled "controlplane" and a blinking cursor, ready for input.
This command is used to determine whether a given subject is permitted to perform a specific action on a cluster resource. The command follows this sequence:
  1. Specify the verb (e.g., list, get, update, patch, delete).
  2. Specify the target resource.
  3. Optionally, specify the namespace.
For example, to verify if you can list pods in the “monitoring” namespace, run:
If the output is “yes,” it indicates that the current user has the required permission.
By default, if no user or service account is explicitly mentioned, the command checks permissions for the current authenticated user.
To confirm your current user, execute:
The output might look like this:
In the example above, the current user is “kubernetes-admin,” which typically has full authorization within the cluster.

​
Analyzing Role and RoleBinding Permissions

To examine the permissions assigned to subjects other than the current user, begin by listing the roles in a specific namespace. For instance, if you have a role named “pod-reader” in the default namespace, fetch its details using:
This output will show that the “pod-reader” role is permitted to perform verbs such as “get,” “watch,” and “list” on the “pods” resource. Next, inspect the role bindings with:
The output might appear as follows:
To view detailed information for the “read-pods” role binding, run:
This YAML output confirms that the “read-pods” role binding associates the “pod-reader” role with a user named Jane and with the default service account. As a result, Jane is allowed to get, watch, and list pods in the default namespace. You can use the “kubectl auth can-i” command to verify these permissions. For example, to check if Jane can get pods:
A response of “yes” confirms the permission. Conversely, if you attempt a verb that Jane is not authorized for, such as delete:
The output will be “no”. Similarly, when verifying permissions for service accounts, include the “system:serviceaccount” prefix with the namespace. To check if the default service account can delete pods, use:
The response will indicate that deleting pods is not allowed. The “kubectl auth can-i” command is incredibly useful when managing multiple service accounts, roles, and role bindings. It helps clarify why a particular subject can or cannot perform specific actions on a resource.

​
Increasing Verbosity for Detailed Debugging

For advanced troubleshooting, you can augment the “kubectl auth can-i” command with increased verbosity using the “—v=10” flag. This provides a detailed breakdown of the RBAC evaluation process. For instance:
The verbose output includes detailed messages, explaining why the action is permitted or denied. You might see log entries that look like this for an allowed action:
And for a denied “delete” action:
Remember that Kubernetes RBAC is allow-only: any action is implicitly denied unless a role or role binding explicitly grants permission.
Using increased verbosity with “—v=10” can be a potent tool for debugging complex RBAC configurations and ensuring that your cluster’s authorization rules are correctly enforced.

​
Summary Table

This guide should help you effectively troubleshoot and understand your Kubernetes RBAC permission settings using the “kubectl auth can-i” command. For further details, refer to the official Kubernetes Documentation.

Watch Video