Lakekeeper Authentication

generated: '2026-08-27'
method: searched
source: >-
  https://docs.lakekeeper.io/docs/latest/authentication/, https://docs.lakekeeper.io/docs/latest/configuration/,
  https://docs.lakekeeper.io/docs/latest/authorization/, openapi/lakekeeper-catalog-api-openapi.yml,
  openapi/lakekeeper-management-api-openapi.yml, openapi/lakekeeper-generic-table-api-openapi.yml,
  openapi/lakekeeper-management-plus-api-openapi.yml
docs: https://docs.lakekeeper.io/docs/latest/authentication/
summary:
  types:
  - http
  - oauth2
  - openIdConnect
  oauth2_flows:
  - clientCredentials
  api_keys: false
  note: >-
    Lakekeeper has NO API-key path. Every caller presents a bearer JWT, and Lakekeeper does not mint those — it
    validates tokens issued by an identity provider the operator configures. That is a deliberate design choice
    for self-hosted software: there is no vendor account system to hold keys in.
schemes:
- name: BearerAuth
  type: http
  scheme: bearer
  bearerFormat: JWT
  applies_to: all three APIs (catalog, management, generic-table) and the Plus management API
  default: true
  detail: >-
    Declared as the top-level `security` requirement on the Management, Generic Table and Plus documents. The
    token is validated on signature (via the IdP's jwks_uri), issuer, and — when configured — audience.
  sources:
  - openapi/lakekeeper-catalog-api-openapi.yml
  - openapi/lakekeeper-generic-table-api-openapi.yml
  - openapi/lakekeeper-management-api-openapi.yml
  - openapi/lakekeeper-management-plus-api-openapi.yml
- name: OAuth2
  type: oauth2
  flows:
  - flow: clientCredentials
    tokenUrl: /v1/oauth/tokens
    scopes: 1
  applies_to: Iceberg REST Catalog API
  deprecated_note: >-
    The catalog-hosted token endpoint (operationId getToken) is marked deprecated in the upstream Apache Iceberg
    specification in favour of an external authorization server. The Iceberg spec's own guidance — carried in the
    scheme description Lakekeeper serves — is to substitute tokenUrl with the external authorization server's full
    token path.
  sources:
  - openapi/lakekeeper-catalog-api-openapi.yml
  scopes_artifact: scopes/lakekeeper-scopes.yml
identity_providers:
  configuration:
  - name: LAKEKEEPER__OPENID_PROVIDER_URI
    detail: >-
      Points at the operator's IdP. The provider MUST serve /.well-known/openid-configuration, and that document
      must define jwks_uri and issuer.
  - name: LAKEKEEPER__OPENID_PROVIDERS
    since: v0.13.0
    detail: >-
      Configure several providers simultaneously — e.g. Okta for humans and a cloud OIDC issuer for service
      accounts. Backwards-compatible with the single-provider setting.
  - name: LAKEKEEPER__OPENID_AUDIENCE
    detail: >-
      Validates the token's `aud` claim. RECOMMENDED in every deployment, so a token leaked for another
      application on the same IdP cannot be used to reach data in Lakekeeper.
  - name: subject claim fallback
    detail: >-
      The OpenID subject-claim setting accepts a comma-separated list; the first matching claim in the token wins,
      which eases integration across heterogeneous IdPs.
  documented_idps:
  - Keycloak
  - Microsoft Entra ID (Azure AD)
  - Okta (with DPoP on the role provider, opt-out to Bearer)
  - Any OIDC-compliant provider
  kubernetes:
    supported: true
    detail: >-
      Kubernetes service-account tokens are accepted as an alternative authenticator.
      LAKEKEEPER__KUBERNETES_AUTHENTICATION_SUBJECT_SOURCE=username derives the Lakekeeper user id from
      `system:serviceaccount:<namespace>:<name>` — stable across clusters — instead of the per-cluster uid
      (the default), so roles and instance admins can be pre-provisioned.
principal_identifiers:
  oidc: 'oidc~<subject from the provider>'
  note: Roles bound to an external source system carry provider-id + source-id rather than being managed in Lakekeeper.
machine_clients:
  flow: OAuth2 client_credentials against the operator's IdP
  detail: >-
    All common Iceberg clients and IdPs support client_credentials. The documentation walks through app
    registration for Keycloak and Entra ID, including the exact spark.sql.catalog.<name>.oauth2-server-uri
    configuration engines need.
  warning: >-
    From the Flink guide — inject TOKEN / OAUTH_* through Flink's env.java.opts or cluster secret management;
    never pass secrets on the `flink run` command line in production.
authorization:
  note: >-
    Authentication and authorization are separate and separately pluggable. After a token is validated, the
    configured Authorizer decides what the principal may do: AllowAll (default, no authorization), OpenFGA
    (Zanzibar-style ReBAC, the recommended production choice), an Open Policy Agent bridge for engine-level
    delegation, or Cedar in Lakekeeper+.
  admission_gates:
    since: v0.13.0
    detail: >-
      A coarse allow/deny hook that runs AFTER authentication and BEFORE any handler — distinct from the
      per-resource Authorizer. Used to consult an external entitlement service, suspend a tenant, or honour a
      token deny-list. Gates may also contribute resolved roles and can see the caller's bearer token. Only an
      exact 403 is read as an authoritative deny; every other non-2xx makes the gate fail closed with a 503.
    docs: https://docs.lakekeeper.io/docs/latest/admission/
  actions_endpoints: >-
    get_server_actions, get_project_actions, get_warehouse_actions, get_namespace_actions, get_table_actions,
    get_view_actions, get_generic_table_actions, get_role_actions and get_user_actions answer "what may this
    principal do here?" — the correct pre-flight for an agent, and the way to tell a permission failure apart from
    a nonexistent object.
  docs: https://docs.lakekeeper.io/docs/latest/authorization/
gaps:
- No API keys, no personal access tokens — an operator must stand up an IdP before Lakekeeper is usable in production.
- >-
  The catalog document's OAuth2 tokenUrl is a relative path (/v1/oauth/tokens) pointing at a deprecated endpoint;
  a client must be told the external authorization server out of band.
- The Management API declares no scopes; authorization is entirely delegated to the Authorizer.