Built-in roles

Full unrestricted access to every resource in the cluster — the Kubernetes equivalent of root.

• →Auto-reconciled: any modification or deletion is reverted on the next API server restart.
• →Audit all ClusterRoleBindings to this role — each one is effectively cluster root.
• →Membership in the system:masters group also bypasses RBAC entirely and grants equivalent access without any binding.

Kubelet node identity role — grants broad read access and the secret/configmap access required to run scheduled workloads; scope enforced by the NodeRestriction admission plugin.

• →NodeRestriction admission plugin must be enabled to limit what each kubelet can read — without it this role is much wider in practice.
• →CVE-2022-3294: node name spoofing allowed privilege escalation via this role in Kubernetes ≤ 1.23.
• →Bound to every kubelet via the Node authorizer — compromise of any node identity yields this access.

Controller manager identity — full read/write access to most resources needed to reconcile cluster state, including secrets and SA token creation.

• →Use --use-service-account-credentials so each controller gets its own scoped ServiceAccount instead of sharing one identity.
• →A compromised single identity here yields broad cluster-wide read/write across nearly all resource types.

Allows external storage provisioners to create and delete PersistentVolumes and read PersistentVolumeClaims and StorageClasses.

• →Can create PersistentVolumes with hostPath — pods mounting those volumes gain direct access to the node filesystem.
• →Intended exclusively for external storage provisioner controllers; verify no application workloads hold this role.

Full namespace admin — has bind and escalate within the namespace; can create pods/exec/attach and read/write secrets.

• →Holds bind and escalate within the namespace — a namespace admin can grant themselves any permission they already hold.
• →Aggregation rule: ClusterRoles labeled 'rbac.authorization.k8s.io/aggregate-to-admin: "true"' are automatically merged in.
• →Auto-reconciled — extend behaviour via aggregation labels rather than direct modification.

Read/write access to most namespace resources — can deploy workloads, exec into pods, and read/write secrets; lacks bind and escalate.

• →Can exec into pods and read secrets — treat this as T1 access despite the friendly name.
• →Aggregation rule: ClusterRoles labeled 'rbac.authorization.k8s.io/aggregate-to-edit: "true"' are automatically merged in.
• →Cannot create or bind roles, but workload creation and exec into existing pods is sufficient for most attack scenarios.

Scheduler identity — reads pods and nodes, writes pod binding decisions. Cluster-scoped but tightly restricted to scheduling concerns.

• →Has the bind verb on pods — can assign a pod to any specific node, influencing workload placement.
• →Reads PriorityClasses and PersistentVolumes, giving visibility into storage topology and workload scheduling priority.

kube-proxy identity — list/watch access to Services, Endpoints/EndpointSlices, and Nodes to maintain iptables/IPVS rules for cluster networking.

• →Bound to the kube-proxy ServiceAccount by default.
• →Cluster-wide watch on all Services and Endpoints provides full service mesh topology visibility to any holder of this role.

CoreDNS/kube-dns identity — list/watch Services and Endpoints cluster-wide to answer DNS queries for all workloads.

• →Compromise of the CoreDNS ServiceAccount allows intercepting or poisoning DNS responses for all cluster workloads.
• →The more common poisoning vector is the CoreDNS configMap (kube-system), not this role directly — see escalation-coredns-poisoning.

Allows extension API servers to delegate authentication and authorization to the main Kubernetes API server via TokenReview and SubjectAccessReview.

• →Used by aggregated API servers (metrics-server, custom API extensions) to validate caller identities.
• →A compromised extension server with this role can probe whether arbitrary service account tokens are valid against the API server.

Read-only access to most namespace resources — cannot read secrets or modify any state.

• →Does not include secrets — a common misconception. Secret access must be explicitly granted.
• →Aggregation rule: ClusterRoles labeled 'rbac.authorization.k8s.io/aggregate-to-view: "true"' are automatically merged in.
• →Still useful for reconnaissance: pod names, service endpoints, environment variable names, and event logs reveal cluster topology.

Minimal access for authenticated users — allows self permission enumeration via selfsubjectaccessreviews.

• →Bound to the 'system:authenticated' group by default — every authenticated user has this.
• →selfsubjectaccessreviews lets any authenticated user enumerate their own permissions — attackers use this to map available attack surface.

Read access to API discovery endpoints — allows enumerating available API groups, versions, and resource types.

• →Bound to 'system:unauthenticated' by default — anonymous users can enumerate your cluster's full API surface.
• →Restricting this breaks kubectl and client tooling; limit unauthenticated network access at the infrastructure level instead.

Allows reading non-sensitive public cluster information — /healthz, /readyz, /livez, and /version endpoints.

• →Bound to both 'system:authenticated' and 'system:unauthenticated' — truly public to the network.
• →Exposes the Kubernetes version string, which helps attackers target known version-specific CVEs.

Read access to monitoring endpoints — intended for Prometheus and similar scrapers to access /metrics on nodes and the API server.

• →Metrics endpoints can expose sensitive operational data: request rates, error rates, resource names, and label values.
• →Verify only monitoring ServiceAccounts (Prometheus, Datadog, etc.) are bound to this role.