A privileged operator or controller renders an object like a pod from a ConfigMap it owns, then applies it under its own cluster-wide ServiceAccount
Write access to that ConfigMap (get plus patch or update) lets an attacker set the rendered pod privileged with hostPID, or supply 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
Rights needed, any one set:
· any one write verb on the controller's ConfigMap
· any one write verb on the controller's ConfigMap
· any one write verb on the controller's ConfigMap
· any one write verb on the controller's ConfigMap
Note:
Reaches cluster-admin only where the helper pod can schedule onto a control-plane node and read its admin.conf or CA key.
Where only a worker node is reachable, as on managed control planes, it stops at node compromise.
Guard controller-owned config like kube-system.
