delete configmaps
Crashes workloads that depend on the ConfigMap for configuration, at next reload or pod restart.
High-value targets include CoreDNS config, CNI configs, and application feature flags.
Contextual upgrade to T1:
T1 for a kube-system ConfigMap that a control plane component reads, such as the CoreDNS Corefile or a CNI configuration.
Losing it breaks name resolution or pod networking cluster-wide, not just one workload.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
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
Additional rights needed:
· 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
· create plus delete rewrites an existing config object; create alone is enough only where the controller's ConfigMap is absent
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.