[
https://issues.apache.org/jira/browse/HBASE-28317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17810110#comment-17810110
]
ASF GitHub Bot commented on HBASE-28317:
----------------------------------------
bbeaudreault commented on code in PR #5644:
URL: https://github.com/apache/hbase/pull/5644#discussion_r1464019537
##########
hbase-server/src/main/java/org/apache/hadoop/hbase/ipc/NettyRpcServer.java:
##########
@@ -413,6 +415,19 @@ private void initSSL(ChannelPipeline p, boolean
supportPlaintext)
sslHandler.setWrapDataSize(
conf.getInt(HBASE_SERVER_NETTY_TLS_WRAP_SIZE,
DEFAULT_HBASE_SERVER_NETTY_TLS_WRAP_SIZE));
+ sslHandler.handshakeFuture().addListener(future -> {
Review Comment:
@Apache9 do you think a listener is the right approach here? I'm wondering
if we should instead pass the SSLHandler into NettyServerRpcConnection, and
directly call `handler.handshakeFuture().get()` in `setupHandlers()`. That way
it's more explicit that we have the certificate on the connection prior to
handling any requests. With the listener approach, I'm not 100% sure we can
guarantee that the listener is executed in the eventLoop prior to the
channelRead0 in NettyRpcServerPreambleHandler.
> RpcCallContext should expose client's TLS certificate
> -----------------------------------------------------
>
> Key: HBASE-28317
> URL: https://issues.apache.org/jira/browse/HBASE-28317
> Project: HBase
> Issue Type: Improvement
> Reporter: Charles Connell
> Assignee: Charles Connell
> Priority: Minor
>
> At my employer we plan on using a coprocessor to log information about some
> requests to HBase. For this to be useful to us, we need to know who each
> request is coming from. We use HBase's TLS support with mutual authentication
> to authenticate clients. I'd like a way to expose the client certificate used
> on a request to coprocessors. For setups using Kerberos authentication,
> RpcCall exposes the Kerberos principal shortname via {{getRequestUser()}}, so
> this would be the TLS equivalent to that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
