[
https://issues.apache.org/jira/browse/SPARK-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14360808#comment-14360808
]
Aaron Davidson commented on SPARK-6229:
---------------------------------------
The reason we did not originally put the SASL stuff into the middle of the
TransportContext was to keep the latter simple, allowing SASL to effectively be
a plugin on top. This is pretty critical to the design of not pushing
application-level concerns into the transport layer whenever possible.
That said, clearly encryption cannot work without another layer in the
pipeline. My inclination would be to add a pluggable encryption handler as an
argument to TransportContext. The interface could be something simple like:
{code}
trait EncryptionHandler {
def createChannelHandlers(): List[ChannelHandler]
}
{code}
which are then attached appropriately to the pipeline on channel initialization.
In particular, in my imagination, a user would either want to use SSL
encryption or SASL-based encryption, but not both, so making a single,
optional, EncryptionHandler is sufficient. Second, a user may want to use SSL
and SASL authentication together (maybe not, but I could imagine SSL only being
used for encryption over the wire and SASL being used for more fine-grained
access control), so ideally this could keep the SASL bootstrap, but the SASL
encryption mechanism has a handle to the SASL RPC Handler and waits for it to
say OK before beginning encryption.
If, however, there is no good use-case for SSL + SASL auth, then you could
still do the refactoring you had in mind of putting the SASL authentication as
part of the handler instead of a bootstrap.
> Support 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]
