AWS EKS 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/08/03"
3integration = ["aws"]
4maturity = "production"
5min_stack_comments = "The AWS integration adds the aws.eks_audit data stream in package 8.9.0, which requires Kibana 9.6.0 or later."
6min_stack_version = "9.6.0"
7updated_date = "2026/10/20"
8
9[rule]
10author = ["Elastic"]
11description = """
12Detects non-system identities using the Kubernetes nodes/proxy API to proxy requests through the API server directly to
13a node's Kubelet. The nodes/proxy subresource allows any principal with this RBAC permission to reach the Kubelet API on
14any worker node without needing direct network access or Kubelet TLS certificates. Through this proxy path, an attacker
15can list all pod specifications including environment variable secrets, read Kubelet configuration and PKI material,
16retrieve container logs, and access running pod metadata across all workloads on the target node. Monitoring and health
17check endpoints such as /metrics, /healthz, and /stats are excluded to reduce noise from legitimate observability
18tooling.
19"""
20false_positives = [
21 """
22 Legitimate kubelet debugging, node troubleshooting, or security tooling that uses the node proxy outside the
23 excluded metrics prefix may match. Baseline approved operators and automation identities.
24 """,
25]
26from = "now-9m"
27index = ["logs-aws.eks_audit-*"]
28language = "kuery"
29license = "Elastic License v2"
30name = "AWS EKS API Server Proxying Request to Kubelet"
31note = """## Triage and analysis
32
33### Investigating AWS EKS API Server Proxying Request to Kubelet
34Review the user.name, source.ip, and user_agent.original fields to determine who initiated the proxy request and from
35where. Examine aws.eks.audit.requestURI to identify which Kubelet endpoint was proxied — the path after /proxy/
36maps directly to the Kubelet API path the attacker accessed.
37
38### Possible investigation steps
39
40- Check the proxied Kubelet path in requestURI to determine attacker intent:
41 - /proxy/pods — pod spec enumeration including environment variable secrets
42 - /proxy/exec or /proxy/run — command execution inside containers on that node
43 - /proxy/configz — Kubelet configuration and authentication settings
44 - /proxy/runningpods — active workload enumeration
45 - /proxy/containerLogs — log harvesting for leaked credentials
46- Identify how the principal obtained nodes/proxy permission by reviewing RBAC bindings
47- Check if a ServiceAccount token was created shortly before via the TokenRequest API - this
48 indicates the attacker minted a token specifically for this access.
49- Review whether the same principal accessed multiple nodes via proxy in a short window, which
50 indicates systematic lateral movement across the cluster.
51
52### False positive analysis
53
54- Prometheus, Datadog, and other monitoring agents scrape /metrics and /stats via nodes/proxy.
55 These endpoints are excluded by default. If additional monitoring paths generate noise, add
56 them to the requestURI exclusion.
57- Cluster administration tools that inspect node health via the proxy API can match. Correlate
58 with change management windows and verify the source identity.
59
60### Response and remediation
61
62- Immediately review the RBAC role granting nodes/proxy permission and determine if the binding
63 is authorized. Remove unauthorized bindings.
64- If /proxy/pods was accessed, assume all environment variable secrets on that node are compromised.
65 Rotate affected credentials, API keys, and database passwords.
66- If /proxy/exec or /proxy/run was accessed, treat the target node as compromised. Isolate the node,
67 review running containers for unauthorized modifications, and check for persistence mechanisms.
68- Audit all ClusterRoles for nodes/proxy permission — this is a powerful privilege that should be
69 restricted to infrastructure automation only, never granted to application service accounts."""
70references = ["https://kubernetes.io/docs/concepts/cluster-administration/proxies/"]
71risk_score = 47
72rule_id = "b9ef6a04-6f0d-5b61-a308-405cf668f014"
73setup = """This rule reads EKS control-plane audit logs collected by the AWS integration
74into `logs-aws.eks_audit-*`, where the AWS EKS audit ingest
75pipelines normalize each audit record under `aws.eks.audit.*`.
76
77Enable the `audit` control-plane log type on the EKS cluster, send its
78CloudWatch log group through the AWS integration, and confirm events carry
79`data_stream.dataset: aws.eks_audit` and
80`cloud.provider: aws` before enabling this rule.
81"""
82severity = "medium"
83tags = [
84 "Domain: Cloud",
85 "Domain: Containers",
86 "Platform: AWS",
87 "Platform: Kubernetes",
88 "Data Source: AWS",
89 "Data Source: Amazon Web Services",
90 "Data Source: Kubernetes API Server Audit Logs",
91 "Service: AWS EKS",
92 "Use Case: Threat Detection",
93 "Tactic: Privilege Escalation",
94 "Tactic: Lateral Movement",
95 "Tactic: Discovery",
96 "Rule Type: Custom Query (KQL)",
97 "Resources: Investigation Guide",
98 "Profile: Beta",
99]
100timestamp_override = "event.ingested"
101type = "query"
102
103query = '''
104data_stream.dataset:"aws.eks_audit" and
105aws.eks.audit.objectRef.subresource:"proxy" and
106aws.eks.audit.objectRef.resource:"nodes" and
107not aws.eks.audit.requestURI:(*metrics* or *healthz* or *stats/summary* or *elastic-agent* or *configz*) and
108not user.name:(
109 system\:kube-controller-manager or
110 system\:kube-scheduler or
111 system\:serviceaccount\:kube-system\:* or
112 system\:node\:* or
113 eks\:*
114)
115'''
116
117
118[[rule.threat]]
119framework = "MITRE ATT&CK"
120[[rule.threat.technique]]
121id = "T1611"
122name = "Escape to Host"
123reference = "https://attack.mitre.org/techniques/T1611/"
124
125
126[rule.threat.tactic]
127id = "TA0004"
128name = "Privilege Escalation"
129reference = "https://attack.mitre.org/tactics/TA0004/"
130[[rule.threat]]
131framework = "MITRE ATT&CK"
132[[rule.threat.technique]]
133id = "T1550"
134name = "Use Alternate Authentication Material"
135reference = "https://attack.mitre.org/techniques/T1550/"
136[[rule.threat.technique.subtechnique]]
137id = "T1550.001"
138name = "Application Access Token"
139reference = "https://attack.mitre.org/techniques/T1550/001/"
140
141
142
143[rule.threat.tactic]
144id = "TA0008"
145name = "Lateral Movement"
146reference = "https://attack.mitre.org/tactics/TA0008/"
147[[rule.threat]]
148framework = "MITRE ATT&CK"
149[[rule.threat.technique]]
150id = "T1613"
151name = "Container and Resource Discovery"
152reference = "https://attack.mitre.org/techniques/T1613/"
153
154
155[rule.threat.tactic]
156id = "TA0007"
157name = "Discovery"
158reference = "https://attack.mitre.org/tactics/TA0007/"
Triage and analysis
Investigating AWS EKS 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 aws.eks.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
- AWS EKS API Request Impersonating Privileged Identity
- AWS EKS Container Created with Excessive Linux Capabilities
- AWS EKS Ephemeral Container Added to Pod
- AWS EKS Pod Created With HostIPC
- AWS EKS Pod Created With HostNetwork