Kubernetes API Server Proxying Request to Kubelet
Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability tooling.
Elastic rule (View on GitHub)
1[metadata]
2creation_date = "2026/05/05"
3integration = ["kubernetes"]
4maturity = "production"
5updated_date = "2026/05/05"
6
7[rule]
8author = ["Elastic"]
9description = """
10Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly
11to a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet
12API on any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path,
13an attacker can list all pod specifications including environment variable secrets, read Kubelet configuration and
14PKI material, retrieve container logs, and access running pod metadata across all workloads on the target node.
15Monitoring and health check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate
16observability tooling.
17"""
18false_positives = [
19 """
20 Legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the
21 excluded metrics prefix may match. Baseline approved operators and automation identities.
22 """,
23]
24from = "now-9m"
25index = ["logs-kubernetes.audit_logs-*"]
26language = "kuery"
27license = "Elastic License v2"
28name = "Kubernetes API Server Proxying Request to Kubelet"
29note = """## Triage and analysis
30
31### Investigating Kubernetes API Server Proxying Request to Kubelet
32
33Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from
34where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/
35maps directly to the Kubelet API path the attacker accessed.
36
37### Possible investigation steps
38
39- Check the proxied Kubelet path in requestURI to determine attacker intent:
40 - /proxy/pods — pod spec enumeration including environment variable secrets
41 - /proxy/exec or /proxy/run — command execution inside containers on that node
42 - /proxy/configz — Kubelet configuration and authentication settings
43 - /proxy/runningpods — active workload enumeration
44 - /proxy/containerLogs — log harvesting for leaked credentials
45- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings
46- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this
47 indicates the attacker minted a token specifically for this access.
48- Review whether the same principal accessed multiple nodes via proxy in a short window, which
49 indicates systematic lateral movement across the cluster.
50
51### False positive analysis
52
53- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy.
54 These endpoints are excluded by default. If additional monitoring paths generate noise, add
55 them to the requestURI exclusion.
56- Cluster administration tools that inspect node health via the proxy API can match. Correlate
57 with change management windows and verify the source identity.
58
59### Response and remediation
60
61- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding
62 is authorized. Remove unauthorized bindings.
63- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised.
64 Rotate affected credentials, API keys, and database passwords.
65- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node,
66 review running containers for unauthorized modifications, and check for persistence mechanisms.
67- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be
68 restricted to infrastructure automation only, never granted to application service accounts.
69"""
70references = [
71 "https://kubernetes.io/docs/concepts/cluster-administration/proxies/",
72 "https://attack.mitre.org/techniques/T1552/007/",
73]
74risk_score = 47
75rule_id = "332ecb5b-08b6-47e9-885b-3cee1de74bac"
76severity = "medium"
77tags = [
78 "Data Source: Kubernetes",
79 "Domain: Kubernetes",
80 "Use Case: Threat Detection",
81 "Tactic: Privilege Escalation",
82 "Tactic: Lateral Movement",
83 "Tactic: Discovery",
84 "Resources: Investigation Guide",
85]
86timestamp_override = "event.ingested"
87type = "query"
88query = '''
89kubernetes.audit.objectRef.subresource:"proxy" and
90kubernetes.audit.objectRef.resource:"nodes" and
91not kubernetes.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and
92not user.name:(
93 system\:kube-controller-manager or
94 system\:kube-scheduler or
95 system\:serviceaccount\:kube-system\:* or
96 system\:node\:* or
97 eks\:* or aksService
98)
99'''
100
101[[rule.threat]]
102framework = "MITRE ATT&CK"
103
104[[rule.threat.technique]]
105id = "T1611"
106name = "Escape to Host"
107reference = "https://attack.mitre.org/techniques/T1611/"
108
109[rule.threat.tactic]
110id = "TA0004"
111name = "Privilege Escalation"
112reference = "https://attack.mitre.org/tactics/TA0004/"
113
114[[rule.threat]]
115framework = "MITRE ATT&CK"
116
117[[rule.threat.technique]]
118id = "T1550"
119name = "Use Alternate Authentication Material"
120reference = "https://attack.mitre.org/techniques/T1550/"
121
122[[rule.threat.technique.subtechnique]]
123id = "T1550.001"
124name = "Application Access Token"
125reference = "https://attack.mitre.org/techniques/T1550/001/"
126
127[rule.threat.tactic]
128id = "TA0008"
129name = "Lateral Movement"
130reference = "https://attack.mitre.org/tactics/TA0008/"
131
132[[rule.threat]]
133framework = "MITRE ATT&CK"
134
135[[rule.threat.technique]]
136id = "T1613"
137name = "Container and Resource Discovery"
138reference = "https://attack.mitre.org/techniques/T1613/"
139
140[rule.threat.tactic]
141id = "TA0007"
142name = "Discovery"
143reference = "https://attack.mitre.org/tactics/TA0007/"
Triage and analysis
Investigating Kubernetes API Server Proxying Request to Kubelet
Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from where. Examine kubernetes.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/ maps directly to the Kubelet API path the attacker accessed.
Possible investigation steps
- Check the proxied Kubelet path in requestURI to determine attacker intent:
- /proxy/pods — pod spec enumeration including environment variable secrets
- /proxy/exec or /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/proxy permission by reviewing RBAC bindings
- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this indicates the attacker minted a token specifically for this access.
- Review whether the same principal accessed multiple nodes via proxy in a short window, which indicates systematic lateral movement across the cluster.
False positive analysis
- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy. These endpoints are excluded by default. If additional monitoring paths generate noise, add them to the requestURI exclusion.
- Cluster administration tools that inspect node health via the proxy API can match. Correlate with change management windows and verify the source identity.
Response and remediation
- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding is authorized. Remove unauthorized bindings.
- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised. Rotate affected credentials, API keys, and database passwords.
- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node, review running containers for unauthorized modifications, and check for persistence mechanisms.
- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be restricted to infrastructure automation only, never granted to application service accounts.
References
Related rules
- Kubernetes Client Certificate Signing Request Created or Approved
- Kubelet API Connection Attempt to Internal IP
- Potential Direct Kubelet Access via Process Arguments
- Kubernetes Creation or Modification of Sensitive Role
- Kubernetes RBAC Wildcard Elevation on Existing Role