Ranger

Apache Ranger is the policy enforcement engine deployed into each tenant cluster. Every query that reaches Trino is checked against Ranger before execution — access is denied by default if no matching policy exists.

What It Does

Ranger evaluates three types of policies at query time:

Policy type	What it controls
Resource policy	Access to specific catalogs, schemas, tables, and columns
Tag policy (restriction)	Restrict or permit access to all columns carrying a Datahub tag
Tag policy (masking)	Apply a data transformation (hash, nullify, partial mask) to all columns carrying a Datahub tag

Resource policies are managed through the Data Access Management UI. Tag policies depend on tags being present in Ranger's tag store — populated via the Datahub ranger-tag-sync.

Components

Component	Description
Ranger Admin	The Ranger web UI and REST API. Manages services, policies, and audit logs.
PostgreSQL	Ranger's backing database for policy storage (provisioned via KubeBlocks).
ranger-seed-policy	A one-shot Kubernetes Job that runs at deploy time to bootstrap the Trino service and seed the default policies.
ranger-role-sync	A CronJob that mirrors Keycloak realm roles into Ranger roles every 15 minutes.

Seed Policies

The seed policy job runs once at deploy time and creates the following default policies in the trino Ranger service:

Policy name	Resource	What it grants
all - trinouser	trinouser: *	Every user can impersonate themselves — required for Trino's identity propagation model
all - queryid	queryid: *	Every user can execute queries — the execute privilege on query identifiers
information-schema-reader	information_schema.*	kc_realm_platform_admin can read the Trino information schema

If the seed job fails before creating the trino service definition, the Ranger plugin in Trino falls back to allow-all — all queries succeed regardless of policies. Check kubectl logs job/<seed-job-name> -n ranger if policies appear to not be evaluating.

Audit Filters

Ranger is configured with audit filters to reduce log noise:

Condition	Audited?
Any denied access	Yes
queryid / execute access	No
trinouser / impersonate as {USER}	No
Everything else	No (filter is additive — only denials are audited by default)

Keycloak Role Sync

The ranger-role-sync CronJob runs on a configurable schedule (default: every 15 minutes) and mirrors Keycloak realm roles into Ranger.

• Each Keycloak realm role (e.g. data_analyst) becomes a Ranger role named kc_realm_data_analyst.
• Users assigned the realm role in Keycloak are added as members of the corresponding Ranger role.
• The CronJob uses a dedicated Keycloak OAuth client with view-realm permission on the realm-management client — it reads the realm role membership without needing admin credentials.
• Ranger policies reference kc_realm_* roles rather than individual users. A user gaining a realm role in Keycloak automatically inherits all policies granted to that role within the next sync cycle.

For the full role sync architecture, see Keycloak → Ranger Role Sync.

Go Deeper

• Data Access Management — managing policies via the UI
• SQL Auth: Superset, Trino & Ranger — how policies are enforced at query time
• Datahub — ranger-tag-sync that populates Ranger's tag store
• Keycloak → Ranger Role Sync — full role sync details