Open Data Infrastructure
Lakekeeper Audit Logs for Catalog Governance
How Lakekeeper audit logs can become operational evidence for catalog access, denial reasons, and recovery review.
Catalog governance gets real when a denial, write, or table change leaves evidence that operators can read under pressure.
The practical problem
Lakekeeper documents structured JSON logs and audit events for authorization checks, including fields such as action, entity, actor, and decision. It also warns that audit logs contain personally identifiable information, which means the logs are both governance evidence and sensitive records.
That combination is exactly why audit logs need an operating model. Catalog audit logs should help teams explain access, review incidents, and recover from mistakes without turning sensitive identities into casual dashboard data.
Audit logs should answer control questions
A useful audit record answers who asked, what they attempted, which catalog resource was involved, whether the decision was allowed or denied, and which policy path shaped that result. That evidence is operational, not decorative.
For Open Data Infrastructure, catalog logs should connect to lineage, data product ownership, policy-as-code decisions, and incident review. Otherwise, teams can see isolated events but not the chain of responsibility around the table.
Core idea: Catalog audit logs are governance evidence only when they connect identity, action, resource, decision, and review.
The operational pattern
Route audit logs to secure long-term storage. Apply access controls to the logs themselves. Create filters for denied decisions, sensitive resources, unusual principals, and recovery actions. Tie high-risk events to incident workflows instead of treating them as generic logs.
That discipline matters during recovery. If a table was dropped, modified, or accessed unexpectedly, operators need to know which identity and policy path led to the event. The log should shorten the investigation, not become another system to investigate.
What breaks first
- Audit logs are enabled, but nobody owns retention, access, or review.
- Denied decisions are logged but not connected to developer feedback or safe alternatives.
- PII appears in logs that too many people can inspect.
- Recovery reviews rely on memory because catalog events are not tied to lineage or table versions.
Questions to ask
Ask where audit logs are stored, who can read them, how long they are retained, and how they connect to catalog roles, table changes, and incident review. Ask whether a denied request can become a useful support artifact instead of a vague access ticket.
For adjacent context, read Lakekeeper multi-tenant Iceberg catalogs, Polaris and Lakekeeper catalog operations, and governance as infrastructure.
Sources to start with
These primary sources anchor the technical claims in this guide.
- Lakekeeper logging documentation
- Lakekeeper configuration documentation
- Apache Iceberg REST Catalog specification
- OpenLineage documentation
The catalog log should make a governance decision explainable while the decision is still useful.