Kubernetes Exposed Service Created With Type NodePort
This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker…
Description
This rule detects an attempt to create or modify a service as type NodePort. The NodePort service allows a user to externally expose a set of labeled pods to the internet. This creates an open port on every worker node in the cluster that has a pod for that service. When external traffic is received on that open port, it directs it to the specific pod through the service representing it. A malicious user can configure a service as type Nodeport in order to intercept traffic from other pods or nodes, bypassing firewalls and other network security measures configured for load balancers within a cluster. This creates a direct method of communication between the cluster and the outside world, which could be used for more malicious behavior and certainly widens the attack surface of your cluster.
Detection logic
Its licence does not clear it for publishing here
Sunturai publishes a detection's own text where the licence it arrived under has been reviewed and permits it, and Elastic License 2.0 has not. The query as its source wrote it, its canonical form and the hash that pins this revision are in the workspace record.
Detection requirements
- Platform
- ContainersLinuxmacOSWindows
The rule states no platform. This is derived from the ATT&CK technique it maps to.
- Log source category
- event_index
Known benign triggers
- Developers may have a legitimate use for NodePorts. For frontend parts of an application you may want to expose a Service onto an external IP address without using cloud specific Loadbalancers. NodePort can be used to expose the Service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort Service from outside the cluster, by requesting <NodeIP>:<NodePort>. NodePort unlike Loadbalancers, allow the freedom to set up your own load balancing solution, configure environments that aren't fully supported by Kubernetes, or even to expose one or more node's IPs directly.
MITRE ATT&CK mappings
0 exclusive techniques.This is coverage no other published rule has; it is not this rule's total technique count.
References
| Reference | Cited by |
|---|---|
| kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types | 2 |
| kubernetes.io/docs/concepts/services-networking/service/#type-nodeport | 2 |
| www.tigera.io/blog/new-vulnerability-exposes-kubernetes-to-man-in-the-middle-attacks-heres-how-to-mitigate/ | 2 |
From the source
- At source
- Open at source
- Upstream identifier
- 65f9bccd-510b-40df-8263-334f03174fed
- Tagged by the source as
- Data Source: KubernetesDomain: CloudDomain: ContainersNoise: MediumPerformance: FastPlatform: KubernetesResources: Investigation GuideRule Type: Custom Query (KQL)Tactic: ExecutionTactic: Persistence
Licence
- Published under
- Elastic License 2.0Read the licence
- Attribution
- Required
Authorship
- Written by
- Published
- Sep 20, 2026
- Version
- 3