Aller au contenu

Multitenant Storage

multitenant: true permet a un adapter storage de completer sa configuration depuis le TenantContext courant.

Principe

La config versionnee contient les defaults non sensibles. Le resolver tenant fournit les coordonnees propres au tenant: bucket, container, prefixe ou credentials cloud.

Text Only
1
2
3
auth -> tenant id -> TenantResolver -> TenantContext
                                      -> adapter storage
                                      -> cible tenant

Chaque adapter lit uniquement sa tranche de contexte: s3, azure-blob ou gcs.

Exemple De Contexte

Python
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
from arclith.adapters.context import set_tenant_context
from arclith.domain.models.tenant import AdapterTenantCoords, TenantContext

token = set_tenant_context(
    TenantContext(
        adapters={
            "s3": AdapterTenantCoords(
                params={
                    "bucket_name": "tenant-a-files",
                    "prefix": "uploads",
                    "region_name": "eu-west-3",
                }
            )
        }
    )
)
try:
    ...
finally:
    token.var.reset(token)

En production, le contexte est normalement pose par le pipeline d'auth ou par un resolver tenant, pas directement dans le use case.

Coordonnees Attendues

Adapter Coordonnees tenant
s3 bucket_name, prefix, region_name (region), endpoint_url, force_path_style, profile_name, aws_access_key_id (access_key_id), aws_secret_access_key (secret_access_key), aws_session_token (session_token)
azure-blob account_url, blob_service_url, container_name, container, prefix, connection_string, conn_str, account_key, storage_account_key, sas_token, use_default_credential, default_credential, managed_identity
gcs bucket_name, prefix, project_id, project, credentials_path, service_account_file, credentials_json, service_account_json, credentials_json_b64, service_account_json_b64

Les alias existent pour faciliter l'integration avec un Vault deja structure.

Strategies D'isolation

Strategie Quand l'utiliser
bucket/container par tenant forte isolation IAM/RBAC, lifecycle et quotas par tenant
prefixe par tenant mutualisation simple, a condition de policies tres bornees
credentials par tenant comptes ou roles differents selon client
volume ou deploiement filesystem par tenant dev ou on-prem avec isolation par runtime

La strategie doit etre coherente avec les contraintes de suppression, audit, facturation et restauration.

Points D'attention

  • Ne pas melanger les fichiers de plusieurs tenants dans un prefixe partage sans policy explicite.
  • Ne pas construire la cible tenant depuis une donnee utilisateur non verifiee.
  • Stocker les credentials tenant dans Vault ou un secret manager, jamais dans Git.
  • Tester chaque tenant avec une cle de smoke isolee, par exemple smoke/<tenant-id>/health.txt.

Suite

Lire Securite, puis la page du provider utilise: S3, Azure Blob ou GCS.