Skip to content

Draft: POC enforce Organization Isolation based on `project_id` and `namespace_id` column on every table

Dylan Griffith requested to merge add-project-id-namespace-id-to-everything into master

What does this MR do and why?

Related to #394800 (closed) this is similar to !129889 (closed) but will allow adding any of:

  1. project_id
  2. namespace_id
  3. organization_id

to every table.

The way this POC works is by creating a Postgres constraint trigger that is executed when a new record is created. One trigger is created for every foreign key in the database and the validation asserts that the record on both sides of the foreign key are sharded ultimately to the same organization by recursing up project_id -> namespace_id -> organization_id.

This POC demonstrates how to enforce the isolation with a DB constraint but to be more robust we'd probably want to expand the constraint to be enforced with:

  1. Loose foreign keys
  2. All model associations that are within a Cell
  3. Validated on UPDATE as well but only if the sharding key or foreign keys change

This POC is complementary to !131968 (closed) which shows how these sharding keys might be used to traverse all the way down from namespace -> project -> all data related to all projects ... and therefore validate that all the records are indeed isolated to one top level namespace and would be safe to migrate to a new organization.

Screenshots or screen recordings

Screenshots are required for UI changes, and strongly recommended for all other merge requests.

Before After

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Dylan Griffith

Merge request reports