[
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)
