Deploy the demo for the first time¶

This guide creates the project catalog and fixed v1 secret, provisions the three persona groups, builds all governed relations, and applies the access contract.

Use it once for a new target. For routine job deployment, use Deploy and run the Databricks bundle.

Prerequisites¶

Complete Configure a development environment. The authenticated caller must be allowed to create a Unity Catalog catalog, account groups and users, SQL functions, and the Databricks secret scope. openssl is required to generate the pepper.

Load the reviewed target values:

set -a
source .env
set +a

Danger

The example environment targets the canonical bricksgdpr catalog. Confirm DBT_PROJECT_CATALOG, DATABRICKS_EXPECTED_HOST, and DATABRICKS_EXPECTED_CALLER before any mutating command.

Create the catalog¶

uv run dbt run-operation bootstrap_project_catalog

The operation executes create catalog if not exists for DBT_PROJECT_CATALOG.

Check for an existing `v1` pepper¶

List the secret scopes first:

databricks secrets list-scopes --profile bricksgdpr

If bricksgdpr is absent, create it:

databricks secrets create-scope bricksgdpr --profile bricksgdpr

Now list the keys in that scope:

databricks secrets list-secrets bricksgdpr --profile bricksgdpr

Danger

If pepper_v1 appears, stop. Do not run put-secret: that command can overwrite an existing value, which would silently change the meaning of every future v1: key.

Create the `v1` pepper once¶

Only after confirming that pepper_v1 is absent, create it:

openssl rand -base64 48 \
  | databricks secrets put-secret bricksgdpr pepper_v1 --profile bricksgdpr

The command pipes the generated secret directly to Databricks. It does not belong in .env, dbt variables, logs, tags, or tables.

Warning

Never overwrite bricksgdpr/pepper_v1 in place. The pseudonymize_personal_data_v1 function and every v1: key depend on that immutable pairing. Rotation requires a new versioned key, wrapper, and parallel columns.

The repository references the fixed scope and key, but it does not prevent an operator from overwriting the secret or test the secret-scope ACL. Immutability and the rule that only the deployment identity receives secret READ are external operator controls that must be reviewed and audited separately.

Provision the persona topology¶

Follow Provision persona identities. For the repository-owned demo users, select synthetic mode and return here after the post-apply preflight passes.

Build relations and reconcile privileges¶

Run the sequence in this order:

uv run dbt build --exclude tag:access_control
uv run dbt run-operation apply_access_controls
uv run dbt test --select tag:access_control
uv run dbt build

The initial build creates the relations and applies their relation-level SELECT grants. The operation then grants required parent USE privileges and revokes broad or internal-function access. The access tests compare live Unity Catalog metadata with the exact allowlist.

Validate the data plane¶

scripts/validate_personas.sh --apply

This creates three temporary service principals, runs the positive and expected-denial SQL tasks, then deletes the principals and uploaded workspace files. See Validate persona access before running it.

Confirm the deployment¶

Use Build and explore the demo to check the current fixture counts and inspect the governed layers.

For the exact schema and reader matrix, consult Catalogs and schemas. Read Demo and production boundaries before adapting this single-deployer target to a shared environment.