Awesome.
Thanks for all the input folks.
Andor
On Mon, 2024-06-10 at 15:24 -0400, Bryan Beaudreault wrote:
> I'm back at my computer now so was able to find the JIRA:
> https://issues.apache.org/jira/browse/HBASE-27326
>
> I ended up not tackling it partially for the reason Andrew mentions
>
I'm back at my computer now so was able to find the JIRA:
https://issues.apache.org/jira/browse/HBASE-27326
I ended up not tackling it partially for the reason Andrew mentions -- I
realized that even our use-case did not cleanly fit into the proposal
there. So instead we ended up exposing the
Cool.
I suggest hbase-examples because different organizations will embed a user
name or potenitally other details into certificate fields differently, so
there isn't a one size fits all solution. However HBase could provide a
worked example where the username is in CN.
On Mon, Jun 10, 2024 at
It probably helps here to recognize the similarities in management of client
certs in the usual mTLS architectures and the Kerberos TGT. Both are short
lived credentials that the client obtains from an authority using some kind of
secret that establishes its right to receive the credential and
We use mTLS with short lived certificates which are provided via an
authenticated certificate authority service (CAS) and only work for a
specific cluster. In order for someone to get a certificate, they must make
a request to CAS which verifies they are allowed to have a certificate for
the
On Sun, 2024-06-09 at 23:10 -0700, Andrew Purtell wrote:
> There is middle ground between your position and a blanket trust of
> connection header parameters from any client with a valid
> certificate...
> Certificates can carry additional information, including usernames,
> which
> would be
Generally speaking clients are not trustworthy, otherwise we didn't
need security at all, right?
Even if they're trustworthy, certificates and security credentials can
potentially be stolen. Following my previous example, Charlie is an
attacker and was able to break into Bob's account and has
Also, before this thread goes off on this particular tangent, I'd like to
go back to something Bryan mentioned in his earlier response.
> Based on how we use HBase in
> our environment, this is perfectly secure for our use-case. That may not
> work for everyone, and I did file a jira to add a
Like I said the successful verification of the certificate implies the
client is trustworthy, including what the client supplies in the header.
Now, if within your organization, you are distributing trusted certificates
to potentially untrustworthy software, that is a you problem, as they say.
It
Yeah. I think the key point here is that the client certificate
identifies the originating "host" and not the "user", hence we have the
client hostname verification built-in. The only thing that you can be
sure about when you do mTLS is that the request is coming from a
legitimate host.
Therefore
mTLS is totally unrelated to the username. It's whatever you'd typically
have without mTLS.
On Sun, Jun 9, 2024 at 1:38 PM Andor Molnar wrote:
> That is a completely fair point and I agree that from security
> perspective, the approach is safe enough.
>
> I'd just like to figure out what is the
That is a completely fair point and I agree that from security
perspective, the approach is safe enough.
I'd just like to figure out what is the username in this case? Linux
user id? Anything that comes from SASL layer based on the Hadoop stack?
Andor
On Fri, 2024-06-07 at 09:30 -0700,
Most users who would employ a mTLS authentication scheme would operate with
this trust model. The fact the client has a valid signed certificate means it
can be trusted, and that trust includes supplied connection metadata like
username. Or, if not, then not.
So then a lot of security
You're sort of correct. We've been using mTLS in prod for a while now, ever
since the feature was committed. It's true that the actual HBase username
is not verified with mTLS, however you still can authenticate the
connection. The idea behind mTLS is that the certificate carries the
Hi Bryan / Hbase devs,
Based on the changes when you added mTLS support in HBASE-27280 [1],
only the certificate and hostname verification part were added to the
codebase. HBase doesn't actually authenticates the user when mTLS is
being used.
In other words some other auth method Simple or
15 matches
Mail list logo
