Security Center

Security Center is the platform’s self-service access-governance UI. Product owners register data products here, teams request and are granted access to them, and row-level/column-level security policies get authored, all enforced by Trino’s native OPA access-control plugin (see Getting started: Sovereign Data Platform’s “Querying data” section) without any manual Rego editing.

Core concepts

For a step-by-step walkthrough with screenshots, see User manual.

Concept	What it is
Product	A registered table (catalog.schema.table), living in a catalog and schema that a team owns. Either created directly in Security Center (provisioned in the background) or discovered automatically by a periodic sync job and later adopted by a team.
Team	A group of users (and applications) that owns products and/or requests access to other teams’ products. Membership can include users, groups, or applications.
Role	A named access level scoped to one product (e.g. reader, analyst) — not a global permission. Every product has an implicit owner role (reserved name); a product owner can create additional roles.
Access request	A team’s request for one of its members to be granted a product’s role. Goes through a request → approve/reject workflow; approved access can later be revoked.
RLS rule	Row-level security: a set of predicates (column, operator, value) scoped to a role. Rows failing the predicates are invisible to that role.
CLS rule	Column-level security: a column mask scoped to a role. One of four fixed mask types: full_redact, hash, partial_mask (with parameters, e.g. {"keep_last": 4}), null.

Requesting access to a product

From the Catalogus tree, search or browse the registered products. Requesting access to a product’s role submits an access request on behalf of your team, with a comment and contact explaining the request — visible to that product’s owner for approval. Your pending and past requests, across every state, are visible from your own view; nothing is granted until a product owner approves it.

Approving access requests (product owners)

From a product’s Beheer tab, an owner sees every pending access request against that product’s roles and can approve, reject, or later revoke previously-approved access. Owners can also create additional roles beyond the reserved owner role (lowercase, starting with a letter, e.g. analyst) — each new role is available immediately as a request target and as an RLS/CLS scope.

Authoring row-level security rules

Still on a product’s Beheer tab, an owner can author RLS rules for any of the product’s roles: a list of predicates, each a column, an operator (=, !=, >, <, >=, <=, IN), and a value. A role with one or more enabled RLS rules only sees rows matching every predicate: rows failing any predicate are filtered out entirely for members holding that role. Column names can be picked from the product’s real Trino schema when column metadata is available, or entered as free text otherwise.

Authoring column-level security rules

CLS rules mask a specific column for a specific role rather than filtering rows:

Mask type	Effect
full_redact	Replace the value entirely (e.g. with a fixed placeholder).
hash	Replace the value with a one-way hash.
partial_mask	Mask part of the value, keeping the rest visible — parameterised, e.g. {"keep_last": 4} to keep only the last 4 characters.
null	Return NULL for the column.

Like RLS rules, a CLS rule is scoped to one (role, column) pair and can be individually enabled or disabled without deleting it.

Admin tasks

Users with the admin role get a Beheer (administration) menu with three areas, described step by step in Administrator journey:

• Gebruikersbeheer (user management): manage platform users and teams.

• Product synchronisatie and Unity Catalog: catalog settings, synchronization and deleting a catalog that has no tables (the API call is DELETE /admin/unity-catalog/catalogs/{catalog}?confirm=<name>, admin only; the catalogs system and main are protected).

• Admin panel (products): delete a product or team outright (deleting a team also removes all of its groups; fails if the team still has dependent state), adopt a product the Trino sync job discovered but no team has claimed ownership of yet, and manually trigger a Trino sync to reconcile Security Center’s product registry against what actually exists in Trino.

How enforcement actually works

Security Center itself never talks to Trino at query time. Every RLS/CLS rule authored through the UI is compiled into Rego and packaged into a per-customer OPA bundle; each customer’s Trino OPA plugin polls its own /trino/{customer}/bundle.tar.gz endpoint on an interval and picks up rule changes automatically, with no Trino restart or manual policy deployment needed. That endpoint is authenticated with a static bearer token shared once at deploy time between Security Center and the customer’s OPA instance, not a per-request Keycloak token (OPA has no Keycloak identity of its own to present).

Spark follows the same rules. A user whose role carries a row filter or column mask reads that table in a notebook through Trino, so the filter and mask are applied there as well; such access is read-only.