RLS et base dédiée par projet : le choix d’isolation multi-tenant d’Aurabase

Le pattern le plus documenté pour du multi-tenant Postgres tient en trois lignes : une seule base, une colonne tenant_id sur chaque table, une policy RLS qui compare cette colonne à une valeur extraite du JWT. C’est économique — un pool de connexions, un schéma, une seule instance à faire tourner — et ça marche bien quand les tenants sont nombreux, petits, et de faible enjeu individuel.

Le compromis est réel : la frontière entre deux clients devient une expression SQL, évaluée table par table. Une policy oubliée sur une nouvelle table, une connexion qui tourne avec un rôle superuser, un script de debug lancé en direct — chacun de ces incidents, pourtant banals en exploitation, peut exposer silencieusement les lignes de tous les tenants en même temps. La frontière de sécurité et la frontière technique (la base) sont alors exactement la même chose.

Depuis une consolidation récente du provisioner (repérée dans le code comme « Task 12 »), un projet Postgres actif chez Aurabase relève d’exactement deux architectures — les anciens modèles à base réellement partagée entre plusieurs projets ont été retirés du chemin de provisioning.

pub enum ProjectInstanceKind {
    /// Cluster CNPG dédié à CE SEUL projet (palier entreprise).
    FullyDedicated,
    /// Database sur le cluster CNPG de l'ORGANISATION du projet —
    /// partagée avec les AUTRES projets de la MÊME organisation,
    /// jamais avec une organisation tierce.
    SharedClusterDedicated,
}

Le palier du projet décide laquelle des deux s’applique — et c’est le code qui tranche, pas une case cochée dans un 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() : tout palier non-entreprise (free/pro/team)
// route vers le cluster CNPG de SA PROPRE organisation, jamais celui
// d'une autre — voir migration 073, consolidation à 2 architectures.

Sur les deux architectures, la base ou le cluster n’héberge jamais deux organisations différentes — la question n’est donc pas « vos données sont-elles isolées » mais « votre projet a-t-il du compute CloudNativePG pour lui seul, ou le partage-t-il avec d’autres projets de la même organisation ».

Cette consolidation à deux architectures est récente : le code portait auparavant deux voies supplémentaires — un « master partagé » où plusieurs projets cohabitaient dans la même base, isolés uniquement par schéma, et une variante postgrest_dedicated_shared_db. Une migration dédiée les a retirées et resserré la contrainte de la table projects aux deux seules valeurs restantes, précisément parce que le modèle à schémas partagés était la source du bug décrit plus bas.

Une base Postgres distincte est une frontière au niveau connexion, pas au niveau ligne. Un rôle applicatif connecté à la base du projet A ne peut tout simplement pas interroger les tables du projet B — il n’a pas de session ouverte dessus. Cette propriété tient même si une policy RLS est mal écrite, absente sur une table, ou contournée par un rôle élevé : le pire cas reste confiné à l’intérieur d’une seule base.

Ce dépôt porte d’ailleurs la trace d’un vrai bug qui illustre le risque inverse. Sous l’ancien modèle à schémas partagés (retiré depuis), provision_postgres_schema accordait par erreur des droits GRANT ALL ... TO PUBLIC sur chaque schéma de projet — PUBLIC s’appliquant à tout rôle de la base sans condition d’appartenance, un login isolé par projet pouvait lire et écrire dans le schéma d’un autre. Une migration correctrice (066) a retiré ces droits sur l’existant.

Un correctif du 23 août 2026 va dans le même sens : un REVOKE ALL ON SCHEMA public posé sans condition par le provisioner a été rendu conditionnel à la topologie, parce qu’il n’apportait une isolation réelle que sur l’ancien modèle à base partagée — sur les deux architectures actuelles, il bloquait sans bénéfice l’import de dumps SQL qui référencent explicitement public.<table>.

Rien de ce qui précède ne rend la RLS inutile — elle change simplement d’étage. Une fois dans votre base de projet, Aurabase expose exactement la convention PostgREST reprise par Supabase : trois fonctions SQL qui lisent les claims du JWT posés par la gateway dans 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
$$;

