Github user mccheah commented on the issue:
https://github.com/apache/spark/pull/23174
> There doesn't need to be a single solution. This patch going in does not
preclude adding more features later, one of which might be reading this from a
pre-defined secret.
The way it's written now, if the user opts-in to using `spark.authenticate`
with Kubernetes, the application will _always_ automatically generate the
secret and use that as the security mechanism. I think we'd prefer to see the
various options that are available up front and this patch should probably
introduce both the automatic secret creation version (if we agree that this is
secure) and the manual provision version. If this change is merged into 3.x
without any other changes, users will be forced to use the K8s secret based
SASL scheme and this feature will be unusable for other users such as with the
vault case discussed above.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
