RLS versus een speciale database per project

Het meest gedocumenteerde patroon voor Postgres met meerdere tenants bestaat uit drie regels: een enkele basis, een kolom tenant_id in elke tabel, een RLS-beleid dat deze kolom vergelijkt met een waarde die is geëxtraheerd uit de JWT. Het is economisch – een verzameling verbindingen, een diagram, één exemplaar om uit te voeren – en het werkt goed als de huurders talrijk, klein en met een lage individuele inzet zijn.

Het compromis is reëel: de grens tussen twee clients wordt een SQL-expressie, tabel voor tabel geëvalueerd. Een beleid dat is vergeten op een nieuwe tafel, een verbinding die draait met een superuser-rol, een debug-script dat live wordt gelanceerd - elk van deze incidenten, hoe triviaal ook in werking, kan in stilte de regels van alle tenants tegelijkertijd blootleggen. De veiligheidsgrens en de technische grens (de basis) zijn dan precies hetzelfde.

Sinds een recente consolidatie van de provisioner (in de code gemarkeerd als "Taak 12") valt een actief Postgres-project bij Aurabase onder precies twee architecturen: de oude modellen met een basis die feitelijk door verschillende projecten wordt gedeeld, zijn uit het provisioningpad verwijderd.

pub enum ProjectInstanceKind {
    /// CNPG-cluster gewijd aan DIT ALLEEN-project (bedrijfsniveau).
    FullyDedicated,

    /// Database over de CNPG-cluster van het project ORGANISATIE —
    /// gedeeld met ANDERE projecten van DEZELFDE organisatie,
    ///nooit met een derde partij.
    SharedClusterDedicated,
}

Het projectniveau bepaalt welke van de twee van toepassing is – en het is de code die beslist, niet een vakje dat is aangevinkt in een dashboard:

fn should_provision_dedicated(engine: &str, db_url_encrypted: &Option<String>, plan: &str) -> bool {
    matches!(engine, "postgres" | "postgresql")
        && plan == "enterprise"
        && !non_empty(db_url_encrypted)
}

// Should_route_to_fleet(): elk niet-bedrijfsniveau (gratis/pro/team)
// route naar de CNPG-cluster van UW EIGEN organisatie, nooit die ene
// van een andere — zie migratie 073, consolidatie naar 2 architecturen.

Op beide architecturen huisvest de basis of het cluster nooit twee verschillende organisaties. De vraag is dus niet “zijn uw gegevens geïsoleerd” maar “heeft uw project de beschikking over CloudNativePG geheel voor zichzelf, of deelt het deze met andere projecten in dezelfde organisatie.”

Deze consolidatie van twee architecturen is recent: de code kende voorheen twee extra paden: een ‘gedeelde master’ waarbij verschillende projecten naast elkaar in dezelfde database bestonden, alleen geïsoleerd door middel van een diagram, en een postgrest_dedicated_shared_db-variant. Een speciale migratie verwijderde deze en verscherpte de beperking van de tabel projects tot alleen de twee resterende waarden, juist omdat het gedeelde schemamodel de bron was van de hieronder beschreven bug.

Een afzonderlijke Postgres-database is een grens op verbindingsniveau, geen grens op rijniveau. Een applicatierol die is verbonden met de database van project A kan simpelweg geen query uitvoeren op de tabellen van project B; er is geen sessie voor open. Deze eigenschap geldt zelfs als een RLS-beleid slecht is geschreven, ontbreekt in een tabel of wordt omzeild door een hoge rol: in het ergste geval blijft het beperkt tot één database.

Deze aanbetaling vertoont ook de sporen van een echte bug, wat het tegenovergestelde risico illustreert. Onder het oude gedeelde schemamodel (sindsdien ingetrokken), heeft provision_postgres_schema ten onrechte GRANT ALL ... TO PUBLIC rechten toegekend aan elk projectschema - PUBLIC door op alle rollen in de database toe te passen zonder lidmaatschapsvoorwaarden, kon een geïsoleerde login per project het schema van een ander project lezen en schrijven. Een corrigerende migratie (066) verwijderde deze rechten uit de bestaande.

Een patch van 23 augustus 2026 gaat in dezelfde richting: een REVOKE ALL ON SCHEMA public die onvoorwaardelijk door de provisioner werd geplaatst, werd voorwaardelijk gemaakt op basis van de topologie, omdat deze alleen echte isolatie bood op het oude gedeelde databasemodel - op de twee huidige architecturen blokkeerde deze zonder enig voordeel de import van SQL-dumps die expliciet verwijzen naar public.<table>.

Geen van de bovenstaande dingen maakt EPIRB nutteloos; het verandert alleen de vloer. Eenmaal in uw projectdatabase, geeft Aurabase precies de PostgREST-conventie weer die wordt gebruikt door Supabase: drie SQL-functies die de JWT-claims lezen die zijn ingesteld door de gateway in request.jwt.claims.

