Spark's master UI and the applications it can restart

On 23 October 2026, ZoomEye returned 16,696 matches for title="Spark Master" and 8,809 for the same title restricted to port 8080. The difference is almost exactly a factor of two, and the restricted query is the one that is easier to explain.
Both are observations of publicly reachable interfaces, collected through the ZoomEye API one result per query. Neither tells you whether the interface requires authentication.

What sits behind the master UI

The Spark master web interface shows registered applications, completed applications, workers and executors. It also exposes an interface that can terminate a running application or driver, and that capability is why the page matters more than its read-only appearance suggests.
Spark's own security documentation describes the controls available: spark.authenticate for internal RPC authentication, SSL settings for the UI and RPC, and a separate spark.ui.filters mechanism for HTTP authentication in front of the web interfaces. Deployments that enable SSL but not authentication encrypt the console without restricting who reaches it.
The distinction between a standalone cluster master and a YARN or Kubernetes deployment matters here. A master UI on port 8080 implies standalone mode, and standalone clusters are the deployments where the console is most likely to be internet-facing by accident, because the cluster was stood up on a handful of hosts without a platform team deciding how it would be published.

Why the port restriction halves the count

A master UI binds 8080 by default. Deployments that keep the default and expose it appear in both queries. Deployments that publish through a load balancer on 443, or change the port, or front the interface with a path prefix, appear only in the unrestricted count.
That is the ordinary explanation, and the 50 per cent retention rate is roughly what a mixed population should look like. It has a second implication that receives less attention: a query scoped to the default port will miss about half the population it claims to describe. Coverage claims built on the port-scoped number overstate confidence.
There is a third reading worth checking before drawing conclusions. A title fingerprint can match a page that merely mentions the phrase, such as documentation, a monitoring dashboard that names a Spark master, or a status page. The unrestricted count is the larger number and therefore the more contaminated one. Confirming a match by inspecting the response body rather than the title alone is the difference between an inventory item and a guess.

The failure mode that a scan never shows

An exposed master UI is a discovery and manipulation surface. An attacker who reaches it learns application names, driver hosts, and often configuration values rendered in the environment tab. Terminating an application is a denial-of-service action with a single request.
Neither step requires the compromise of a credential if the interface is unauthenticated, and neither appears in a port scan. What appears in the scan is a host that answered on 8080 with a particular title.
Post-exploitation is where the real risk sits. Spark applications routinely run with credentials in their environment for object storage, message brokers and databases, and the master UI can surface executor details that point to those applications. Reaching the console is therefore a reconnaissance step towards the data plane, not an end in itself.

Building an inventory that survives the next query

The practical approach is to make external measurement a cross-check against a source of truth you own, rather than the source of truth itself.
From the deployment side: cluster manifests, Helm releases and container inventories name the Spark version and whether spark.authenticate and spark.ui.filters are configured. Those are the values that determine exposure, and they are not visible from outside.
From the measurement side: queries restricted to your own netblocks, certificate organisations or ASN, for the master title and for the worker title, produce a list to reconcile. Two discrepancies matter: a host you find that nobody deployed, and a host you cannot find that your inventory says should be public.
For each master interface in scope, the verification that ends the argument is a request to the applications endpoint followed by a check of the response status and authentication challenge. Recording the status code alongside the host turns a finding into evidence.

Monitoring a distributed job runner

Detecting misuse of a Spark deployment is largely a question of whether job and application activity is retained. Spark writes event logs when spark.eventLog.enabled is set, and those logs record application submission, completion and executor allocation. A history server that retains them, shipped off the cluster, is the record an investigator needs.
The comparison worth running this quarter is between that record and your access logs. Can you list, for a given day, every application that was submitted, by whom, and from which host? If the answer depends on a shell history or a scheduler log that rotates weekly, the record has a gap.
The master UI's terminate action is the other event to look for. A completed application that ended early, with no corresponding deployment or failure in the scheduler, is a specific anomaly worth alerting on where event logs are available.

References

• Apache Spark security documentation: https://spark.apache.org/docs/latest/security.html
• Apache Spark monitoring and instrumentation: https://spark.apache.org/docs/latest/monitoring.html
• Apache Spark web UI configuration: https://spark.apache.org/docs/latest/configuration.html
• ZoomEye query syntax reference: https://www.zoomeye.org/doc
• Measurement note: counts collected 23 October 2026 with title="Spark Master" (16,696) and title="Spark Master" && port=8080 (8,809).