Kubernetes RBAC has four objects. Role and ClusterRole define permissions. RoleBinding and ClusterRoleBinding grant them to subjects. Permissions are purely additive, so there are no deny rules. The scope of the binding, not the role, usually decides how far a permission reaches.
The four objects
A Role always lives in one namespace. A ClusterRole is not namespaced. The Kubernetes docs say a ClusterRole can define permissions on namespaced resources and be granted within single namespaces, define permissions on namespaced resources and be granted across all namespaces, or define permissions on cluster-scoped resources. It can also cover non-resource endpoints such as the health check path.
A binding holds a list of subjects (users, groups or service accounts) and a reference to the role being granted.
The combination that surprises people
A RoleBinding can reference a Role in its own namespace. It can also reference a ClusterRole and bind it only inside the RoleBinding's namespace. That is a handy pattern: define a reusable ClusterRole once, then grant it namespace by namespace.
To grant a ClusterRole in every namespace, you use a ClusterRoleBinding. That is the broad option, and it is the one to review most carefully.
- Read pods in one namespace: Role plus RoleBinding.
- Reuse one role in many namespaces: ClusterRole plus a RoleBinding in each.
- Read pods in all namespaces: ClusterRole plus ClusterRoleBinding.
- Manage nodes or other cluster-scoped objects: ClusterRole plus ClusterRoleBinding.
A minimal example
This Role lets a subject read 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", "watch", "list"]
On its own it grants nothing. Nobody holds the permission until a RoleBinding names a subject and points at pod-reader.
Habits that keep RBAC reviewable
The Kubernetes good practices page suggests assigning permissions at the namespace level where possible, using RoleBindings rather than ClusterRoleBindings. It also advises avoiding wildcard permissions, which cover object types added to the cluster in the future, and not using cluster-admin unless specifically needed.
When you review a cluster, list ClusterRoleBindings first. Each one is a grant that applies everywhere. Then look for bindings to groups, because group membership is managed outside the cluster and is easy to forget.
Safeguard does not replace RBAC review inside a cluster. Where it helps is the surrounding workflow: policies and gates on the changes that modify manifests, and compliance evidence automation for showing a reviewer that access reviews happened.
Quick check
Can a Role grant access in another namespace?
No. A Role sets permissions within the namespace it belongs to. Use a ClusterRole with a RoleBinding in each target namespace, or a binding in the other namespace.
Is there a deny rule in RBAC?
No. The docs state that permissions are purely additive. To remove access, remove the grant.
Sources
Last reviewed: 19 October 2026.
