[
https://issues.apache.org/jira/browse/SPARK-6229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14488104#comment-14488104
]
Jeffrey Turpin commented on SPARK-6229:
---------------------------------------
Hey Marcelo,
So what I have done is to overload the TransportContext constructor, adding a
constructor that takes an instance of the TransportEncryptionHandler interface:
{code:title=TransportContext.java|linenumbers=false|language=java}
public TransportContext(
TransportConf conf,
RpcHandler appRpcHandler,
TransportEncryptionHandler encryptionHandler) {
this.conf = conf;
this.appRpcHandler = appRpcHandler;
this.decoder = new MessageDecoder();
if (encryptionHandler != null) {
this.encryptionHandler = encryptionHandler;
} else {
this.encryptionHandler = new NoEncryptionHandler();
}
this.encoder =
(this.encryptionHandler.isEnabled() ? new SslMessageEncoder() : new
MessageEncoder());
}
{code}
This way the method existing method signatures for createServer and
createClientFactory don't change. To facilitate this I also added a constructor
to the TransportClientFactory class and modified the constructor for the
TransportServer class, to also take a TransportEncryptionHandler instance....
In the TransportClientFactory case I need to add the Netty SslHandler before
the connection occurs, which can be done by calling the _addToPipeline_ method
of the TransportEncryptionHandler interface:
{code:title=TransportClientFactory.java|linenumbers=false|language=java}
private void initHandler(
final Bootstrap bootstrap,
final AtomicReference<TransportClient> clientRef,
final AtomicReference<Channel> channelRef) {
bootstrap.handler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
TransportChannelHandler clientHandler = context.initializePipeline(ch);
encryptionHandler.addToPipeline(ch.pipeline(), true);
clientRef.set(clientHandler.getClient());
channelRef.set(ch);
}
});
}
{code}
This _initHandler_ method is called just before connection is made. In addition
the TransportEncryptionHandler interface has an _onConnect_ method to allow a
post connect initialization to occur, which in the SSL case, is to allow the
handshake process to complete, which is a blocking operation. This could be
possibly done in a custom TransportClientBootstrap implementation, but the
method signature of _doBootstrap_ would have to change to allow for this.
As for the TransportServer, the Netty SslHandler must be added to the pipeline
before the server binds to a port and starts listening for connections. Again,
in this case, this could be done in a TransportServerBootstrap implementation,
but the method signature of _doBootstrap_ would have to change (or we would
need to add another method) to allow for this... Thoughts?
Jeff
> 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]
