mosiac1
commented
4 months ago Hello, I started looking into this and wanted to share my current though-process on possible approaches.
Calls to getColumnMask
Not including here calls from tests and calls from System/CatalogAccessControl implementations that mostly just delegate (I didn't spend a lot of time on these, please correct me if there is more functionality to consider).
io.trino.sql.analyzer.StatementAnalyzer.Visitor#visitInsertio.trino.sql.analyzer.StatementAnalyzer.Visitor#visitDeleteio.trino.sql.analyzer.StatementAnalyzer.Visitor#visitUpdateio.trino.sql.analyzer.StatementAnalyzer.Visitor#visitMergeio.trino.sql.analyzer.StatementAnalyzer.Visitor#visitTableExecuteio.trino.sql.analyzer.StatementAnalyzer.Visitor#analyzeFiltersAndMasks
All of these iterate over the columns in a table and call getColumMask on each column.
visitInsert/Delete/Update/Merge/TableExecute have pretty much the same code block:
for (ColumnMetadata tableColumn : tableMetadata.getColumns()) {
if (accessControl.getColumnMask(session.toSecurityContext(), tableName, tableColumn.getName(), tableColumn.getType()).isPresent()) {
throw semanticException(NOT_SUPPORTED, node, "ALTER TABLE EXECUTE is not supported for table with column masks");
}
}analyzeFiltersAndMasks actually uses the returned column masks.
Bulk getColumnMask?
As discussed in the slack thread, combining the fetching all of column masks needed for a query into a single call is hard to practically impossible. I think we can still get a good increase in performance by fetching the masks for all the columns in a given table in one pass.
The signature of the bulk function could look like the following (this isn't the best approach but it gets the point across, its pretty easy to add). The default implementation would delegate to getColumnMask.
List<Optional<ViewExpression>> getColumnMasks(SystemSecurityContext context, CatalogSchemaTableName tableName, List<Pair<String, Type>> columns);OPA access control plugin
This discussion began in the context of the OPA access control plugin, which does an HTTP call for every getColumnMask function call.
If the plugin would receive a bulk column masks call through the API there are two main ways of resolving it:
- send 1 HTTP requests to the OPA server for each column, but in parallel
- pros: no changes to policy code, no changes to Trino configs needed to benefit from speedup
- cons: high network traffic, limited by the number of connection the http client of the OPA access control plugin can have open at one time. we can assume that the OPA server is running as a sidecar to the Trino coordinator (i.e. on the same machine), which might make this manageable
- use a "bulk column masks" endpoint on the OPA server, similar to
opa.policy.batched-uriin concept- pros: low network traffic, less communication costs, less things that can break
- cons: additional logic needs to be implemented in Rego; Trino configuration needs to change
I don't know which of these is better.
Next steps
I will look into gathering some data on the performance of the current implementation and one (or both if I have time) of these "solutions".
Would love to hear the thoughts of the community on this!
cc: @vagaerg @dprophet
vagaerg
dprophet
dain
shohamyamin
Explanation: When applying column masking, redundant requests are triggered for every column, regardless of whether they are queried or not. This leads to unnecessary overhead as the system tries to get column masking on all table columns, even those not accessed by the query. Moreover, the current approach sends individual requests for each column, causing some performance slowdowns and unnecessary overhead for the authorization system(in my case OPA).
For example: A query for one column of a table with 250 columns will create 250 requests of getColumnMasking for opa
Proposed Solution:
Enhance Trino to execute getColumnMask only for relevant columns. Optimize Trino to make getColumnMask operation as bulk for all the relevant columns at once rather than send them individually for each column, thereby improving performance.
Relevant slack threads: https://trinodb.slack.com/archives/CGB0QHWSW/p1711991055481149 https://trinodb.slack.com/archives/CGB0QHWSW/p1711991466026649