sweb opened a new pull request, #58010:
URL: https://github.com/apache/spark/pull/58010
### What changes were proposed in this pull request?
`BasicExecutorFeatureStep` now populates the executor environment from
`SecurityManager.getEnvironmentForSslRpcPasswords`, immediately alongside the
existing `_SPARK_AUTH_SECRET` injection. This is the same call the standalone
worker already makes in `CommandUtils`.
Variable names the user already binds through
`spark.kubernetes.executor.secretKeyRef` are skipped, so an explicit secret
reference does not end up with a literal password beside it in the pod spec.
### Why are the changes needed?
`spark.ssl.rpc.enabled=true` cannot work on Kubernetes today.
`SparkConf.isExecutorStartupConf` deliberately withholds `spark.ssl.*` keys
containing `Password` from the executor startup conf, with the comment
"Passwords are propagated separately though". That separate channel is the
`_SPARK_SSL_RPC_*` environment variables, read back by `SSLOptions.parse`, and
the Kubernetes backend never wrote them. Executors thus start with no keystore
password and die building their `RpcEnv`:
```
java.lang.RuntimeException: SSLFactory creation failed
at org.apache.spark.network.ssl.SSLFactory.<init>(SSLFactory.java:84)
at org.apache.spark.rpc.netty.NettyRpcEnv.<init>(NettyRpcEnv.scala:69)
Caused by: java.security.UnrecoverableKeyException: Get Key failed:
Cannot read the array length because "password" is null
```
The application then aborts on `Max number of executor failures (4) reached`
without submitting a job. The only way to use RPC SSL on Kubernetes is to
inject the four variables by hand from a Secret.
### Does this PR introduce _any_ user-facing change?
Yes. Previously, setting `spark.ssl.rpc.enabled=true` on Kubernetes without
also setting `spark.kubernetes.executor.secretKeyRef._SPARK_SSL_RPC_*` caused
every executor to fail during `RpcEnv` construction and the application to
abort. Now the passwords reach the executors from the driver's configuration
and the application runs.
Users already applying the `secretKeyRef` workaround are unaffected: those
bindings still win, and no literal password is added beside them.
### How was this patch tested?
Three new tests in `BasicExecutorFeatureStepSuite`:
- `SSL RPC password propagation`
- `SSL RPC passwords shouldn't propagate if RPC SSL is disabled`
- `SSL RPC passwords shouldn't override an explicit secretKeyRef`
Also verified end-to-end on minikube, k8s v 1.35.1
### Was this patch authored or co-authored using generative AI tooling?
Claude Code was used when debugging the original issue that lead to this PR
- the first version of this PR was drafted in that session as well.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
