Multi-Region Row Level Security in CockroachDB

https://www.cockroachlabs.com/blog/fine-grained-access-control-row-level-security/

by rusticwizard • 1 year ago

50 16 1 year ago

cockroachlabs.com

jayzalowitz• 1 year ago

well done!

DSingularity• 1 year ago

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

sebmellen• 1 year ago

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

rsclarke• 1 year 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.

rusticwizard2• 1 year 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.

journal2• 1 year 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• 1 year ago

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

journal2• 1 year 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.

jandrewrogers2• 1 year 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.

v5v32• 1 year ago

Haven't looked at their offering but a lot of cloud managed db's charge per dB rather than a virtual server grouping.

So there will be a cost per dB A cost to backup that dB Etc

And so a lot of companies, particularly startup, will keep one large dB.

sqlitor• 1 year ago

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

rusticwizard2• 1 year ago

If you go the session variable route and are concerned about SQL injection, this paradigm won't likely work for you. However, you can replace the session variable with a role per tenant which avoids the scenario you are describing. The caveat there is that you will now have to manage a role per tenant which can be troublesome if you are trying to pack lots of tenants.

We're planning to introduce an immutable session variable later this year to make the session-based approach more viable. It won't stop someone from tampering with the tenant_id before it's initially set, but it will prevent any changes afterward. Though in practice, most of our customers aren’t too concerned. They have application-layer guardrails in place and are confident that users can’t tamper with session state directly.

But yes, there are trade offs either way.

v5v32• 1 year 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.

Multi-Region Row Level Security in CockroachDB

Related Stories