Governance & identity
In lavalake, governance is not a layer on top of the platform — it is the path every query takes. There is no route around it, not for search, dashboards, the BI feed or the AI assistant.
On this page
Access requests, erasure and support
Privacy requests cover lake data and personal platform data. Erasure requires confirmation of the displayed records; retention rules and audit evidence still apply. The processing-activities report provides a Word or PDF starting point to complete. Vendor support receives only explicitly granted, time-limited and logged access.
Delegated identity instead of a service account
A backend that reads data with broad rights of its own and then decides what to show the user is the common case — and the point at which authorization models fall apart. lavalake inverts it: the agent exchanges the signed-in user's token through Keycloak's standard token exchange (RFC 8693) for a token addressed to Trino, and issues the query with that.
What you see in lavalake is exactly what Trino shows your identity. A bug in the interface cannot reveal a row you are not allowed to see.
Row and column policies
Under Verwaltung → Richtlinien (administration → policies) a platform administrator defines which rows a role sees and which columns are masked. The console does not merely store those rules — it compiles them into Trino's file-based access control. Trino reads the generated rules file from a shared volume and applies it to every query, wherever it comes from.
- Row access: a condition Trino appends to every query against the table.
- Column masking: an expression that replaces the value rather than hiding the column.
- Effective on every path — worksheet, search, dashboard, BI feed, assistant.
Policies take effect inside Trino
Compose reads policy files through a shared volume. On Kubernetes, values-datenrechte.yaml distributes rules through a ConfigMap to Trino and warehouse coordinators. Without this integration, a stored policy does not prove enforcement: check console status and verify behavior with a restricted account.
Since 0.25.0 the policies page also answers whether an individual policy takes effect at all: it checks catalog, schema, table and column against the live catalog and reports matches as well as misses. Trino compares names case-sensitively — a policy on “Kunden” instead of “kunden” used to protect nothing, silently.
Since v0.34.0, Keycloak roles are passed through as Trino groups. A policy therefore applies to every member of the specified role. Changes made in user administration are synchronized immediately; the mapping is also refreshed periodically.
Classify tables and columns
In the table view, administrators tag tables and columns as personal data, confidential, financial data and other categories. “Klassifizieren” suggests tags from column names and data types. Suggestions are confirmed individually and every change is audited.
Name-based heuristics work without an AI backend. An optional configured API or self-hosted model refines suggestions, receiving only names and types, never data values. Tags do not yet trigger automatic masking. Personal-data access, deletion and retention workflows are available.
The audit log
Every access is logged, and the entries form a hash chain: each entry carries the checksum of its predecessor. An entry altered or removed after the fact breaks the chain at a provable point. Archival goes to object storage under Object Lock — storage that refuses to be overwritten.
The access is logged, not the content
The chain records who queried what, and when — not the values. Otherwise it would become a second, unprotected copy of the data.
Lineage and access history
From the same chain, the lineage page derives two questions nobody else can answer: where did this table's data come from — which import, which source, which document? And who has read or changed it since? Both are derived rather than separately maintained, and therefore cannot drift away from reality.
What else protects the installation
| Measure | Effect |
|---|---|
| Reachable only through the reverse proxy | Backend, database, object storage and the Keycloak backchannel stay on the internal network. |
| Encrypted secrets | Source passwords, LLM and embedding keys and OAuth material are AES-256-GCM encrypted and never returned, logged or audited. |
| TLS to source databases | Default verify — TLS with certificate verification, switchable per source. |
| Egress guard | Admin-triggered connection tests and embedding calls cannot reach link-local or cloud-metadata addresses. An allowlist can narrow this further. |
| Isolated document parsing | PDF and Word extraction runs in a resource-limited worker with a hard timeout. A hostile document can only kill its own worker. |
Applies to: This page describes lavalake 0.201.0. Product and documentation live in separate repositories — when in doubt, what the console shows is authoritative.
Something missing?
If these pages do not answer your question, we will walk through the platform against your own case in half an hour.
Book a demo