All of them. The Spark security documentation says a Spark cluster and its services are generally not deployed on the public internet, and that access to Spark ports should be limited to the hosts that need them. That includes the web UIs, the standalone master, the REST submission port and the history server.
The ports the docs list
The security page names these default ports.
| Port | What it is |
|---|---|
| 8080 and 8081 | Standalone master and worker web UIs |
| 7077 | Standalone master |
| 6066 | REST submission server |
| 4040 | Application web UI |
| 18080 | History server |
It also notes that the driver, block manager and executor ports are random unless you pin them. Pinning them makes firewall rules possible. Random ports make narrow rules hard.
Why defaults matter
The same page is direct about the starting position: security features like authentication are not enabled by default, and the docs say none of the deployment types is secure by default. They also state that Spark "does not provide any built-in authentication filters" for the web UI. So network position is often the first control, not the last.
That makes a mistaken firewall rule or a cloud security group opened to all addresses a serious event. A port that accepts job submissions or shows application details is a door.
A checklist
- Find your Spark hosts. Include notebooks, ephemeral clusters and test environments.
- List listening ports on each. Compare against the table above.
- Check inbound rules in your firewall or cloud security groups. Source ranges should be your office, VPN or other known networks, not everywhere.
- Pin driver and executor ports if you need strict rules between nodes.
- Put the UIs behind an authenticating proxy or filter if people need to reach them.
- Turn on authentication and encryption for traffic between nodes. The docs describe these settings.
- Repeat the check after every cluster rebuild, since defaults return when a template changes.
Managed services
If you use a managed Spark service, the vendor's console controls the network. The ports above may not apply, but the question remains: who can reach the endpoints your service exposes? Ask for the answer in writing.
Where dependencies come in
Open ports are a deployment topic, not a package topic, but the two meet. If a vulnerability in a Spark component is exploitable over the network, exposure decides whether it matters to you. Prioritize patches for components on reachable hosts.
Safeguard's asset discovery can help you find the services you run, and its SBOM and dependency scanning plus reachability analysis can rank findings on them. The free scan at https://gold.safeguard.sh/scan is a quick starting point for repositories.
Quick check
Is a firewall enough for Spark?
It is a strong first step, but the docs also recommend enabling authentication and encryption, and protecting the UIs with a filter.
Why pin the random ports?
Pinned driver and executor ports let you write narrow firewall rules. Random ports force wide ranges.
Sources
Last reviewed: 19 October 2026.
