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 :doc:`getting-started`'s "Querying data" section) without any manual Rego editing. Core concepts -------------- For a step-by-step walkthrough with screenshots, see :doc:`../user-manual/index`. .. list-table:: :header-rows: 1 * - 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: .. list-table:: :header-rows: 1 * - 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 :doc:`../user-manual/admin`: - **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=``, 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.