Multi-Region Row Level Security in CockroachDB

(cockroachlabs.com)

46 points | by rusticwizard 18 hours ago ago

14 comments

  • v5v3 42 minutes ago

    >You Shall Not Pass: Fine Grained Access Control with Row Level Security

    When you rug pulled your license, I could not pass.

    I'm sure it will be useful to your paying clients, who may be using RLS on their other DBs.

  • DSingularity 14 hours ago

    The first example demonstrating row level security contains results from the wrong tenant.

    • rusticwizard 12 hours ago

      Ah nice catch! This is an unfortunate copy paste error on the content on our part and we will fix it first thing tomorrow.

    • sebmellen 13 hours ago

      Is that true? I can’t quite follow it on mobile.

      • rsclarke 12 hours ago

        Yes, the example shows setting the current tenant id to all ones and then performing a select revealing a tenant id of all twos.

        The same result is displayed in another example when correctly using a tenant id of all twos. A mistake perhaps of wrong output with the wording in the article is all.

  • journal 13 hours ago

    Doesn't same database multi-tenancy defeats the one-tenant one-database advantage of being able to easily disaster recover a single tenant or allow for easily moving a tenant and all their stuff to a dedicated box?

    • esseph 13 hours ago

      At a certain scale they'd be sharded and not on a single instance anyway, right?

      • jandrewrogers 12 hours ago

        Even then, you do want to provide some degree of hardware-adjacent isolation to limit not just the blast radius but also computational cost of some DDL operations in a multi-tenant setup.

        For example, you generally only want to have one tenant’s data per storage page. There are many famous ways that interleaving different tenants’ data at a fine-grained level can go very wrong.

        • bob1029 2 hours ago

          Aggregating all tenants into the same tables could provide you with much more robust statistics for the query planner to use.

          There are also advantages from a cache utilization standpoint if the system is heavily loaded.

          • jandrewrogers an hour ago

            Having tenants in the same tables is compatible with their data being on separate pages.

            • bob1029 11 minutes ago

              I am arguing for the I/O benefit of sharing pages between tenants.

              I understand there are potential regulatory concerns with this, but I've never seen an audit get even remotely close to this level of detail.

      • journal 13 hours ago

        somewhere only in one place there will be main index with at least references to locations where to find others. at the top somewhere there is always just a flat list. this is a multi-dimensional problem. i really want to know real life scenario someone arguing for or against this. really interested to see what side people pick and where they draw the line of what it means to be multi-tenant. personally, i will never again write multi-tenant code ever again in my life. the implementation i've modeled for myself because i understood that immediate backup and restore is more important than fancy multi-tenancy.

  • sqlitor 9 hours ago

    What happens if an attacker executes `SET app.current_tenant` a second time on the existing connection (e.g. through SQL injection)?

  • jayzalowitz 15 hours ago

    well done!