Are You Using “kubectl auth can-i”?. The Underutilized Command You Need to Know

In the Kubernetes realm, ensuring the security and proper assignment of roles and permissions within a cluster is paramount. Kubernetes administrators often face the challenge of verifying whether a particular user or service account has the necessary permissions to act. This is where the often underutilized ‘kubectl auth can-i’ command comes into play, offering a straightforward way to check access rights without executing the actual operation.

The Power of ‘kubectl auth can-i’: 

The ‘kubectl auth can-i’ command is a part of the Kubernetes command-line tool that allows you to query the Kubernetes RBAC (Role-Based Access Control) to check if a user, group, or service account can perform a specific action. It’s an invaluable command for DevOps engineers and Kubernetes administrators to verify and troubleshoot permissions.

Basic Usage: To use ‘kubectl auth can-i’, you simply follow the syntax:

kubectl auth can-i <verb> <resource>

For example, if you want to check if your current user can create deployments in the default namespace, you would use:

kubectl auth can-i create deployments

Checking Permissions for a Service Account: 

Let’s say you have a service account named ‘monitoring-sa’ in the ‘monitoring’ namespace, and you want to check if it has permission to list endpoints (which is crucial for service discovery in monitoring solutions). You could run:

kubectl auth can-i list endpoints --namespace monitoring --as system:serviceaccount:monitoring:monitoring-sa

This command will return ‘yes’ if the service account has the required permissions, or ‘no’ if it does not.

Advanced Examples: 

You can also use ‘kubectl auth can-i’ to check permissions for verbs that are not part of the standard Kubernetes API. For instance, if you’re using Custom Resource Definitions (CRDs), you can check permissions for these as well:

kubectl auth can-i create mycustomresources.mydomain.com --as system:serviceaccount:monitoring:monitoring-sa

Besides checking permissions for standard Kubernetes API actions and Custom Resource Definitions (CRDs), ‘kubectl auth can-i’ can be used to verify permissions for specific API subresources. Subresources like ‘status’ and ‘scale’ are important for certain operations and can have separate permissions from the main resource.

For instance, if you want to check if a service account has the permission to update the status of a deployment, which is a common requirement for continuous deployment setups, you could use:

kubectl auth can-i update deployments/status --namespace production --as system:serviceaccount:default:deploy-sa

This command will check if the ‘deploy-sa’ service account in the ‘default’ namespace has permission to update the status subresource of deployments in the production namespace.

Another advanced use case is checking permissions for pod exec, which is crucial for debugging:

kubectl auth can-i create pod/exec --namespace development --as system:serviceaccount:default:debug-sa

This will verify if the ‘debug-sa’ service account in the ‘default’ namespace is allowed to execute commands in pods within the ‘development’ namespace. This is particularly useful when setting up service accounts for CI/CD pipelines that need to perform diagnostic commands in running pods.

By providing multiple advanced examples, we can demonstrate the versatility of the ‘kubectl auth can-i’ command in managing complex permission scenarios in Kubernetes.

Looking Ahead: 

The ‘kubectl auth can-i’ command is a simple yet powerful tool to help manage and verify permissions within a Kubernetes cluster. It’s an essential command for anyone responsible for the security and integrity of their Kubernetes environment.

Remember, always verify before you deploy!