[ https://issues.apache.org/jira/browse/HBASE-28317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17809179#comment-17809179 ]
Charles Connell commented on HBASE-28317: ----------------------------------------- {quote}I know you plan to inspect the certificate in the coprocessor. That might involve string manipulation/comparisons (cert parsing, username comparisons, etc) and math (for ip subnet checking). Since a certificate is tied to a connection and can't change for the lifetime of the connection, it will be far preferable to do this once per connection instead of for every request. A single client can send many requests/sec, and a RegionServer in aggregate will serve thousands of req/s or more. Doing this work on-connection instead of on-request would save a lot of cpu time. Given that TLS is a new native feature of hbase, I think we should consider this as a configurable auth plugin of some sort rather than just expose it on RpcCallContext.{quote} I did consider this, but all of the work can be skipped by just caching the results of the work you describe. I can cache a mapping of "certificate signature -> business logic" on the first computation, and then not need to do to any work again for the life of that connection. The certificate parsing that gets me to the point of having the signature available is naturally done once per connection anyways, so that's not going to be done any more than necessary either. Now, this is all theoretically less elegant than a plugin system, but I don't think it's a good idea to add that much extra code to HBase for a use case that we don't really need. > 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)