Role and ClusterRole
RBAC objects that define a set of permitted API verbs on specified resources, scoped to a namespace (Role) or cluster-wide (ClusterRole).
What is Role and ClusterRole?
A Role is a namespace-scoped RBAC object that defines a set of permissions within a single namespace. Each rule in a Role specifies an apiGroups list (e.g., [''], ['apps'], ['batch']), a resources list (e.g., ['pods', 'deployments', 'secrets']), and a verbs list (e.g., ['get', 'list', 'watch', 'create', 'update', 'patch', 'delete']). A Role can only grant permissions — it cannot restrict permissions already granted by other roles.
A ClusterRole has the same structure but applies cluster-wide. ClusterRoles serve two distinct purposes: granting permissions on cluster-scoped resources (nodes, namespaces, PersistentVolumes, ClusterRoles themselves) that have no namespace, and granting permissions that can be bound in specific namespaces via RoleBindings. Kubernetes ships with several built-in ClusterRoles — cluster-admin (full access), admin (full namespace access), edit (read-write for most resources), and view (read-only).
Aggregated ClusterRoles compose permissions from multiple ClusterRoles using label selectors. The built-in admin, edit, and view ClusterRoles use aggregation, allowing CRD owners to extend them automatically by creating a ClusterRole with the appropriate aggregation label.
Example
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pod-reader
namespace: production
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-binding
namespace: production
subjects:
- kind: ServiceAccount
name: monitoring-agent
namespace: monitoring
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.ioCost & Waste Implications
Wildcard Roles (resources: ['*'], verbs: ['*']) grant full namespace access to whatever ServiceAccount they are bound to. If that ServiceAccount's token is stolen via a container escape, the attacker has complete control of the namespace including creating expensive workloads, accessing all Secrets, and potentially escalating to cluster-admin through chained permissions.
How KorPro Helps
KorPro identifies Roles and ClusterRoles with wildcard resource or verb specifications, flags bindings to ServiceAccounts that no longer exist, and highlights ClusterRoles with cluster-admin-equivalent permissions bound to non-system subjects.
Scan Your Cluster FreeRelated Terms
RBAC(RBAC)
SecurityRole-Based Access Control — Kubernetes's authorization mechanism that grants permissions through role bindings.
Read definitionServiceAccount
SecurityAn identity for Pods to authenticate to the Kubernetes API and cloud provider services, with tokens automatically mounted.
Read definitionNamespace
Core ConceptsA virtual partition within a cluster that isolates resources, access control, and networking between teams or environments.
Read definitionPod Security
SecurityKubernetes controls that restrict what Pods can do at the OS level — capabilities, root access, host namespaces, and file system permissions.
Read definitionStop Wasting Money on Orphaned Kubernetes Resources
KorPro connects to your clusters across GCP, AWS, and Azure — no agents, no installation — and surfaces every orphaned resource with its monthly cost estimate.