Open Data Infrastructure
Lakekeeper Role Mapping for Catalog Operations
How Lakekeeper role mapping connects human owners, service accounts, namespace responsibility, and audited catalog recovery paths.
Catalog roles are where governance stops being a meeting and starts being executable infrastructure.
Role mapping has to match operations
Lakekeeper implements Iceberg REST catalog operations and exposes management capabilities that go beyond the REST catalog specification, including permissions. Its docs describe authorization options such as OpenFGA and OPA integration.
That means role mapping should not be designed around job titles. It should be designed around operations: who can create namespaces, who can issue credentials, who can alter tables, who can recover access, and which service accounts can act for which data product.
Core idea: Lakekeeper role mapping should encode operational responsibility, not org-chart decoration.
The catalog has two kinds of responsibility
The Lakekeeper concepts documentation separates the Iceberg REST API from the management API used for configuration and non-spec entities such as permissions. The authorization docs describe OpenFGA-based permission evaluation and OPA bridge behavior.
That split is helpful. Table operations, management operations, and policy evaluation can have separate owners. A good role map makes those boundaries visible before something breaks.
Patterns that work
- Map every namespace to a data product owner and a recovery owner.
- Separate human break-glass roles from service account runtime roles.
- Record which role can create, alter, drop, recover, and delegate within each project or namespace.
- Use OpenFGA or OPA integration as an enforcement path, then log the decision path for audit.
- Review role mapping whenever warehouse boundaries, namespaces, or service identities change.
For adjacent ODI context, read Lakekeeper open catalog operations, Lakekeeper namespace ownership, REST catalog security.
What breaks first
- A service account owns a namespace because it created the first table.
- Recovery requires admin access because no scoped recovery role exists.
- Role names describe teams but not operations.
- Policy evaluation happens, but nobody can trace it back to catalog ownership.
Questions to ask
- Which Lakekeeper roles map to real catalog operations?
- Who owns recovery for each warehouse and namespace?
- Which service accounts can delegate or issue credentials?
- How are OpenFGA or OPA decisions linked to audit records?
Sources to start with
These primary sources anchor the technical claims in this guide.
- Lakekeeper concepts documentation
- Lakekeeper OpenFGA authorization documentation
- Lakekeeper OPA documentation
A catalog role should explain what someone can operate, not where they sit.