Bauta

Put a mask on production: a safe, realistic stand-in for your production data, in whichever database you need it. Bauta masks what it copies, copies only the slice you need with every relationship intact, generates what may not be copied at all, and moves data between databases on a schedule you already run, with nothing to host.

• Masking: consistent across tables and runs, one-to-one for keys (NIST FF1 where policy requires it), applied before anything reaches the target, and every column must be covered.
• Discovery, subsets and synthetic data: propose a masking policy from a live schema, copy a referentially complete slice of production, create the copy's tables in whichever database it goes to, and fill tables that can't be copied with generated rows.
• Audit: report what every job does with data and what a reviewer should question, and seal each run's masking manifest so it can be verified later.
• Provable coverage: list every table in production and what the jobs do with each, so a table nobody wrote a job for fails the build rather than going unnoticed. A database can require that nothing reaches it unmasked.
• Seven databases: Oracle, SQL Server, PostgreSQL, MySQL, MariaDB, SQLite and DuckDB, as source or target in any combination.
• Files as a target: a masked copy in Parquet, CSV or JSON Lines, in a directory or in S3, Google Cloud Storage or Azure, for a data lake that Athena, Snowflake or Databricks reads: appended to incrementally or published whole as a snapshot, with nothing visible until a run succeeds.
• Iceberg tables: a masked copy as Iceberg tables in any of the three clouds, through a Glue, REST or SQL catalog: each run one commit, upserts that merge by key, and old snapshots' files deleted with them.
• Streaming: memory stays flat however large the table, and PostgreSQL and SQL Server targets load in bulk.
• Fast: a million rows of six masked columns, two of them one-to-one keys, in under 8 seconds on one core with the optional native masker, and 74 without; more cores for wide tables. Either way the masks are the same.
• Incremental loads: extract only what changed since the last successful run.
• A dependency graph: jobs run in order, concurrently where they can, each in its own process with an optional timeout.
• Operable: webhook alerts; run state, history and manifests each in a file or a table; and passwords from a command for cloud IAM tokens.
• No infrastructure: a pip install, some YAML, and a command you run from cron.

Install

Python 3.10 or newer. Choose the drivers you need as extras; each is loaded only when a connection uses it.

pip install "bauta[postgresql,oracle]"

The native masker (optional). bauta-rs masks in Rust: about ten times the throughput on one core, with identical masks. It can also mask on several cores: jobs.yaml's maskingThreads is 1 by default, a number up to the cores available, or auto to divide the cores between the jobs running (see masking threads). pip install "bauta[postgresql,native]" installs the version that matches, which is the only one Bauta uses. Without it, everything works, only slower. See the native masker.

Quickstart

Start from the configuration in example/starter/configuration/, from a clone or downloaded from GitHub:

mkdir configuration
cp example/starter/configuration/*.yaml configuration/

Edit configuration/connections.yaml and configuration/jobs.yaml for your databases, then supply the credentials they reference:

export SOURCE_DB_PASSWORD=...  TARGET_DB_PASSWORD=...  MASKING_KEY=...

bauta validate           # check the configuration, offline
bauta run --dry-run     # check connections and tables, moving nothing
bauta run                # run every job once

To see it work without any of that, the demos in a clone of this repository use throwaway SQLite databases:

git clone https://github.com/ribeiro11075/bauta.git && cd bauta
pip install -e ".[fpe]"

python example/walkthrough/demo.py       # the whole workflow: discover, subset, audit, mask, verify, synthesize
python example/incremental/demo.py       # streaming and incremental loads
python example/masking/demo.py           # masking, discovery and a subset, from Python
python example/native-masking/demo.py    # Python against Rust, and Rust on one core against all of them

The command

bauta run                run every job that's due, once
bauta validate           check the configuration, without connecting
bauta jobs               show the job graph and which jobs are due
bauta history            show recent job outcomes

bauta discover           propose a masking policy for tables
bauta subset             generate jobs that copy a referentially complete subset
bauta schema             create target tables from source ones, in the target's dialect
bauta synthesize         fill tables with generated rows, for data that can't be copied
bauta clear              empty the jobs' target tables, children first

bauta audit              report what each job does with data, and what to question
bauta coverage           list a source database's tables and what the jobs do with each
bauta verify-manifest    check a masking manifest is unaltered, and who signed it
bauta verify-references  count rows in the copy whose foreign key points at nothing

bauta --version          print the version, and which masker it would use

run makes one pass and exits, so it fits under cron or a Kubernetes CronJob. A second run sharing the same run state refuses to start while the first is still going. bauta <command> --help lists every flag.

Configuration and logging

Every command takes these.

Running jobs

Run state, history and the manifest

Each is kept in a file or in a database table, set in jobs.yaml or overridden for one run by its flags. A file set in jobs.yaml is relative to jobs.yaml; a file flag is relative to the working directory.

Tables default to bauta_memory, bauta_history and bauta_manifest, and must exist first; operations.md has their definitions. A manifest is signed when $BAUTA_MANIFEST_KEY is set.

Saying less, and saying it once

A defaults: block in jobs.yaml supplies what every job would otherwise repeat, so a job says only what is particular to it:

defaults:
  sourceConnection: prod
  targetConnection: staging
  insertStrategy: upsert
  masking:
    key: ${MASKING_KEY}

jobs:
  maskCustomers:
    sourceQuery: select id, email from customers
    targetTableFinal: customers
    masking:
      columns: {id: keep, email: email}

A masking policy's columns stays with its job, so what a job does to its data can be read in one place. Any field a file doesn't recognise is an error, so a misspelling stops bauta validate rather than being quietly ignored.

Proving the copy is safe

Proposing and reviewing policies

discover, subset --mask, audit and synthesize recognise personal data by built-in rules, and by rules of your own:

discover takes --all-tables for a whole database instead of a repeated --table, and discover/subset take --mask-keys to mask numeric surrogate keys as well as text ones, in the domain each foreign key already shares.

Environment variables

The ones you'd set in a deployment; operations.md also lists two for diagnosis.

Documentation

Layout

License

MIT