2023-10-27 - User Policies and Table Policies¶
Problem¶
Previously we squashed user policies into a json field on the members table which wasn’t very scalable and was complex to maintain as we were constantly parsing the json to work out which tables users had access policies for
Solution¶
Re architect policies into two new tables: table_policies to hold the table level policy information (ie sql predicates) with an interleaved table user_policies which holds the user level policies (a user policy is bound to 1 or many table policies. This makes the logic to lookup and apply policies alot simpler and co-locates the data in spanner for increased performance. At the same time implement a new cloud function apply_security_polices which is responsible for re-applying policies if a consume table is rebuilt (ie dropped and re-created), by running this function after any ‘Create Consume ….’ jobs we make sure new consume tables always have the latest policies applied. When re-applying we apply the table policies (incudes the default access for viewers and service accounts) then we apply the user level policies
Leverage the Magic¶
Leverage spanner config data for policies and cloud functions to re-apply security when required
Magician Partner¶
Re architect the securirty grain in spanner , policies becomes table_policies and split the policy json off the users table and into its own user_policies interleaved in table_policies (as a user may have multiple policies and nesting json is too technical)
Last Refreshed¶
Doc Refreshed: 2024-05-20