update configmaps
A ConfigMap that a privileged controller renders into workloads carries the same weight as one in kube-system, because the controller applies whatever it reads under its own cluster-wide ServiceAccount.
The local-path provisioner builds its helper pod from local-path-config, so rewriting that object runs an attacker command as root on a node at the next PVC provision.
Add-on namespaces such as local-path-storage, argocd and flux-system need kube-system level restrictions.
Contextual upgrade to T0:
The controller's rendered pod can land on a control-plane node, for example a volume provisioner helper pod steered there by the attacker's own PVC and nodeSelector: reading that node's admin.conf or CA key gives cluster-admin.
A GitOps controller bound cluster-wide is equally T0, since it applies attacker manifests directly.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
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
Additional rights needed:
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.