Recettes

Chaque recette est un workflow autonome : un énoncé de problème, la configuration, et les commandes à exécuter. Copiez, adaptez, livrez.

Générer un dataset de debug depuis la production

Problème. Un bug en production référence orders.id = 982331. Vous voulez une copie locale qui inclut cette commande, ses users, ses order_items, et rien d’autre.

Configuration. fk_depth: 1 copie les lignes à un saut de clé étrangère de la commande — son utilisateur, ses lignes de commande — et, par défaut, chaque parent dont ces lignes ont besoin.

extraction:
  fk_depth: 1
  tables:
    - table: orders
      filter: "id = 982331"

anonymization:
  tables:
    - table: users
      columns:
        - name: id
          strategy: FPE_ID
        - name: email
          strategy: FAKE
          type: EMAIL

Exécution.

brume plan       # vérifier ce qui est tiré
brume execute    # livrer vers votre Postgres local

Comme FPE_ID est déterministe, votre bug à la source id = 982331 atterrira sur un id cible stable (par ex. 7831) à chaque fois. Référencez-le avec confiance dans vos notes de debug.

---

Rafraîchir le staging chaque semaine via CI/CD

Problème. Vous voulez que staging soit re-pseudonymisé chaque dimanche soir depuis prod.

Prérequis. Commitez votre brume.yml à la racine du dépôt (ou indiquez un autre chemin avec BRUME_CONFIG_PATH). Le job ci-dessous suppose qu’il est récupéré en même temps que le workflow.

Exemple GitHub Actions.

.github/workflows/refresh-staging.yml

name: Refresh staging from prod
on:
  schedule:
    - cron: '0 2 * * 0'  # Dimanche 02:00 UTC
  workflow_dispatch:

jobs:
  refresh:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4   # récupère brume.yml depuis le dépôt
      - name: Install pg_dump
        run: |
          # Version majeure de pg_dump >= celle de votre source prod (ici : Postgres 17)
          sudo apt-get update
          sudo apt-get install -y postgresql-client-17
      - name: Install Brume
        run: |
          curl -1sLf 'https://dl.cloudsmith.io/public/brume/brume/setup.deb.sh' | sudo -E bash
          sudo apt-get install -y brume
      - name: Run Brume
        env:
          BRUME_HMAC_SECRET:    ${{ secrets.BRUME_HMAC_SECRET }}
          BRUME_FPE_KEY:        ${{ secrets.BRUME_FPE_KEY }}
          BRUME_SOURCE_HOST:    ${{ secrets.PROD_HOST }}
          BRUME_SOURCE_DB:      app_production
          BRUME_SOURCE_USER:    brume_reader
          BRUME_SOURCE_PASSWORD: ${{ secrets.PROD_RO_PASSWORD }}
          BRUME_SCHEMA:         public
          BRUME_TARGET_HOST:    ${{ secrets.STAGING_HOST }}
          BRUME_TARGET_PORT:    5432           # défaut : 5460
          BRUME_TARGET_DB:      app_staging
          BRUME_TARGET_USER:    app
          BRUME_TARGET_PASSWORD: ${{ secrets.STAGING_PASSWORD }}
        run: |
          brume diag        # valide les secrets et la configuration
          brume plan
          brume execute

Utilisez --json si vous voulez publier des logs structurés comme artefacts.

---

Pseudonymiser les colonnes metadata JSONB

Problème. Votre users.metadata est un document JSONB qui contient contact.email, contact.phone et shipping.address. Le reste du document est sûr.

Configuration.

anonymization:
  tables:
    - table: users
      columns:
        - name: metadata
          strategy: FAKE
          type: JSONB
          json_paths:
            - path: $.contact.email
              type: EMAIL
            - path: $.contact.phone
              type: PHONE
            - path: $.shipping.address
              type: ADDRESS

Les autres chemins à l’intérieur de metadata sont conservés tels quels. Les chemins qui ne résolvent pas sur une ligne donnée sont ignorés silencieusement — mais brume dry-run signalerait un chemin qui ne résout jamais sur l’ensemble de la table.

---

Maintenir la cohérence entre bases de microservices

Problème. Votre service users stocke email ; votre service audit stocke user_email ; votre service marketing stocke notify_email. Aucune n’est reliée par une FK. Vous avez besoin que le même email réel atterrisse sur le même faux email dans les trois.

Configuration.

anonymization:
  linked_columns:
    - semantic_key: user_email
      columns:
        - table: users
          column: email
        - table: audit_logs
          column: user_email
        - table: marketing_subscriptions
          column: notify_email

Exécutez Brume indépendamment sur la base de chaque service avec le même BRUME_HMAC_SECRET — le groupe linked_columns garantit une sortie fictive identique.

---

Exporter vers un fichier .sql portable

Problème. Votre DPO veut revoir un export pseudonymisé hors ligne avant tout déploiement en production.

.env.brume. Générez-le avec brume init dump, puis renseignez :

BRUME_SINK_TYPE=DUMP
BRUME_SINK_OUTPUT_PATH=./out/pseudonymized.sql.gz
BRUME_SINK_COMPRESSION=GZIP     # NONE | GZIP | ZSTD
# Les variables BRUME_TARGET_* sont ignorées avec le sink DUMP

Exécution.

brume execute

Vous obtenez ./out/pseudonymized.sql.gz. Importez avec :

gunzip -c pseudonymized.sql.gz | psql -h ... -U ... -d ...

---

Multi-tenant — extraire les données d’un seul tenant

Problème. Votre schéma est multi-tenant sur tenant_id. Vous voulez ne livrer que le tenant 42.

Configuration.

extraction:
  fk_depth: 1
  tables:
    - table: tenants
      filter: "id = 42"
    - table: users
      filter: "tenant_id = 42"
    - table: orders
      filter: "tenant_id = 42"

Appliquez le filtre tenant_id = 42 sur chaque table racine du périmètre tenant, et gardez un fk_depth bas. fk_depth est un rayon dans les deux sens : depuis une ligne partagée par plusieurs tenants (un plan, un pays, un produit), un saut de plus vers le bas atteint les lignes d’autres tenants. Vérifiez les décomptes par table de brume plan avant de lancer execute.

---

Suite

• RGPD & conformité — checklist de validation.
• Exploitation & dépannage — performance, gestion des secrets, erreurs courantes.