Kubernetes Extension RBAC Management

Kubernetes Extension RBAC Management is the practice of integrating new resource types and extension components into the cluster's role-based access control model coherently, covering aggregated ClusterRoles that let extensions plug into the built-in view/edit/admin role hierarchy, the escalation-prevention rules that bound what any actor can grant, and the specific RBAC roles required by aggregated API servers and webhooks to authenticate delegated requests.

Aggregated ClusterRoles

Plugging Into the Default Role Hierarchy

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: postgrescluster-edit
  labels:
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
  - apiGroups: ["databases.example.com"]
    resources: ["postgresclusters"]
    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

Kubernetes ships default ClusterRoles named view, edit, and admin that use aggregation labels to automatically absorb rules from any other ClusterRole carrying the matching rbac.authorization.k8s.io/aggregate-to-<role> label; a CRD author adding this label to their own ClusterRole means every user or group already bound to the built-in edit role automatically gains access to the new custom resource type without any change to existing RoleBindings.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: postgrescluster-view
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
  - apiGroups: ["databases.example.com"]
    resources: ["postgresclusters"]
    verbs: ["get", "list", "watch"]

Layered Aggregation

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-monitoring: "true"

An organization can define its own intermediate aggregation labels (such as aggregate-to-monitoring) beyond the built-in three, and a custom ClusterRole used as the aggregation root for a team-specific composite role, giving extension authors a consistent, decentralized way to participate in access control tiers defined outside core Kubernetes.

Escalation Prevention

The Cannot-Grant-More-Than-You-Have Rule

The API server enforces that no actor can create a Role, ClusterRole, RoleBinding, or ClusterRoleBinding granting permissions the actor does not themselves already hold, unless that actor also holds the escalate verb on the relevant resource; this prevents a controller or user with permission only to manage RBAC objects from using that permission to grant itself broader access than it started with.

rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles"]
    verbs: ["escalate"]

bind Verb for Delegation Without Full Control

rules:
  - apiGroups: ["rbac.authorization.k8s.io"]
    resources: ["clusterroles"]
    verbs: ["bind"]
    resourceNames: ["postgrescluster-edit"]

The bind verb, scoped via resourceNames to a specific ClusterRole, lets an actor create bindings to that exact role without granting the broader ability to create or modify arbitrary roles, a common pattern for delegating "who can grant access to this specific Operator's resources" without granting general RBAC administration authority.

RBAC for Aggregated API Servers

Delegated Authentication Role

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: custom-metrics-auth-reader
  namespace: kube-system
roleRef:
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
  - kind: ServiceAccount
    name: custom-metrics-apiserver
    namespace: custom-metrics

An aggregated API server requires a RoleBinding granting it read access to the extension-apiserver-authentication ConfigMap in kube-system, since that is how it retrieves the client CA and request-header configuration needed to validate identities already authenticated by the front-end API server; omitting this binding causes every request to the aggregated API to fail authentication despite the aggregated server itself running correctly.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: custom-metrics-auth-delegator
roleRef:
  kind: ClusterRole
  name: system:auth-delegator
subjects:
  - kind: ServiceAccount
    name: custom-metrics-apiserver
    namespace: custom-metrics

The built-in system:auth-delegator ClusterRole similarly grants an aggregated API server the ability to perform TokenReview and SubjectAccessReview calls against the main API server, delegating the actual authorization decision back to the cluster's central RBAC configuration rather than reimplementing it.

RBAC for Webhooks

Minimal Service Account Scope

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: postgrescluster-validator-role
rules:
  - apiGroups: ["databases.example.com"]
    resources: ["postgresclusters"]
    verbs: ["get"]

An admission webhook's own service account typically needs only narrow, often read-only, RBAC permissions, since its role is to evaluate an incoming request rather than to independently manage cluster resources; granting it broader access than strictly required expands the impact of a webhook compromise well beyond what its actual function warrants.

Relationship to Operator Scope and Extension Areas

Extension RBAC management is the cluster-wide access-control layer that sits above the resource-specific RBAC decisions covered under Operator extensibility scope, providing the aggregation and escalation-prevention mechanisms that let CRDs, aggregated API servers, and webhooks all participate coherently in the same access-control model rather than each requiring bespoke, disconnected permission schemes: it is what allows "grant this user edit access" to remain a single, stable operation even as the set of resource types in a cluster grows through ongoing extensibility work.