patch configmaps
Patch and update are distinct RBAC verbs, but patch alone, without update, carries the same risk on kube-system ConfigMaps.
It is enough to rewrite CoreDNS or any other sensitive kube-system ConfigMap.
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
Any IAM principal whose ARN is mapped can use it, including one from another AWS account, and it needs no AWS permissions of its own to do so
The bearer token is a locally signed GetCallerIdentity request, an API that requires no allow policy, so a zero-permission identity still authenticates
Editing the node role own entry is tempting but fails wherever that role has an access entry, since access entries override aws-auth for the same principal
Removing the mapping revokes access at once, unlike the certificate paths where an issued credential cannot be recalled
Console clusters using Auto Mode are created in API mode where this is inert, while a raw CreateCluster call with no accessConfig defaults to CONFIG_MAP where it is live
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 captures 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 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:
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.