⎈K8sCalc

kubernetes

Kubernetes RBAC Generator

Generate a Kubernetes ServiceAccount, Role or ClusterRole, and RoleBinding or ClusterRoleBinding in one manifest. Configure resources and verbs for least-privilege access.

Kubernetes RBAC: Least-Privilege Access

RBAC (Role-Based Access Control) is how Kubernetes controls what users and workloads can do. Three resources work together: ServiceAccount, Role, and RoleBinding.

The Three-Resource Pattern

ServiceAccount — the identity (who)
Role           — the permissions (what)
RoleBinding    — links identity to permissions (who can do what)

Common Permission Sets

Read-only (monitoring agents, dashboards): `` verbs: [get, list, watch] ``

Read-write (operators, controllers): `` verbs: [get, list, watch, create, update, patch, delete] ``

Checking Permissions

bash
# What can this ServiceAccount do?
kubectl auth can-i --list \
  --as=system:serviceaccount:default:my-app

# Can it get pods? kubectl auth can-i get pods \ --as=system:serviceaccount:default:my-app ```

Common Pitfalls

  • ›Using ClusterRole when Role is sufficient
  • ›Using wildcard verbs/resources: "*"
  • ›Binding to the default ServiceAccount (shared by all pods in namespace)
  • ›Forgetting that RoleBinding scope determines access scope, not Role type

Frequently Asked Questions

What's the difference between Role and ClusterRole?

A Role grants access within a single namespace. A ClusterRole grants access cluster-wide — across all namespaces. Always prefer Role over ClusterRole unless you genuinely need cluster-wide access. A ClusterRole can also be bound to a specific namespace via a RoleBinding (not ClusterRoleBinding) — this is a common pattern for shared roles.

What API group should I use for Deployments?

Deployments, StatefulSets, DaemonSets, and ReplicaSets are in the 'apps' API group. Pods, Services, ConfigMaps, Secrets, PVCs are in the core group (empty string). CronJobs are in 'batch'. You can check with: kubectl api-resources --sort-by=group.

What is the principle of least privilege for RBAC?

Grant only the permissions the workload actually needs. Start with get,list,watch (read-only) and add write verbs only when required. Avoid wildcards (*) for both resources and verbs — they grant access to everything including future resource types. Audit RBAC with: kubectl auth can-i --list --as=system:serviceaccount:default:my-app.

How do I use the ServiceAccount in a Pod?

Set serviceAccountName in the pod spec. Kubernetes automatically mounts the token at /var/run/secrets/kubernetes.io/serviceaccount/token. In the pod: kubectl --token=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token) get pods. For security, set automountServiceAccountToken: false on pods that don't need API access.