GKE API Server Proxying Request to Kubelet
Description
Detects non-system identities using the GKE nodes/proxy API to reach a node's Kubelet through the API server. The nodes/proxy subresource allows any principal with this permission to call the Kubelet API without direct node network access or Kubelet TLS certificates. Through this path an attacker can list pod specs (including environment secrets), read Kubelet configuration, retrieve container logs, and access running pod metadata on the target node. Monitoring endpoints such as metrics, healthz, and stats/summary are excluded to reduce noise from observability tooling.
Query · kuery
data_stream.dataset:gcp.audit and service.name:"k8s.io" and event.outcome:success and event.action:( "io.k8s.core.v1.nodes.proxy.get" or "io.k8s.core.v1.nodes.proxy.create" ) and not gcp.audit.resource_name:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and not client.user.email:( "system:kube-controller-manager" or "system:kube-scheduler" or system\:serviceaccount\:kube-system\:* or system\:node\:* )
Investigation fields
Pivot points the source recommends for triage.
@timestampclient.user.emailsource.ipuser_agent.originalevent.actionevent.outcomegcp.audit.resource_namedata_stream.namespace
Implementation guide
The GCP Fleet integration with GKE audit logs enabled is required.
Known false positives
- Legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the excluded metrics paths may match. Baseline approved operators and automation identities after review.
Analyst notes
Investigating GKE API Server Proxying Request to Kubelet
Review client.user.email, source.ip, and user_agent.original to determine who initiated the proxy request.
Examine gcp.audit.resource_name and event.action to identify which Kubelet path was accessed after /proxy/.
Possible investigation steps
- Check the proxied Kubelet path for attacker intent:
/proxy/pods— pod spec enumeration, including environment variable secrets/proxy/execor/proxy/run— command execution inside containers on that node/proxy/configz— Kubelet configuration and authentication settings/proxy/runningpods— active workload enumeration/proxy/containerLogs— log harvesting for leaked credentials- Identify how the principal obtained
nodes/proxypermission by reviewing RBAC bindings. - Correlate with TokenRequest activity from the same actor shortly before the proxy call.
- Review whether the same principal proxied multiple nodes in a short window.
False positive analysis
- Monitoring agents that scrape paths other than the excluded metrics/health endpoints may match. Add approved paths or identities after baselining.
- Cluster admin tools that inspect node health via the proxy API can match during maintenance windows.
Response and remediation
- Review and remove unauthorized RBAC granting
nodes/proxy. - If
/proxy/podswas accessed, rotate secrets and credentials that may have been exposed via environment variables on that node. - If
/proxy/execor/proxy/runwas accessed, treat the node as compromised and isolate it. - Restrict
nodes/proxyto infrastructure automation only.