Expose an API to get all ACLs

[Lars Francke]

Hi,

I have a use-case for a customer who's looking to build an audit tool. This
audit tool should build a report of all authorizations across various
products. HBase is one of them.

Unfortunately in HBase it's not currently possible to list all ACLs without
going directly to the _hbase:acl_ table (unless I'm missing something,
which would be great).

I see that the AccessControlLists class has a loadAll method but it's not
exposed anywhere.

Are there any objections in adding a method to retrieve all ACLs across all
tables etc.? I'm not yet 100% sure on the permissions that should be
required to do this. Any opinions?
Global + Access or something similar?

Cheers,
Lars

[Reid Chan]

What about extracting those infos from HBase's audit logs?

Retrieving all ACLs sounds hard if cell level ACLs is included, otherwise is feasible.

But from system security perspective, exposing all ACLs is not a secure behavior, though we can limit the api level to (Global|Namespace|Table|).Admin permission only.


--------------------------

Best regards,
R.C



________________________________________
From: Lars Francke <***@gmail.com>
Sent: 28 November 2018 03:03
To: ***@hbase.apache.org
Subject: Expose an API to get all ACLs

Hi,

I have a use-case for a customer who's looking to build an audit tool. This
audit tool should build a report of all authorizations across various
products. HBase is one of them.

Unfortunately in HBase it's not currently possible to list all ACLs without
going directly to the _hbase:acl_ table (unless I'm missing something,
which would be great).

I see that the AccessControlLists class has a loadAll method but it's not
exposed anywhere.

Are there any objections in adding a method to retrieve all ACLs across all
tables etc.? I'm not yet 100% sure on the permissions that should be
required to do this. Any opinions?
Global + Access or something similar?

Cheers,
Lars

[Lars Francke]

Reid, thanks for your input. Answers inline.

Post by Reid Chan
What about extracting those infos from HBase's audit logs?

I have to admit that I didn't even think about the audit logs and I'm not
sure what they expose in terms of ACLs but either way we won't have all
audit logs from the beginning of time so we'll miss some ACLs. Therefore
this is not an option for us.

Post by Reid Chan
Retrieving all ACLs sounds hard if cell level ACLs is included, otherwise is feasible.

Yes, another good point. I'd limit myself to the ACLs stored in the acl
table for now. That is because my client does not use Cell Level ACLs or
Visibility Labels. I know that those are long standing open issues[1] which
I don't intent to tackle.

Post by Reid Chan
But from system security perspective, exposing all ACLs is not a secure
behavior, though we can limit the api level to
(Global|Namespace|Table|).Admin permission only.

I thought about that and I'm not sure. I added a similar API to NiFi and
Kafka also has one now and while this information definitely is sensitive
there are already people who can see this data today, it just requires more
work. Agreed on the permissions!


[1] <https://issues.apache.org/jira/browse/HBASE-12470>

Post by Reid Chan
--------------------------
Best regards,
R.C
________________________________________
Sent: 28 November 2018 03:03
Subject: Expose an API to get all ACLs
Hi,
I have a use-case for a customer who's looking to build an audit tool. This
audit tool should build a report of all authorizations across various
products. HBase is one of them.
Unfortunately in HBase it's not currently possible to list all ACLs without
going directly to the _hbase:acl_ table (unless I'm missing something,
which would be great).
I see that the AccessControlLists class has a loadAll method but it's not
exposed anywhere.
Are there any objections in adding a method to retrieve all ACLs across all
tables etc.? I'm not yet 100% sure on the permissions that should be
required to do this. Any opinions?
Global + Access or something similar?
Cheers,
Lars

[Stack]

Post by Lars Francke
Hi,
I have a use-case for a customer who's looking to build an audit tool. This
audit tool should build a report of all authorizations across various
products. HBase is one of them.
Unfortunately in HBase it's not currently possible to list all ACLs without
going directly to the _hbase:acl_ table (unless I'm missing something,
which would be great).
I see that the AccessControlLists class has a loadAll method but it's not
exposed anywhere.
Are there any objections in adding a method to retrieve all ACLs across all
tables etc.? I'm not yet 100% sure on the permissions that should be
required to do this. Any opinions?
Global + Access or something similar?

Yeah. Not surprised given this an 'internal' table.

As long as there are perms on access to your new method, should be good to
add. Anything else would be a hack I'd say Lars (reading the echo of loaded
ACLs out to zk... or trying to read the 'internal' acl table yourself).

Thanks,
S

Post by Lars Francke
Cheers,
Lars

[Lars Francke]

Post by Lars Francke

Post by Lars Francke
Hi,
I have a use-case for a customer who's looking to build an audit tool.

This

Post by Lars Francke
audit tool should build a report of all authorizations across various
products. HBase is one of them.
Unfortunately in HBase it's not currently possible to list all ACLs

without

Post by Lars Francke
going directly to the _hbase:acl_ table (unless I'm missing something,
which would be great).
I see that the AccessControlLists class has a loadAll method but it's not
exposed anywhere.
Are there any objections in adding a method to retrieve all ACLs across

all

Post by Lars Francke
tables etc.? I'm not yet 100% sure on the permissions that should be
required to do this. Any opinions?
Global + Access or something similar?

Yeah. Not surprised given this an 'internal' table.
As long as there are perms on access to your new method, should be good to
add. Anything else would be a hack I'd say Lars (reading the echo of loaded
ACLs out to zk... or trying to read the 'internal' acl table yourself)

Thanks!
I agree on other methods being a hack (and relying on implementation
details).

Perfect. In that case I'll propose the solution for my client hoping he'll
sponsor the work.

Cheers,
Lars

Post by Lars Francke
Thanks,
S

Post by Lars Francke
Cheers,
Lars