Kubernetes RBAC Basic Commands with Practical Examples

Intro

Kubernetes RBAC basic commands with practical examples should help operators move from an observed problem to a verified result. Start by identifying the installed version, deployment topology, prerequisites, and the exact component being inspected.

This article focuses on Kubernetes RBAC commands for developers, DevOps consultants and technical startup teams. It connects Kubernetes RBAC basic commands, Kubernetes RBAC examples, Kubernetes RBAC cheat sheet and Kubernetes RBAC operations to commands, expected output, failure signals, and recovery decisions that match the selected technology.

The goal is operational safety: observe before changing, limit the blast radius, use placeholders instead of secrets, verify the result, and document how to recover if the expected state is not reached.

Version and Environment Inventory

Before issuing any RBAC-related commands, confirm the Kubernetes version and the availability of the RBAC API. RBAC is stable in Kubernetes v1.8+ and enabled by default in most managed distributions. Use kubectl version to see client and server versions, and kubectl api-versions to confirm rbac.authorization.k8s.io/v1 is present. If the API group is missing, the cluster may have legacy authorization modes enabled; check the API server flags with kubectl cluster-info dump | grep authorization-mode or consult your cluster administrator.

A read-only inventory is the first step for safe changes. For example, to list existing roles in the default namespace, run:

kubectl get roles -n default

Expected output shows a table with columns NAME and AGE. If no roles exist, the output is No resources found in default namespace. This tells you whether the namespace has custom roles or relies on cluster-wide roles.

For cluster-scoped resources, list cluster roles:

kubectl get clusterroles

This includes built-in roles like admin, edit, view, and cluster-admin, plus any custom ones. To see a specific role in detail, use:

kubectl describe clusterrole view

The output lists the policy rules: resources, verbs, and API groups. Note that built-in roles are often updated during upgrades, so custom roles are preferable for long-lived permissions.

Practical check for Version and Environment Inventory: start with kubectl get pods -o wide, then use kubectl describe pod <name> for scheduling and event details, kubectl logs <name> --previous for crash loops, and kubectl rollout status deployment/<name> before assuming a release succeeded. These commands help differentiate between RBAC authorization failures and other runtime issues; for example, a CrashLoopBackOff may be due to a missing config map rather than a permission error.

For a local test, keep the blast radius small. Apply one manifest, inspect the generated resources, and verify access with kubectl auth can-i or a test pod before moving to production. Example:

kubectl auth can-i create deployments --as=system:serviceaccount:default:test-sa -n default

If the answer is yes, the service account has the permission; if no, inspect the role bindings.

Safe Configuration Path

A safe configuration path starts with defining the least privilege principle. Rather than reusing cluster-admin for every team, create namespace-scoped roles or cluster roles with minimal verbs and resources. Begin by observing what a service account or user can currently do:

kubectl auth can-i --list --as=system:serviceaccount:default:test-sa -n default

This lists all allowed actions for that identity. Use this before and after changes to verify the delta. Then make one scoped change at a time; for example, add a Role that allows reading pods in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Apply it with:

kubectl apply -f pod-reader-role.yaml

Then bind it to a user or service account using a RoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "[email protected]"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f pod-reader-binding.yaml

Verify with:

kubectl auth can-i get pods [email protected] -n default

Output should be yes. Then attempt a denied action:

kubectl auth can-i delete pods [email protected] -n default

Output should be no. This confirms least privilege.

For cluster-wide access, use ClusterRole and ClusterRoleBinding. For example, to allow a group to view nodes:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-nodes
subjects:
- kind: Group
  name: "operations"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: node-viewer
  apiGroup: rbac.authorization.k8s.io

Apply and test with:

kubectl auth can-i list nodes --as=system:serviceaccount:default:ops-sa

If the output is no, check the service account name and binding subject.

Verification and Diagnostics

Verification centers on kubectl auth can-i, kubectl auth reconcile, and audit logs. Start with basic permission checks as shown above. For a more exhaustive view, list all rules for a role:

kubectl get role pod-reader -n default -o yaml

Inspect the output for unexpected verbs or resources. Use kubectl describe for a human-readable summary:

kubectl describe clusterrole admin

This shows aggregated rules and labels.

Diagnosing access denials often involves checking the Kubernetes audit logs if enabled. Look for entries with requestURI and user matching the denied request, and the authorization.k8s.io/decision field set to forbid. For example, in a managed cluster like EKS or GKE, you may need to enable audit logging to see these events.

Another diagnostic is to inspect the effective permissions of a user via kubectl auth can-i --list --as=user. Compare it against the intended role matrix. If permissions are missing, check for typos in resource names, API groups (the core group is ""), and subjects. Also verify that RoleBindings are in the correct namespace; a common mistake is to create a RoleBinding in the kube-system namespace when the Role is in default.

For continuous verification, use tools like kubectl-who-can (a kubectl plugin) to find who can perform an action on a resource. Install it via krew and run:

kubectl who-can delete secrets -n default

