Prefer SSL. The Spark security docs say SSL is standardized and considered more secure than the legacy AES option. If you use AES, set the engine version to 2 and the cipher to AES with GCM and no padding, because the defaults are not authenticated. The two options are mutually exclusive, and RPC SSL is not on by default.
The two options
The Spark documentation describes network encryption of RPC traffic between nodes.
SSL based encryption is the preferred route. A detail that trips people up: the docs state RPC SSL is not automatically enabled when the general SSL setting is turned on. It must be explicitly enabled. If both SSL and AES are enabled, SSL takes precedence.
AES based encryption is a legacy option. It needs RPC authentication, and it is controlled by spark.network.crypto.enabled. The docs recommend two settings:
spark.network.crypto.authEngineVersion=2
spark.network.crypto.cipher=AES/GCM/NoPadding
They explain why. The defaults are not authenticated, since the default cipher mode is CTR, and version 1 of the engine is the backward compatible default.
Authentication comes first
Encryption without authentication protects traffic from eavesdroppers but not from a peer that should not be there. The docs describe shared secret authentication through spark.authenticate. Some details matter:
- With a fixed shared secret, the same secret is used by all applications and daemons, which the docs say limits security on multi tenant clusters.
- On YARN a unique secret is generated per application, and this depends on YARN RPC encryption being on.
- On Kubernetes, anyone who can list pods in the namespace can see the secret, so RBAC must be set to match.
A decision guide
- New cluster: choose SSL for RPC, enable it explicitly, and set authentication.
- Existing cluster using AES: check the engine version and cipher. If they are defaults, move to version 2 with GCM, or migrate to SSL.
- Mixed estate: document the setting per cluster. Do not assume one cluster's configuration applies to another.
- Test after the change: confirm nodes still connect, and confirm traffic is encrypted with a packet capture or your platform's own tooling.
Changing encryption settings on a running cluster can disconnect nodes with different settings. Plan a maintenance window and test in a non-production cluster first.
What to put in evidence
For a review or questionnaire, keep:
- The configuration values for authentication and RPC encryption, per environment.
- The date and the person who checked them.
- The Spark version, since documentation and defaults change between releases.
The dependency angle
The settings above live in Spark itself, so patching Spark matters too. A cipher setting does not help if the version you run has an unpatched flaw in that code path. Track advisories for the Spark version you run.
Safeguard's SBOM and dependency scanning can list the Spark and library versions in your images and match them against known advisories, and its compliance and evidence automation can help keep records of checks like these. The free scan at https://gold.safeguard.sh/scan is a quick way to try the scanning side.
Quick check
If I enable spark.ssl.enabled, is RPC encrypted?
Not necessarily. The docs say RPC SSL is not automatically enabled by that setting and must be explicitly turned on.
Can I run both SSL and AES?
They are mutually exclusive options. If both are enabled, the docs say SSL takes precedence.
Sources
Last reviewed: 19 October 2026.
