[FEATURE REQUEST] Add Row Level and Column Level access control.

[silwalanish]

Is your feature request related to a problem? Please describe.

Is there a way to define row/column level access control through the RBAC defined here?

Describe the solution you'd like

With row level access control, I would like to filter certain rows from result set for a given Role. With column level access control, I would like to add data masking to certain columns for a given Role.

Describe alternatives you've considered

No response

Additional context

No response

[shohamyamin]

I think that the catalog should return when a resource is requested the row filter expression and the column mask expression that way the Trino/spark will be able to force the row filter/column mask.

the catalog itself cannot make the filter/masking because he isn’t the one that access to the object storage and do the compute

[snazy]

RLAC/CLAC is IMO a very useful functionality/feature to restrict access to sensitive information to trusted client (e.g. query engines). Masking/hiding is technically probably the more straght-forward part, but getting "trust" right is tricky.

A table (or view referencing such a table directly or indirectly) that has CLAC/RLAC enabled, must not be accessible to untrusted clients, simply because once you give those access, they technically see everything. Or the catalog would have to intercept (and rewrite) manifest-lists, manifest-files and data/delete files according to the user's privileges and R/CLAC rules (masking) - that's quite expensive.

However, if you have an engine/client that you really trust to securely apply the CLAC/RLAC filters, the catalog can grant access to it and rely on the engine/client to do the right thing.

"Trust" itself has very different meanings for different people. Some say they're fine with running queries only on that engine X, Y or Z. Others say that the engine must run on extremely locked down hardware, ensuring that malicious users must not even be able to use side-channel attacks to get (some) knowledge of the protected data.

Don't get me wrong, definitely don't wanna shoot this down or so - it's the opposite. Just saying, that there's a lot of work to do.

[johnnysohn]

@snazy there's an open proposal for extending Iceberg rest spec to support both row and column level access. Once that proposal is accepted maybe you guys can implement it on Polaris?