Filed a Jira ticket for this and I started to work on it. https://issues.apache.org/jira/browse/HBASE-28952
Andor On Fri, 2024-09-20 at 15:03 -0700, Andrew Purtell wrote: > I would accept a coprocessor hook addition for connection > establishment, or rejecting same, provided the customary backwards > compatibility provisions are made to avoid binary compatibility > problems and minimize source level changes for interface > implementers. I can’t speak for other committers but you would have > my +1. > > > On Sep 19, 2024, at 7:07 AM, Charles Connell > > <cconn...@hubspot.com.invalid> wrote: > > > > Hi Andor, > > > > I don't believe there is a way for a coprocessor or other plugin to > > hook into connection establishment and reject connections. If you > > were > > interested, I imagine that contributing this change would be > > appreciated by the core team, but I don't speak for them. > > > > As a workaround for now, you would need to block specific > > operations > > via coprocessor implementations of the various *Observer interfaces > > like RegionObserver and others. Once there, you can call > > RpcServer.getCurrentCall() to get an RpcCallContext object. > > > > > > Charles > > > > > On Tue, Aug 27, 2024 at 10:03 AM Andor Molnar <an...@apache.org> > > > wrote: > > > > > > Hi Andrew / Bryan, > > > > > > I'm looking at how to implement this client cert user/group > > > verification stuff that we talked about here, but I have to admit > > > I > > > have no idea how to do this properly. Could you please give me > > > some > > > pointers? > > > > > > In @charlesconnel's PR [1] about adding client cert chain to > > > RpcCallContext he mentions that it was needed for some kind of > > > audit > > > logging, though in the Jira ticket [2] we'd like to extend the > > > authentication flow and prevent users from connecting with > > > invalid > > > certificates. > > > > > > The closest I've found so far is the AccessController coprocessor > > > which > > > implements _all_ interface methods to verify access. That is a > > > bit > > > scary. Is there a way to catch all login attempts somehow and > > > access > > > RpCallContext from there? > > > > > > Thanks, > > > Andor > > > > > > [1] https://github.com/apache/hbase/pull/5644 > > > [2] https://issues.apache.org/jira/browse/HBASE-27326 > > > > > > > > > > > > > > > > On Mon, 2024-06-10 at 21:46 +0200, Andor Molnar wrote: > > > > 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 > > > > > realized that even our use-case did not cleanly fit into the > > > > > proposal > > > > > there. So instead we ended up exposing the actual certificate > > > > > chain > > > > > [1] in > > > > > the RpcCallContext, so that a user can make their own > > > > > implementation > > > > > using > > > > > coprocessors, etc to do whatever they like. > > > > > > > > > > [1] https://issues.apache.org/jira/browse/HBASE-28317 > > > > > > > > > > On Mon, Jun 10, 2024 at 3:05 PM Andrew Purtell > > > > > <apurt...@apache.org > > > > > > > > > > > wrote: > > > > > > > > > > > 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 12:32 AM Andor Molnar > > > > > > <an...@apache.org> > > > > > > wrote: > > > > > > > > > > > > > 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 protected by the signature. Sometimes this is > > > > > > > > done. > > > > > > > > HBase > > > > > > > > doesn't > > > > > > > > implement it (yet) and if you have a trust architecture > > > > > > > > that > > > > > > > > demands > > > > > > > > it, it > > > > > > > > would establish the username as attested by an > > > > > > > > authority, > > > > > > > > like > > > > > > > > a > > > > > > > > kerberos > > > > > > > > ticket. You'd use a netty API presumably in a > > > > > > > > coprocessor > > > > > > > > hook > > > > > > > > to get > > > > > > > > it in > > > > > > > > order to hand off to UGI. Should someone decide this is > > > > > > > > needed > > > > > > > > it > > > > > > > > would > > > > > > > > make a good contribution back to the project, somewhere > > > > > > > > in > > > > > > > > hbase- > > > > > > > > examples > > > > > > > > perhaps. > > > > > > > > > > > > > > Exactly. That's what I wanted to clarify and pointed what > > > > > > > other > > > > > > > projects (like ZooKeeper) are doing under the hood of > > > > > > > x509 > > > > > > > authentication. I definitely would like to contribute > > > > > > > something > > > > > > > similar > > > > > > > for HBase too. > > > > > > > > > > > > > > Thanks for the pointer of hbase-examples. > > > > > > > > > > > > > > Andor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 9, 2024 at 10:57 PM Andrew Purtell < > > > > > > > > apurt...@apache.org> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > 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 is absolutely not true that kerberos > > > > > > > > > authentication is > > > > > > > > > *required* when > > > > > > > > > using mTLS. Frankly I'd prefer you expand on such > > > > > > > > > comments > > > > > > > > > to > > > > > > > > > explain why > > > > > > > > > you might have untrustworthy clients operating in > > > > > > > > > your > > > > > > > > > production > > > > > > > > > as > > > > > > > > > opposed to another organization with competent > > > > > > > > > operations > > > > > > > > > and > > > > > > > > > better > > > > > > > > > controls. Otherwise this flirts with F.U.D. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, Jun 9, 2024 at 10:07 PM Andor Molnar < > > > > > > > > > an...@apache.org> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > 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 you still need a secure authentication > > > > > > > > > > method > > > > > > > > > > in > > > > > > > > > > order > > > > > > > > > > to > > > > > > > > > > prevent legitimate users to impersonate each other. > > > > > > > > > > > > > > > > > > > > For instance, you have Alice and Bob valid users > > > > > > > > > > both > > > > > > > > > > having > > > > > > > > > > trusted > > > > > > > > > > client certificates. They both can make requests > > > > > > > > > > from > > > > > > > > > > legitimate > > > > > > > > > > hosts, > > > > > > > > > > but with SIMPLE auth they're free to lie about > > > > > > > > > > their > > > > > > > > > > valid > > > > > > > > > > usernames. > > > > > > > > > > > > > > > > > > > > As far as I know, the only secure authentication > > > > > > > > > > option > > > > > > > > > > for > > > > > > > > > > HBase > > > > > > > > > > is > > > > > > > > > > Kerberos, so you still have to use it. Using mTLS > > > > > > > > > > will > > > > > > > > > > prevent > > > > > > > > > > attackers from making requests from ordinary hosts > > > > > > > > > > by > > > > > > > > > > stoling > > > > > > > > > > Kerberos > > > > > > > > > > tokens. > > > > > > > > > > > > > > > > > > > > Andor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Sun, 2024-06-09 at 13:45 -0400, Bryan > > > > > > > > > > Beaudreault > > > > > > > > > > wrote: > > > > > > > > > > > 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 < > > > > > > > > > > > an...@apache.org> > > > > > > > > > > > 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 > > > > > > > > > > > > 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, Andrew > > > > > > > > > > > > Purtell > > > > > > > > > > > > wrote: > > > > > > > > > > > > > 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 engineering effort > > > > > > > > > > > > > goes > > > > > > > > > > > > > in > > > > > > > > > > > > > to > > > > > > > > > > > > > protecting > > > > > > > > > > > > > the trust established by certificate > > > > > > > > > > > > > distribution, > > > > > > > > > > > > > like > > > > > > > > > > > > > using > > > > > > > > > > > > > short > > > > > > > > > > > > > lived certs, and secure distribution methods. > > > > > > > > > > > > > > > > > > > > > > > > > > > On Jun 7, 2024, at 6:34 AM, Bryan > > > > > > > > > > > > > > Beaudreault < > > > > > > > > > > > > > > bbeaudrea...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > authentication -- so a client will need a > > > > > > > > > > > > > > certificate > > > > > > > > > > > > > > which has > > > > > > > > > > > > > > been signed > > > > > > > > > > > > > > by the same CA (or at least within the CA > > > > > > > > > > > > > > chain) > > > > > > > > > > > > > > which > > > > > > > > > > > > > > signed > > > > > > > > > > > > > > the > > > > > > > > > > > > > > server's > > > > > > > > > > > > > > certificate, and vise versa. > > > > > > > > > > > > > > > > > > > > > > > > > > > > For us, if someone has a valid certificate > > > > > > > > > > > > > > and > > > > > > > > > > > > > > the > > > > > > > > > > > > > > mTLS > > > > > > > > > > > > > > authentication > > > > > > > > > > > > > > succeeds, then we just trust their > > > > > > > > > > > > > > username. > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > feature > > > > > > > > > > > > > > for > > > > > > > > > > > > > > validating > > > > > > > > > > > > > > the username (perhaps pulling from a custom > > > > > > > > > > > > > > certificate > > > > > > > > > > > > > > property). > > > > > > > > > > > > > > But I > > > > > > > > > > > > > > haven't actually implemented that, and not > > > > > > > > > > > > > > sure > > > > > > > > > > > > > > that I > > > > > > > > > > > > > > will > > > > > > > > > > > > > > since > > > > > > > > > > > > > > it works > > > > > > > > > > > > > > as-is for us. > > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm on mobile now so I can't find it, but > > > > > > > > > > > > > > it > > > > > > > > > > > > > > should > > > > > > > > > > > > > > be > > > > > > > > > > > > > > findable > > > > > > > > > > > > > > in > > > > > > > > > > > > > > jira if > > > > > > > > > > > > > > you search the tls-related tickets > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jun 7, 2024 at 8:53 AM Andor > > > > > > > > > > > > > > > Molnar < > > > > > > > > > > > > > > > an...@apache.org > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > Kerberos is > > > > > > > > > > > > > > > still > > > > > > > > > > > > > > > needed to identify the HBase user, > > > > > > > > > > > > > > > because mTLS > > > > > > > > > > > > > > > doesn't > > > > > > > > > > > > > > > extract > > > > > > > > > > > > > > > identity information from the client > > > > > > > > > > > > > > > certificate > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > doesn't > > > > > > > > > > > > > > > map > > > > > > > > > > > > > > > it to > > > > > > > > > > > > > > > an active HBase user. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Is that correct? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > > Andor > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > https://issues.apache.org/jira/browse/HBASE-27280 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Best regards, > > > > > > Andrew > > > > > > > > > > > > Unrest, ignorance distilled, nihilistic imbeciles - > > > > > > It's what we’ve earned > > > > > > Welcome, apocalypse, what’s taken you so long? > > > > > > Bring us the fitting end that we’ve been counting on > > > > > > - A23, Welcome, Apocalypse > > > > > > > >
