This is an automated email from the ASF dual-hosted git repository.
holdenk pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/spark-website.git
The following commit(s) were added to refs/heads/asf-site by this push:
new ebf2c3702c Clarify some of the common "this is not a security" bug
type issues we receive (#712)
ebf2c3702c is described below
commit ebf2c3702c4a063add2ecfe0bd62de0c3d0c08e1
Author: Holden Karau <[email protected]>
AuthorDate: Tue Oct 27 10:57:15 2026 -0700
Clarify some of the common "this is not a security" bug type issues we
receive (#712)
We get a lot of security reports that seem to misunderstand our security
model. Try and clarify this a bit more for the people/robots (honestly
probably the robots).
See:
<img width="2027" height="1975" alt="image"
src="https://github.com/user-attachments/assets/60538602-23ea-4323-af38-9d263c223418";
/>
---------
Co-authored-by: Holden Karau <[email protected]>
Co-authored-by: Cursor <[email protected]>
---
security.md | 53 ++++++++++++++++++++++++++++++++++++++++++++++++++
spark-connect/index.md | 6 ++++++
2 files changed, 59 insertions(+)
diff --git a/security.md b/security.md
index 7e9052d1d9..06948aa4f2 100644
--- a/security.md
+++ b/security.md
@@ -54,6 +54,41 @@ internet or untrusted networks. We recommend access within
trusted networks (com
private cloud environments), using restrict access to the Spark cluster with
robust authentication,
authorization, and network controls.
+<h3>I found an exploit, but it requires authentication to be disabled, is that
a vulnerability?</h3>
+
+No. Without authentication, anyone who can reach a Spark cluster can already
submit and execute arbitrary
+code on it by design (see above), so an exploit that only works with
authentication disabled demonstrates
+no additional risk. Such a deployment is inherently insecure, and reports of
this kind will be rejected.
+If you believe you have found an issue that works against a cluster with
authentication enabled, please
+report it.
+
+<h3>I found an exploit, but it requires knowing the shared secret, is that a
vulnerability?</h3>
+
+No. The shared secret (`spark.authenticate.secret`) _is_ the credential:
anyone who knows it is already
+authenticated and can submit and execute arbitrary code on the cluster by
design (see above). An exploit
+that requires knowing the secret demonstrates no access beyond what the secret
already grants, and
+reports of this kind will be rejected. If you have found a way to bypass
authentication or recover the
+secret without being given it (see, for example,
[CVE-2021-38296](#CVE-2021-38296)), please report it.
+
+<h3 id="spark-connect-user-isolation">I found that one authenticated user can
see or act on another user's session in the same driver (for example, via Spark
Connect's `user_id` / `session_id`), is that a vulnerability?</h3>
+
+No. Spark does not support isolating users from each other within a single
driver. Anyone who holds
+a driver's authentication credential has the same access as anyone else who
holds it, including access
+to sessions, jobs, and data belonging to other holders of that same
credential. This is the flip side of
+the point above: the credential is what grants access, not the identifiers
layered on top of it.
+
+Open-source Spark Connect does not provide user isolation. The `user_id` and
`session_id` fields in a
+Spark Connect request are supplied by the client and used to route a request
to the right session; they
+are not an authorization boundary between different holders of the same
authentication credential.
+A shared token answers "is this caller allowed to talk to this server at all,"
not "which of the server's
+users is this." If mutually-untrusting users need isolation from each other,
give each one their own
+driver, and therefore their own credential, rather than sharing one endpoint
and token across them.
+
+Some vendors offer their own isolation or a multi-tenant version of Spark
Connect on top of
+open-source Spark. Issues with a vendor's isolation or multi-tenant version
should be reported to
+that vendor. The same applies to other projects that add their own per-user
isolation (for example,
+Apache Kyuubi): report those to the project.
+
<h3>Is loading a machine learning model secure? Who is responsible for model
security?</h3>
Loading an Apache Spark ML model is equivalent to loading and executing code
within the Spark runtime.
@@ -68,6 +103,24 @@ End users must treat Spark ML models with the same level of
caution and security
This includes verifying the source, validating integrity, and applying
appropriate isolation and security controls
before loading or deploying a model.
+<h3>Is loading a checkpoint secure?</h3>
+
+No, not from an untrusted source. This applies to any kind of Spark checkpoint
-- RDD checkpoints,
+Spark Streaming checkpoints, and Structured Streaming checkpoints alike. A
checkpoint directory holds
+serialized Spark internals: driver and operator state, and, depending on the
job or query, serialized
+closures such as the functions in a DStream graph. Spark deserializes and
reconstructs these when it recovers
+from a checkpoint. Recovering from a checkpoint you did not write, or whose
storage location is writable
+by someone else, is equivalent to loading and executing arbitrary code within
the Spark runtime, for the
+same reasons a Spark ML model is above.
+
+Checkpoints must be trusted: treat a checkpoint location the same way you
would treat the credential
+that authenticates to the driver, restrict write access to it accordingly, and
do not recover from a
+checkpoint whose provenance or integrity you cannot verify.
+
+<h3>I noticed the Spark server can cause the client to execute code, is that a
problem?</h3>
+
+No, this is intentional. The Spark client _must_ trust the server since the
results that come back can be of complex types whose deserialization can
execute code. The final, smaller parts of a computation sometimes run on the
client or driver (depending on the deployment model). This applies to Spark
Connect as well: a client must trust the server it connects to.
+
<h2>Known security issues</h2>
<h3 id="CVE-2025-55039">CVE-2025-55039: Apache Spark: RPC encryption defaults
to unauthenticated AES-CTR mode, enabling man-in-the-middle ciphertext
modification attacks</h3>
diff --git a/spark-connect/index.md b/spark-connect/index.md
index a6822d367f..e7d3aab0aa 100644
--- a/spark-connect/index.md
+++ b/spark-connect/index.md
@@ -136,6 +136,12 @@ Spark JVM does not allow for this debugging experience
because it does not fully
Due to the decoupled nature of client applications leveraging Spark Connect,
failures of the client are now decoupled from the Spark Driver. This means that
when a client application fails, its failure modes are completely independent
of the other applications and don’t impact the running Spark Driver that may
continue serving other client applications.
+## User isolation
+
+Open-source Spark Connect does not isolate users who share a server. Clients
that can authenticate to a server share its sessions, jobs, and data. `user_id`
and `session_id` route a request to a session; they are not an authorization
boundary.
+
+Some vendors offer their own isolation or a multi-tenant version of Spark
Connect. Issues with those should be reported to the vendor. See the
[Security]({{site.baseurl}}/security.html#spark-connect-user-isolation) page.
+
## Upgrading to Spark Connect
Spark Connect does not support all the Spark JVM APIs. For example, Spark JVM
has private methods that some users leverage to execute arbitrary Java code on
Spark clusters. Spark Connect obviously cannot support those methods because
the Spark Connect client isn’t necessarily running Java!
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