create function auth.uid() returns uuid
    language sql stable security definer
    set search_path to 'pg_catalog', 'pg_temp'
    as $$
    select nullif(nullif(current_setting('request.jwt.claims', true), '')::json->>'sub', '')::uuid
$$;

Deze helpers worden gebruikt in het daadwerkelijke beleid van Aurabase zelf – en niet alleen gedocumenteerd voor dat van u. Hier is het beleid dat storage_objectsbeschermt, zoals het in de repository is geplaatst (opnieuw geformatteerd op verschillende regels om te kunnen lezen):

alter table storage_objects enable row level security;

create policy storage_objects_select on storage_objects
  for select using (
    (owner_id = auth.uid())
    or (
      exists (
        select 1 from storage_buckets b
        where (b.name = storage_objects.bucket_name and b.public)
      )
    )
  );

In uw eigen project_<uuid>-schema, dat uw applicatietabellen bevat, plaatst Aurabase opzettelijk geen beleid namens u – de code documenteert het als een “Supabase-model”: de RLS van uw tabellen blijft uw verantwoordelijkheid, met dezelfde functies, dezelfde syntaxis.

Postgres biedt standaard een rolkenmerk, BYPASSRLS, dat al het beleid negeert. Aurabase gebruikt het vrijwillig voor twee rollenfamilies: aura_service_role (de serverrol, nooit zichtbaar aan de browserzijde) en de beheerrol die specifiek is voor elk project, gebruikt tijdens DDL-bewerkingen zoals ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Serverrol: nooit zichtbaar aan de browserzijde, nooit lid
-- rollen uit een ander project.

De rol die uw verzoeken vervult anon/authenticated — tenant_<uuid> — heeft geen BYPASSRLS: de RLS is er normaal gesproken op van toepassing, zonder uitzondering. Als bonus ontvangen de systeemdiagrammen die specifiek zijn voor elk project (_auth, _storage, _platform) een geactiveerde RLS zonder beleid - dus standaard een totale weigering voor elke niet-bypass-rol, een diepgaande verdediging voor het geval een applicatiepad er op een dag per ongeluk toegang toe krijgt.

Deze serverrol maakt deel uit van een bredere structuur – vooraf gedefinieerde rollen, aangepaste RBAC, auditlogboeken – gedetailleerd op de pagina Beveiliging en RBAC.

Op het SharedClusterDedicated-niveau bestaan verschillende projecten van dezelfde organisatie naast elkaar op één CNPG-cluster. De fysieke database scheidt de projecten al van elkaar, maar de PostgreSQL-rollen (zij) zijn globale objecten voor het cluster, niet voor de database. Aurabase voegt daarom een ​​laag toe: een aparte PostgreSQL login per project.

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}

// Standaard actief (F013_PER_PROJECT_AUTHENTICATOR), deactiveerbaar
// uitdrukkelijk als nooduitgang.

Elk project maakt verbinding met zijn eigen login, die alleen lid is van zijn eigen tenant_<uuid> / tenant_<uuid>_admin rollen - nooit die van een ander project in hetzelfde cluster. De database isoleert de gegevens al; Deze login per project isoleert ook de identiteit die ermee verbonden is, zodat een incident in een project de login geen lidmaatschap geeft dat kan worden overgenomen van een ander project.

De keuze voor Aurabase is geen universele regel – het is een compromis voor een specifiek geval: klanten van elkaar isoleren, mogelijk met verschillende compliance-eisen, op een platform waarover zij geen controle hebben. Als u uw eigen SaaS bouwt, rijst voor u dezelfde vraag, op een andere schaal.

• RLS met tenant_id in een gedeelde basis — relevant wanneer uw huurders talrijk zijn, individueel met een lage inzet, en de kosten van een basis per huurder onevenredig zouden zijn. Test elk beleid met pg_proveop elke tafel, zonder uitzondering.
• Speciale basis of diagram — relevant wanneer een huurder zijn eigen nalevingsprobleem heeft (gezondheid, HR, publieke sector), een volume dat prestatie-isolatie rechtvaardigt, of de kosten van een lek tussen twee specifieke clients niet in verhouding staan tot de kosten van extra infrastructuur.

Het prijsniveau van Aurabase past dezelfde arbitrage toe op zijn eigen klanten: standaard een gedeelde basis per organisatie, een speciaal cluster wanneer de uitdaging van het project dit rechtvaardigt. Voor RLS-patronen binnen uw eigen database (eigendom, multi-tenant per organisatie, rollenhiërarchie) beschrijft de RLS-handleiding in productie de drie gevallen met pgTAP-tests. En als de automatisch gegenereerde API in uw diagram u verder interesseert dan REST, dekt de vergelijking op pg_graphql versus Hasura en PostGraphile de andere helft van het Postgres-oppervlak dat door Aurabase wordt belicht.