## 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: ```bash 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: ```bash 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: ```bash 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 ` for scheduling and event details, `kubectl logs --previous` for crash loops, and `kubectl rollout status deployment/` 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: ```bash 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: ```bash 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: ```yaml 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: ```bash kubectl apply -f pod-reader-role.yaml ``` Then bind it to a user or service account using a RoleBinding: ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: read-pods namespace: default subjects: - kind: User name: "jane@example.com" apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` ```bash kubectl apply -f pod-reader-binding.yaml ``` Verify with: ```bash kubectl auth can-i get pods --as=jane@example.com -n default ``` Output should be `yes`. Then attempt a denied action: ```bash kubectl auth can-i delete pods --as=jane@example.com -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: ```yaml 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash 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: ```bash kubectl delete clusterrolebinding ``` 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: ```bash kubectl logs | 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::`. For users, ensure the name matches the authentication system (e.g., email from OIDC). Verify with: ```bash 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 ` 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: ```markdown - [ ] 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= -n `. 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=` 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.