[
https://issues.apache.org/jira/browse/SPARK-58622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
André Schaidhauer Luckmann updated SPARK-58622:
-----------------------------------------------
Description:
#
h2. What
Enable Spark Connect's gRPC server to terminate TLS directly, instead of
requiring an external reverse-proxy sidecar. Configuration is read from the
standard `spark.ssl.connect.*` namespace (parsed via SSLOptions, same machinery
as `spark.ssl.ui`, `spark.ssl.rpc`).
#
h2. Why
Today an operator wanting TLS between a Connect client and the Connect server
must front the gRPC endpoint with an Envoy/nginx/haproxy sidecar configured for
HTTP/2. This is operationally awkward and duplicates configuration a native
Spark deployment already has. The Connect Python and Scala clients have
supported use_ssl since SPARK-42533 (3.4.1); the server side has been the gap.
#
h2. Scope
- Server-side TLS only. mTLS is a follow-up.
- PEM key material only in this PR. JKS + provider overrides are follow-ups.
- spark.ssl.connect.enabled is opt-in and does not inherit spark.ssl.enabled
(matches spark.ssl.rpc.enabled precedent).
h2. Related
- SPARK-41917 (client-focused, still open)
- SPARK-42533 (Scala client SSL, merged)
was:
## What
Enable Spark Connect's gRPC server to terminate TLS directly, instead of
requiring an external reverse-proxy sidecar. Configuration is read from the
standard `spark.ssl.connect.*` namespace (parsed via
SSLOptions, same machinery as `spark.ssl.ui`, `spark.ssl.rpc`).
## Why
Today an operator wanting TLS between a Connect client and the Connect server
must front the gRPC endpoint with an Envoy/nginx/haproxy sidecar configured for
HTTP/2. This is operationally awkward and duplicates
configuration a native Spark deployment already has. The Connect Python and
Scala clients have supported use_ssl since SPARK-42533 (3.4.1); the server side
has been the gap.
## Scope
- Server-side TLS only. mTLS is a follow-up.
- PEM key material only in this PR. JKS + provider overrides are follow-ups.
- spark.ssl.connect.enabled is opt-in and does not inherit spark.ssl.enabled
(matches spark.ssl.rpc.enabled precedent).
## Related
- SPARK-41917 (client-focused, still open)
- SPARK-42533 (Scala client SSL, merged)
> Support server-side TLS for the Spark Connect gRPC server
> ---------------------------------------------------------
>
> Key: SPARK-58622
> URL: https://issues.apache.org/jira/browse/SPARK-58622
> Project: Spark
> Issue Type: Improvement
> Components: Connect
> Affects Versions: 5.0.0
> Reporter: André Schaidhauer Luckmann
> Priority: Major
>
> #
> h2. What
> Enable Spark Connect's gRPC server to terminate TLS directly, instead of
> requiring an external reverse-proxy sidecar. Configuration is read from the
> standard `spark.ssl.connect.*` namespace (parsed via SSLOptions, same
> machinery as `spark.ssl.ui`, `spark.ssl.rpc`).
> #
> h2. Why
> Today an operator wanting TLS between a Connect client and the Connect server
> must front the gRPC endpoint with an Envoy/nginx/haproxy sidecar configured
> for HTTP/2. This is operationally awkward and duplicates configuration a
> native Spark deployment already has. The Connect Python and Scala clients
> have supported use_ssl since SPARK-42533 (3.4.1); the server side has been
> the gap.
> #
> h2. Scope
> - Server-side TLS only. mTLS is a follow-up.
> - PEM key material only in this PR. JKS + provider overrides are follow-ups.
> - spark.ssl.connect.enabled is opt-in and does not inherit spark.ssl.enabled
> (matches spark.ssl.rpc.enabled precedent).
> h2. Related
> - SPARK-41917 (client-focused, still open)
> - SPARK-42533 (Scala client SSL, merged)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]