No. The Apache Spark security documentation says security features such as authentication are not enabled by default, and that not all deployment types will be secure in all environments and none are secure by default. Before exposing a cluster beyond a trusted network, turn on authentication, encryption and UI access controls.
What the documentation says
The security page warns that when a cluster is open to the internet or an untrusted network, it is important to secure access to prevent unauthorized applications from running on the cluster. It also says that anything not documented, Spark does not support.
That framing is useful for data teams. A Spark cluster is a service that runs submitted code. Open access means open execution.
Defaults worth knowing
From the security page's configuration tables:
| Setting | Default | What it controls |
|---|---|---|
spark.authenticate | false | Whether Spark authenticates its internal connections |
spark.authenticate.secret | none | The shared secret, when authentication is on |
spark.network.crypto.enabled | false | AES based RPC encryption |
spark.io.encryption.enabled | false | Local disk I/O encryption |
spark.acls.enable | false | UI ACLs, which also need an authentication filter |
spark.history.ui.acls.enable | false | ACL checks for the history server |
SSL enabled | false | SSL for the UI and related endpoints |
Two details deserve attention. First, the page says Spark does not provide any built in authentication filters for the web UI, so you must supply a servlet filter yourself, and enabling ACLs without one does nothing. Second, RPC SSL is not turned on automatically when the general SSL switch is set. It must be enabled explicitly.
On the cipher setting, the docs note the default AES/CTR/NoPadding is kept for backward compatibility and is not authenticated, and recommend AES/GCM/NoPadding, plus version 2 of the authentication engine.
Deployment notes
On Kubernetes, the page states that any user who can list pods in the namespace where the Spark application runs can also see the authentication secret. That means namespace access control is part of Spark security there.
Event log directories should be created manually with proper permissions. The default ACL behavior adds only the submitting user.
A first pass checklist
- Put the cluster on a private network and restrict who can submit jobs.
- Enable authentication and set a secret through your secrets system.
- Enable RPC encryption, and choose the authenticated cipher the docs recommend.
- Enable local disk I/O encryption if shuffle or spill files hold sensitive data.
- Install a UI authentication filter, then enable ACLs.
- Restrict namespace access if you run on Kubernetes.
- Re-read the page when you upgrade, because the options change over time.
What to test
Try to reach the master and UI from a machine that should not have access. Try to submit a trivial job without credentials. Both should fail. Record the result as evidence for your next review.
Where Safeguard fits
Safeguard's asset discovery and dependency scanning can help you find Spark and its connectors across repositories and images. A free scan is a quick way to see where it is used.
Quick check
Does turning on spark.acls.enable protect the UI by itself?
No. The docs say it requires an authenticated user, so without an authentication filter it does nothing.
Is SSL for RPC enabled when I enable SSL generally?
No. The documentation says RPC SSL must be enabled explicitly.
Sources
Last reviewed: 19 October 2026.
