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
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
For that, the agent writes the rules file to a volume Trino reads, set through TRINO_ACCESS_RULES_FILE. Without that path, policies are stored but not enforced.
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 MinIO 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.16.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