This lists all subjects with that permission, making audit and cleanup easier.

Failure Modes and Recovery

RBAC failures typically fall into a few patterns: over-permissive roles, missing permissions, and misconfigured subjects. A common over-permission issue is using cluster-admin for an application service account. This can lead to full cluster compromise if the application is exploited. Detect such bindings with:

kubectl get clusterrolebinding -o json | jq '.items[] | select(.roleRef.name=="cluster-admin") | .subjects'

If you find a service account bound to cluster-admin, revoke it by deleting the ClusterRoleBinding:

kubectl delete clusterrolebinding <binding-name>

Then create a scoped Role and RoleBinding as shown earlier.

Missing permissions often manifest as HTTP 403 Forbidden errors in application logs or kubectl. Use kubectl auth can-i to confirm the missing permission. Then create a Role or ClusterRole with the required verb and resource, and bind it. For example, if a pod cannot read ConfigMaps:

kubectl logs <pod-name> | grep -i forbidden
kubectl auth can-i get configmaps --as=system:serviceaccount:default:my-app -n default

If no, create a Role with get on configmaps and bind it to the service account.

Misconfigured subjects can occur when the subject name does not match the actual user or service account. For service accounts, the subject name must include the namespace: system:serviceaccount:<namespace>:<name>. For users, ensure the name matches the authentication system (e.g., email from OIDC). Verify with:

kubectl get rolebinding read-pods -n default -o yaml

Check the subjects array and correct if needed. After correction, re-run kubectl auth can-i to confirm.

To recover from a problematic change, keep manifests in version control. If a RoleBinding breaks access, you can revert with kubectl apply -f <previous version> or delete the binding. For emergency recovery, cluster administrators can use the system:masters group or cluster-admin role if available, but this should be tightly controlled.

Operations Checklist

Use the following checklist for day-to-day RBAC operations, adapted for a single accountable owner per item:

- [ ] Inventory current roles and bindings: `kubectl get roles,rolebindings,clusterroles,clusterrolebindings --all-namespaces`
  Owner: Priya Shah, Platform Lead, reviewed weekly on Monday.
- [ ] Review new access requests against the principle of least privilege.
  Owner: Priya Shah, Platform Lead, decision within 2 business days.
- [ ] Apply changes using GitOps or `kubectl apply` with versioned manifests.
  Owner: Priya Shah, Platform Lead, after approval.
- [ ] Verify with `kubectl auth can-i --as=<user> <verb> <resource> -n <namespace>`.
  Owner: Priya Shah, Platform Lead, immediately after apply.
- [ ] Check audit logs for denied requests related to the change.
  Owner: Priya Shah, Platform Lead, next business day.
- [ ] Document any exceptions and set a review date (e.g., quarterly).
  Owner: Priya Shah, Platform Lead, quarterly on the first Monday of Jan/Apr/Jul/Oct.

Each item should be completed in order, and the owner is responsible for executing the step and reporting the result. Revisit the checklist itself monthly to adjust for new resources or team structures.

Common Pitfalls and How to Avoid Them

One frequent pitfall is granting wildcard permissions ("*") in verbs or resources for convenience. This undermines least privilege and increases risk. Instead, enumerate the minimal set of verbs (get, list, watch, create, update, patch, delete) and specific resources. If a wildcard is necessary, scope it narrowly (e.g., pods/log rather than pods and all subresources).

Another pitfall is forgetting that Roles are namespace-scoped while ClusterRoles are cluster-wide. A RoleBinding can reference a ClusterRole to grant cluster role permissions within a single namespace, which is useful for reusing common role definitions. But a RoleBinding to a Role does not grant permissions outside its namespace. Conversely, a ClusterRoleBinding grants cluster-wide access. Misunderstanding this leads to over- or under-permission.

A third pitfall is ignoring aggregated ClusterRoles. Kubernetes aggregates rules into roles like admin and edit using labels. If you accidentally modify labels on a custom role, it may be aggregated into these built-in roles and unexpectedly grant permissions. Use kubectl describe clusterrole admin to see its aggregated rules.

Finally, managing RBAC manually without version control can lead to configuration drift and difficult rollbacks. Store all RBAC manifests in a Git repository and use a GitOps tool such as Argo CD or Flux, or at least a CI/CD pipeline that runs kubectl apply. Review changes through pull requests and require two approvers for production clusters.

Conclusion

Kubernetes RBAC basic commands with practical examples is useful only when each recommendation is version-scoped, observable, and reversible where the technology permits. Copying a command without checking prerequisites and expected output is not an operations procedure.

As a next step, choose one low-risk verification for Kubernetes RBAC commands: run kubectl auth can-i --list --as=<user> for a test user, record the current state, compare the result with the expected permission matrix, and review dependencies such as Role, Role Binding and Cluster Role.

A reliable technical workflow makes failure visible, protects sensitive values, limits changes to the intended resource, and defines recovery verification before an incident forces the decision. By applying the commands and practices in this article, you can manage Kubernetes RBAC safely and efficiently.