[ 
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]

Reply via email to