T1 edit the pod template the operator renders Operators commonly keep the pod template for the workloads they manage in a ConfigMap they own.
Writing to it sets fields in that template, securityContext.privileged and hostPID among them, without ever holding a pods verb of your own.
Confused deputy via a controller trusted config object
T1
Confused deputy via a controller trusted config object A privileged operator or controller builds an object like a pod from a ConfigMap it owns, then applies it under its own cluster-wide ServiceAccount Write access to that ConfigMap (patch or update, or delete plus create) sets that pod privileged with hostPID, or supplies arbitrary manifests, without holding those rights directly For example, the local-path volume provisioner builds its helper pod from its local-path-config ConfigMap. Poisoning that ConfigMap runs an attacker command as root on a node whenever a PVC is provisioned. Trigger it with an ordinary PVC and pod in the attacker's own namespace. The attacker borrows the controller identity. A GitOps controller is the same pattern, applying attacker manifests cluster-wide ↗ Kubernetes documentation kubernetes.io/docs/concepts/storage/dynamic-provisioning/ Break the chain. Treat write access to any object a privileged controller renders as equivalent to that controller's own permissions, and keep it off tenant identities.
the operator creates the pod under its own identity The controller reconciles, renders the template and creates the pod itself, using its own cluster-wide ServiceAccount.
The create is attributed to the operator, and admission judges the pod against the operator's namespace rather than against yours.
Break the chain. Alert on controller-created workloads whose pod spec changed without a matching change to the controller's own release.
nsenter into the host from the admitted pod Operator namespaces are routinely labelled privileged, or exempted from Pod Security Admission, so the controller can run its own node agents.
The privileged hostPID pod is therefore admitted, and nsenter into PID 1 returns a root shell on the node.
Break the chain. Enforce restricted pod security on operator namespaces too, and grant exemptions per workload rather than per namespace.
collect the projected tokens on the node Every pod scheduled on the node keeps its token under the kubelet directory.
Root on the node reads all of them, and the strongest one decides what happens next.
Break the chain. Spread privileged workloads across nodes so one node's token set is not the whole cluster, and prefer short audiences and lifetimes.
T0 bind cluster-admin to a subject you control Where one of the collected tokens carries the bind verb, escalation prevention is waived and a ClusterRoleBinding to cluster-admin succeeds.
The binding outlives every pod in the chain.
Break the chain. Never grant bind on clusterroles. Audit ClusterRoleBindings for subjects that no release process created.
Sources: unit42.paloaltonetworks.com, www.wiz.io