Kubernetes RBAC Definition

Kubernetes RBAC Definition is the precise characterization of Role-Based Access Control as the authorization model that formally grants permissions by binding a set of allowed actions, expressed as rules over API groups, resources, and verbs, to an identity, expressed as a user, group, or ServiceAccount, through a distinct binding object. RBAC is formally one authorization mode among several the API server supports, but it is the mode expressed entirely as ordinary API objects, meaning permission grants are themselves resources that can be created, inspected, and modified through the same API they govern.

The Four RBAC Object Kinds

Role

A Role formally defines a set of permission rules scoped to a single namespace; it has no effect outside the namespace in which it is created, and its rules formally consist of API groups, resource types, and the verbs permitted against them.

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

ClusterRole

A ClusterRole formally defines the same kind of permission rules as a Role, but is not bound to any single namespace; it may grant permissions over cluster-scoped resources, over namespaced resources across every namespace at once, or serve as a reusable rule set later bound within a specific namespace.

RoleBinding

A RoleBinding formally grants the permissions defined by a referenced Role, or a referenced ClusterRole, to one or more subjects, with the binding's effect scoped to the namespace in which the RoleBinding itself exists, regardless of whether it references a Role or a ClusterRole.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: codartium-team
subjects:
  - kind: ServiceAccount
    name: codartium-controller
    namespace: codartium-team
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

A ClusterRoleBinding formally grants the permissions defined by a referenced ClusterRole across the entire cluster, with no namespace scoping applied at all, the only binding kind capable of granting cluster-wide effect.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: platform-admins
subjects:
  - kind: Group
    name: platform-operators
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Formal Rule Structure

apiGroups, resources, verbs

Every rule within a Role or ClusterRole is formally a triple: apiGroups, the API group(s) the rule applies to; resources, the resource type(s) within those groups; and verbs, the allowed action(s), get, list, watch, create, update, patch, delete, and others, against matching requests.

Additive-Only Semantics

RBAC rules are formally additive only: there is no deny rule in the RBAC model, a subject's effective permissions are the union of every rule granted by every Role or ClusterRole bound to it, and the absence of a granting rule is the only mechanism by which an action is disallowed.

Aggregation

ClusterRole Aggregation

A ClusterRole can formally be defined to aggregate the rules of other ClusterRoles matching a label selector, automatically incorporating their rules into its own effective rule set, allowing extension mechanisms such as CRD installations to contribute additional permissions to a broad, pre-existing role without directly modifying it.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: codartium-view
  labels:
    rbac.codartium.io/aggregate-to-view: "true"
aggregationRule:
  clusterRoleSelectors:
    - matchLabels:
        rbac.codartium.io/aggregate-to-view: "true"
rules: []

Evaluation

How a Request Is Checked

For a given request, the RBAC authorizer formally checks whether any rule, across every Role and ClusterRole bound to the requester's resolved identity via any applicable RoleBinding or ClusterRoleBinding, matches the request's namespace (if applicable), API group, resource, and verb; the request is authorized if at least one matching rule exists, and denied otherwise.

kubectl auth can-i delete pods --as system:serviceaccount:codartium-team:codartium-controller -n codartium-team
kubectl get rolebindings,clusterrolebindings -n codartium-team
kubectl describe clusterrole cluster-admin

Why RBAC Is Structured This Way

Separating the definition of permissions, Role and ClusterRole, from the act of granting them, RoleBinding and ClusterRoleBinding, is what formally allows the same permission set to be reused and granted to many different subjects, and allows the namespace scoping of a binding to be chosen independently of whether the underlying permission definition itself is namespace-bound or cluster-wide.