Appearance
Governance & access
Two layers of access
| Layer | Controls | Where |
|---|---|---|
| Page access | Which portal pages you can View / Use / Manage | Settings → Roles, Settings → Organization |
| Data access | Which catalogs, schemas, tables, columns and rows you can read | Atlas → Data & AI Security → Data Governance |
Workspaces are always isolated from each other. The rest of this chapter is about access inside a workspace.
Data Governance console
Data & AI Security → Data Governance. At the top, pick the engine: Lakehouse (Trino) or DN Warehouse (StarRocks).
| Tab | Purpose |
|---|---|
| Overview | Summary of policies |
| Access | Grant select (and more) on catalog / schema / table / column to users or groups |
| Column Masking | Hide or transform column values per user or group |
| Row Filters | Restrict rows with a SQL predicate per user or group |
| Cube Security | Row predicate per role for semantic-layer cubes |
| Audit | Who accessed what |
Mask types:
| Mask | Effect |
|---|---|
| Null | Returns NULL |
| Redact | Every character is replaced |
| Show last 4 / Show first 4 | Partial reveal |
| Hash | Consistent hash. Still joinable, but unreadable. |
| Year only | Dates reduced to the year |
| Exempt | No mask for this user or group |
Changes take effect in about 30–60 seconds.
Where policies apply
| Surface | Runs as | Row filters & masks |
|---|---|---|
| Workbench → Lakehouse tab, Export CSV | You | ✅ |
External JDBC / DBeaver via query.<domain> | You | ✅ |
| Semantic layer cubes | Your role | ✅ via Cube Security |
| Workbench → DN Warehouse tab | Shared workspace role | ⚠️ Workspace-level only |
| Superset pre-configured connections | You (impersonation on) | ✅ Watch out for shared caches. |
| Superset connections added by hand | The URI's user | ⚠️ Not per user unless Impersonate logged-in user is ticked |
| Voir lakehouse connector | Read-only service account | ⚠️ Limit by twin scope |
| Notebooks / Spark / dbt | Shared engine identity | ⚠️ Not per user. Control via page access to Notebooks and Workbench. |
Rule of thumb: give people who must only see filtered data access to the ✅ surfaces, not the ⚠️ ones.
Writing policies safely (admins)
⚠️ Two real mistakes that hid all data from users:
- A row filter on every table (
*/*/*) with an invalid predicate. - A Null mask on a whole catalog (
*).
In both cases the user's schema browser showed only default, with no error message.
Good practice:
- Scope policies to specific schemas and tables. Avoid catalog-wide
*. - Row filter predicates must be valid SQL booleans over the table's columns, e.g.
branch_code = 'KTM'. - Disable a policy while testing instead of deleting it. Test with a non-admin account; admins and owners bypass many rules.
- Grant groups, not individuals. Mirror your org structure (business units / teams) in Settings → Organization.
- Mask PII in bronze and silver, not only gold. Analysts can reach every layer through SQL.
Requesting access (users)
There's no request form in the product. Ask a workspace admin (anyone with Manage on Data & AI Security) and tell them:
- the full table name (
lakehouse.gold.sales_daily), - whether you need all rows or a subset,
- whether you need any masked columns in clear.
Catalog & lineage (DataHub)
Where installed, Applications → Catalog (governance.<domain>) provides search, documentation and lineage from sources through dbt models. It isn't installed on every deployment. Write dbt description:s. They show up here.