[
https://issues.apache.org/jira/browse/SPARK-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372352#comment-14372352
]
Marcelo Vanzin commented on SPARK-6229:
---------------------------------------
I'm a little wary of exposing the pipeline directly to client code for this
particular purpose (encryption), or even a "setEncryptionHandler"-style API.
For two main reasons, mainly:
- You'd need code at every client to know which handlers to add where. To given
an example, like today, every client would need to figure out whether
authentication is enabled to add SASL to the pipeline, then figure out whether
SSL is enabled to add the SslHandler to the pipeline, all that stuff. Instead,
if the library takes care of it, all that is mostly transparent to client code
(which would just provide a configuration object to the library).
- It sort of assumes all encryption handlers would work the same way, which is
not necessarily true. For example, SslHandler kinda needs to be the first
handler in the pipeline. The SASL encryption handler, on the other hand, would
benefit from being added after the framing handler. You can make that work, but
I think it wouldn't be as efficient as if everything was internal to the
library.
So I'm a little partial to not exposing the internals to client code. We could,
separately, provide some API that allows people to play directly with the
pipeline, but I think at this point that has questionable value, and it would
make the layout of the pipeline (order and name of handlers) a kind of public
API. I think most users would be fine with just the existing RpcHandler
interface, instead of having to mess with the internals of the channel.
What do you guys think?
> Support SASL encryption in network/common module
> ------------------------------------------------
>
> Key: SPARK-6229
> URL: https://issues.apache.org/jira/browse/SPARK-6229
> Project: Spark
> Issue Type: Sub-task
> Components: Spark Core
> Reporter: Marcelo Vanzin
>
> After SASL support has been added to network/common, supporting encryption
> should be rather simple. Encryption is supported for DIGEST-MD5 and GSSAPI.
> Since the latter requires a valid kerberos login to work (and so doesn't
> really work with executors), encryption would require the use of DIGEST-MD5.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
