11–15 of 15 posts
It's not immediately clear to me where this is superior to BigQuery authorized views: https://cloud.google.com/bigquery/docs/authorized-views#row-... The comparison in the source doc ( https://cloud.google.com/bigquery/docs/row-level-security-in... ) seems to list the same caveats for both methods.
Earlier quoted context omitted.
As sibling mentioned, table and dataset level security. Another workaround I’ve seen used a lot is to create a view that filters out the rows and columns you’re not sharing with the entire organization. It’s slow and pricey and in most cases I would advocate to duplicate the filtered table, rather than doing a view.
Can you explain how authorised views reduce performance and increase costs?
I don't think row-level security will be any better based on this documentation.
It's not immediately clear to me where this is superior to BigQuery authorized views: https://cloud.google.com/bigquery/docs/authorized-views#row-... The comparison in the source doc ( https://cloud.google.com/bigquery/docs/row-level-security-in... ) seems to list the same caveats for both methods.
I think of row level security as enforced on the table which is stronger as it will apply for any reads on the table.
However, if you have authorized views then you can still create a different view of the same table without the access controls.
You can probably use both to solve the problem and in some cases authorized views maybe the right choice and in some cases row level security will work.
I'm confused, how was BigQuery achieving multi-tenancy without Row-Level Security?