Ces helpers sont utilisés dans les policies réelles d’Aurabase elle-même — pas seulement documentés pour les vôtres. Voici la policy qui protège storage_objects, telle qu’elle est posée dans le dépôt (reformatée sur plusieurs lignes pour la lecture) :

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)
      )
    )
  );

Dans votre propre schéma project_<uuid>, celui qui porte vos tables applicatives, Aurabase ne pose délibérément aucune policy à votre place — le code le documente comme « modèle Supabase » : la RLS de vos tables reste de votre responsabilité, avec les mêmes fonctions, la même syntaxe.

Postgres propose nativement un attribut de rôle, BYPASSRLS, qui ignore toutes les policies. Aurabase l’utilise volontairement sur deux familles de rôles : aura_service_role (le rôle serveur, jamais exposé côté navigateur) et le rôle d’administration propre à chaque projet, utilisé le temps d’opérations DDL comme ALTER SCHEMA ... OWNER TO.

create role aura_service_role nologin bypassrls;
-- Rôle serveur : n'est jamais exposé côté navigateur, jamais membre
-- des rôles d'un autre projet.

Le rôle qui sert vos requêtes anon/authenticated — tenant_<uuid> — n’a lui aucun BYPASSRLS : la RLS s’y applique normalement, sans exception. En prime, les schémas système propres à chaque projet (_auth, _storage, _platform) reçoivent une RLS activée sans policy — donc un refus total par défaut pour tout rôle non-bypass, une défense en profondeur au cas où un chemin applicatif y accéderait un jour par erreur.

Ce rôle serveur s’inscrit dans une posture plus large — rôles prédéfinis, RBAC custom, audit logs — détaillée sur la page Sécurité & RBAC.

Sur le palier SharedClusterDedicated, plusieurs projets d’une même organisation cohabitent sur un cluster CNPG unique. La base physique sépare déjà les projets entre eux, mais les rôles PostgreSQL — eux — sont des objets globaux au cluster, pas à la base. Aurabase ajoute donc une couche : un login PostgreSQL distinct par projet.

pub fn project_authenticator_role(project_id: &str) -> String {
    format!("project_{}_authenticator", project_id.replace('-', '_'))
}
// Actif par défaut (F013_PER_PROJECT_AUTHENTICATOR), désactivable
// explicitement en échappatoire de secours.

Chaque projet se connecte avec son propre login, membre uniquement de ses propres rôles tenant_<uuid> / tenant_<uuid>_admin — jamais de ceux d’un autre projet du même cluster. La base isole déjà les données ; ce login par projet isole en plus l’identité qui s’y connecte, pour qu’un incident sur un projet ne donne à son login aucune appartenance à hériter vers un autre.

Le choix d’Aurabase n’est pas une règle universelle — c’est un compromis pour un cas précis : isoler des clients entre eux, potentiellement avec des exigences de conformité différentes, sur une plateforme qu’ils ne contrôlent pas. Si vous construisez votre propre SaaS, la même question se pose à vous, à une échelle différente.

• RLS avec tenant_id dans une base partagée — pertinent quand vos tenants sont nombreux, individuellement de faible enjeu, et que le coût d’une base par tenant serait disproportionné. Testez chaque policy avec pg_prove, sur chaque table, sans exception.
• Base ou schéma dédié — pertinent dès qu’un tenant a un enjeu de conformité propre (santé, RH, secteur public), un volume qui justifie l’isolation des performances, ou que le coût d’une fuite entre deux clients spécifiques serait disproportionné face au coût d’infrastructure supplémentaire.

Le palier tarifaire d’Aurabase applique ce même arbitrage à ses propres clients : base partagée par organisation par défaut, cluster dédié quand l’enjeu du projet le justifie. Pour les patterns RLS à l’intérieur de votre propre base — ownership, multi-tenant par organisation, hiérarchie de rôles — le guide RLS en production détaille les trois cas avec des tests pgTAP. Et si l’API auto-générée sur votre schéma vous intéresse au-delà de REST, le comparatif sur pg_graphql face à Hasura et PostGraphile couvre l’autre moitié de la surface Postgres exposée par Aurabase.