update configmaps
The CoreDNS ConfigMap in kube-system controls cluster-wide DNS.
Rewriting it redirects service discovery for every workload, T0.
kube-proxy and kubeadm-config are other high-value targets.
ConfigMaps are not meant for sensitive data, but misconfigured applications and operators often keep credentials or security-relevant settings in them.
Contextual upgrade to T0:
On EKS clusters using the aws-auth ConfigMap for IAM-to-RBAC mapping, editing it maps an attacker IAM principal to system:masters for cluster-admin.
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- RequestResponse
Escalation Paths
This is EKS-specific and requires the cluster's authentication mode to be CONFIG_MAP or API_AND_CONFIG_MAP.
A cluster fully migrated to API mode ignores this ConfigMap entirely.
If aws-auth doesn't exist yet (self-managed clusters, or a fresh EKS cluster before it's applied), create it directly instead of patching.
Patch or create the aws-auth ConfigMap in kube-system, mapping your AWS IAM ARN to the system:masters group
Authenticate via AWS CLI as cluster-admin
Additional rights needed:
Note:
AWS now calls aws-auth deprecated in favor of EKS access entries.
Auth mode moves CONFIG_MAP -> API_AND_CONFIG_MAP -> API only, and never moves back.
Once on API mode, aws-auth is permanently inert.
Update the CoreDNS ConfigMap in kube-system to add a rewrite rule or a stub zone.
CoreDNS reloads its configuration within seconds without a restart.
Every pod in the cluster then resolves the targeted name to an address of your choosing.
Whether that yields credentials depends on the client.
It needs a listener on the redirected address and a client that does not verify the server certificate against the name it asked for.
Additional rights needed:
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.