According to the Spark security documentation, on Kubernetes any user who can list pods in the namespace where the Spark application runs can also see its authentication secret. Spark does not hide it from namespace readers, so Kubernetes RBAC has to restrict who may list and read pods there.
What the docs say
Spark's shared secret authentication is enabled with the spark.authenticate setting. How the secret is handled depends on the cluster manager.
- On YARN, Spark generates a unique secret per application, and this relies on YARN RPC encryption for safe distribution.
- With a fixed secret setting, the same secret is shared by all Spark applications and daemons, which the docs say limits security, "especially on multi-tenant clusters".
- On Kubernetes, the docs say any user who can list pods in the application's namespace can see its authentication secret, and that RBAC must be configured accordingly.
The docs also mention supplying secrets through files, with a note that Spark will not mount those files into the containers for you.
Why this matters
Many teams treat a namespace as a team boundary and give analysts or developers read access to pods for debugging. Under the Spark behavior, that read access also exposes the secret that authenticates traffic inside the application. Someone holding it could be trusted by that application's components.
This is not a bug report. It is documented behavior that turns a common RBAC grant into a secret exposure.
What to do
- Inventory who can list or get pods in namespaces that run Spark. Include service accounts used by CI, notebooks and dashboards, not just people.
- Split namespaces. Put Spark applications that use authentication in namespaces with a short list of readers.
- Remove broad grants. Debugging access can be time limited or limited to logs rather than pod specs, if your tooling allows it.
- Review default roles. Read access bundled into broad built-in roles often reaches more people than expected.
- Consider per-application isolation for sensitive workloads, so one secret exposure does not reach other applications.
- Turn on audit logging for pod reads in these namespaces, so you can see who looked.
How to test your own setup
In a test namespace, create a role with only list access to pods and bind it to a test account. Then use that account to read a running Spark driver pod and see what is visible. Do this in a non-production environment and clean up afterward.
Related controls
Authentication is one layer. The same docs recommend encrypting traffic between nodes, protecting the web UI with a filter, and limiting access to Spark ports. Combined with narrow RBAC, these reduce what a single leaked secret can do.
Where dependencies fit
RBAC and secrets are configuration, not packages. But they decide the blast radius when a dependency in a Spark job is compromised. A job that can read a secret and a warehouse is a more valuable target than one that cannot.
Safeguard's asset discovery, SBOM and dependency scanning, and reachability analysis can help you see which Spark jobs carry exploitable packages so you can prioritize them. The free scan at https://gold.safeguard.sh/scan is a quick way to try it.
Quick check
Is the secret exposed if I use YARN?
The docs describe a different model for YARN, with a unique secret per application, and say it depends on YARN RPC encryption being enabled.
Does turning on spark.authenticate fix this?
It turns on authentication, but on Kubernetes the secret's visibility depends on RBAC, which you must configure.
Sources
Last reviewed: 19 October 2026.
