Authorization¶
Authentication verifies who you are, while authorization determines what you can do. Authorization can only be enabled if Authentication is enabled — see the Authentication docs.
Choose an authorizer¶
Lakekeeper delegates every access decision to one configured Authorizer. This is the first decision to make: it determines how permissions are expressed, who changes them, and what day-to-day administration looks like.
| OpenFGA | Cedar | |
|---|---|---|
| Availability | Open source | Lakekeeper Plus |
| Extra service to run | Yes — an OpenFGA deployment with its own database | No, built in |
| How permissions are expressed | Relationships between principals and objects, stored as data | Policies you author and deploy |
| Who changes them | Admins and object owners, at runtime, through the UI or API | Whoever can deploy the policy source; manage_grants holders, at runtime, through the Grants API |
| Conditions on attributes | No | Yes — time, tags, request attributes |
| Grants API | Full vocabulary | Yes, enforced through policies |
| Changing your mind later | You can switch to OpenFGA on a running deployment | Switching away generally needs a new Lakekeeper instance |
Two further authorizers exist for narrower purposes. AllowAll permits every request and is meant for development and testing only — it records grants faithfully but enforces nothing. Custom lets you implement the Authorizer trait yourself; see Customize.
Neither engine expresses row filters or column masks. Both decide whether a principal may perform an action on an object; filtering rows or columns within an object is not something Lakekeeper enforces.
Configuration for each is in the Authorization configuration reference.
What to read next¶
- Evaluating Lakekeeper? Read the page for the authorizer you are leaning towards, and stop there.
- Setting one up? The same page — each carries its own model, roles and configuration.
- Need Alice to read a table? Under OpenFGA, use the UI — or the Grants API if you are automating it — and note that object owners can hand out access to their own objects. Under Cedar, use the Grants API too: the predefined policies turn the grant into access. Conditions beyond grants go in your policy source.
- Operating the deployment? See Instance Admins for administrative access that does not depend on the authorizer being healthy.
Grants, privileges and roles¶
Three words are used consistently across the authorizers and the API:
- A privilege is the name of a capability —
select,modify. Which privileges exist is defined by your authorizer. - A grant gives one privilege on one resource to one principal: Alice may
selecton this warehouse. - A principal is a user or a role. Granting to a role once and then managing its membership is how you keep the number of grants manageable. Where role membership comes from — an identity provider, or Lakekeeper itself — depends on your setup; see Configuration.
Provider-managed roles¶
A role's provider-id says who owns it. lakekeeper roles are yours to manage through the API; roles in a role provider's namespace belong to that provider, so create, rename, source-system rebind and member (un)assignment are rejected with 400 ManagedRoleImmutable — change them in the identity provider instead. They are still ordinary grant principals: grant privileges to them like any other role.
You can delete a provider-managed role, for example one whose group was deleted in the directory. Each member's next request in that project then asks the provider again: if the provider still reports the group, the role is created again under a new id, without the deleted role's grants. Other Lakekeeper instances follow once the member's entry in the user assignments cache expires. Persisted token roles used for DEFINER views regain the group at the view owner's own next request. If the provider is unreachable, the newest stored groups from another project are served; a member with none gets errors until the provider is reachable again.
Deleting any role also removes its grants. Where Lakekeeper stores grants in its database (every built-in authorizer except OpenFGA), a role that holds grants is only deleted with force=true; without it the request fails with 409 RoleHasGrants.
Under Cedar the API creates and rebinds only lakekeeper roles, so a role the API creates can never pass for a directory group. system is rejected with 400 RoleProviderIdReserved, a configured role provider's namespace with 400 ManagedRoleImmutable, and any other namespace with 400 RoleProviderNotApiManaged. Roles left in the namespace of a provider removed from the configuration can still be renamed and deleted.
A role provider adopts existing roles whose provider-id and source-id match its groups, including roles created through the API before the provider was configured, and their grants with them. Review the roles in a namespace before configuring a role provider with that id.
Membership is synced per user at login. A provider-managed role therefore appears once its first member authenticates, and lists only the members Lakekeeper has seen so far — not the full group. A group nobody has logged in from does not exist as a role yet and cannot be granted to; under Cedar, match on principal.project_roles instead, which needs no catalog role.
Direct grants are not effective permissions¶
A grant recorded on a resource is not the whole answer to "what can Alice do here". Your authorizer's model decides what a grant reaches: whether select implies describe, and whether a warehouse grant covers the tables inside it. Role membership and inheritance are resolved when a request is decided, not stored as extra grants.
So a listing of grants on a table shows what was recorded there, for that principal. To ask what a principal may effectively do, use the per-resource .../actions endpoints or POST /management/v1/action/batch-check.