Skip to main content
Oleria provides identity security and access management teams with visibility and intelligence into who has access to what, where they got that access, how they use it, and whether they should even have it. As part of that promise, we integrate your Databricks account into the Oleria platform - one connection covers every workspace the account contains. This page provides step-by-step guidance for connecting Databricks to your Oleria workspace.
This integration operates at the Databricks account level, not a single workspace. Once connected, Oleria automatically discovers and syncs every workspace in the account - see Set up the integration for the three required permission grants, plus an optional fourth that unlocks real audit-log activity.

​
What Oleria discovers

Oleria uses this data for dormant account detection and access reviews, synced across every workspace in the account on Oleria’s regular sync schedule, not just the workspace you connect from.

​
Prerequisites

  • Administrator permission on the Oleria workspace
  • Access to your Databricks account console to create a service principal
  • Your Databricks account ID (found in the account console, under your username)
  • To enable real audit-log activity (optional): a SQL warehouse per region your account has workspaces in
Databricks separates account-level admin from workspace-level admin. This integration’s service principal needs all three: account_admin at the account level, explicit access assigned to every individual workspace it should read, and metastore admin on each metastore for full Unity Catalog coverage. Missing any one of these is a common setup mistake - see the steps below.

​
Set up the integration

1

Create a service principal and OAuth secret

In the Databricks account console, go to User management -> Service principals and add a new service principal (for example, oleria-connector). Open it, go to the Secrets tab, and select Generate secret. Copy the Client ID and Secret immediately - Databricks shows the secret only once.
2

Grant account_admin

Still in the account console, open the service principal’s Roles tab and grant it Account admin. This is required for account-wide operations - enumerating every workspace, real account-level user and group listings, service principal credential inventory, and impersonation rule sets.
Workspace-level “Admin access” does not grant account_admin and does not unlock any account-level API. The two are entirely separate grants - a service principal can hold one without the other.
3

Assign the service principal to every workspace

In the account console, go to Workspaces, select a workspace, open its Permissions tab, and add the service principal with Admin permission (not User). Repeat for every workspace in the account you want Oleria to see.
account_admin does not automatically grant access to any workspace. Each workspace needs its own explicit permission assignment - skipping a workspace means Oleria’s account-wide sync simply won’t reach it, with no error surfaced elsewhere.
Grant Admin, not User - several reads Oleria depends on are admin-gated on the Databricks side: personal access token inventory, workspace-object and secret-scope ACLs, and the non-federated fallback for the Disable workspace user action. A service principal with only User access still produces a healthy-looking connection, just missing credentials and most access grants, with no error surfaced.
4

Grant metastore admin

In the account console, go to Catalog, open each metastore your workspaces use, and set the service principal (or a group that contains it) as Metastore admin. Repeat for every metastore - an account with workspaces in multiple regions typically has one metastore per region.
Without metastore admin, Oleria sees only the Unity Catalog securables the service principal owns or holds an explicit privilege on, not the full metastore, and the Revoke Unity Catalog privilege action fails on everything else. Oleria doesn’t flag this on the connection - it still shows as Healthy - though the Revoke Unity Catalog privilege action’s own validation does list metastore admin as a required permission.
5

Enable audit-log activity (optional)

Databricks’ audit log (system.access.audit) is only queryable through a SQL warehouse, and Oleria never picks one on its own - you choose it. In each region your account has workspaces in, pick a SQL warehouse in one workspace and, in that workspace, grant the service principal Can use on it (SQL Warehouses -> the warehouse -> Permissions). Make sure the access system schema is enabled on that region’s metastore, then grant the service principal USE CATALOG on system, USE SCHEMA on system.access, and SELECT on system.access.audit - metastore admin alone may not include these. The audit table only covers the region of the workspace you query it from. You’ll enter each warehouse’s ID in the connection form in the next section.
This step is optional. Skip it and Oleria’s Activity data comes from job-run history only, the same as before. A wrong warehouse ID, a missing grant, or an unenabled access schema is logged and Oleria falls back to job-run history rather than failing the connection - on some account tiers, enabling the access schema is a Databricks-only action your admin can’t self-serve, so contact Databricks support if the grants above don’t take effect. Each sync starts the warehouse if it’s stopped, which uses Databricks compute - a serverless warehouse with a short auto-stop keeps this small.

​
Connect Databricks to Oleria

1

Open the integration

Log in to your Oleria workspace and navigate to Integrations -> Databricks -> Connect.
2

Complete the connection form

3

Complete the connection

Oleria validates both the workspace-scoped and account-scoped credentials, enumerates every workspace in the account, discovers roles, resources, and access, and begins the first sync.

​
Verify the integration

Confirm the new instance appears on the Connected tab of your Oleria Integrations page with a status of Healthy. Oleria syncs users, groups, Unity Catalog resources, workspace objects, and access grants from every workspace in the account on its regular sync schedule once the initial sync completes.

​
Remediation actions

Workspace group actions apply to workspace-local groups only, since Databricks’ group-membership API is workspace-scoped. An account-level group assigned to a workspace shows up in that workspace’s group listing, but Oleria rejects any add or remove action against it at validation rather than letting it fail against Databricks.
Databricks doesn’t offer a read-only account-level role, so discovery and remediation actions both use the same service principal and the grants you set up above - account_admin, workspace Admin, and metastore admin. Oleria only makes changes in Databricks when you run a remediation action.

​
Known limitations

  • Audit-log activity is opt-in and has a gap window: without a SQL warehouse configured (see Set up the integration), Activity is job-run history only - a user who works only through the browser under SSO, holds no personal access token, and never triggers a job has no activity signal from this integration. With a warehouse configured, Oleria reads system.access.audit about an hour behind real time so late-arriving rows are still caught, but a row that lands more than roughly an hour after its event is still missed - Databricks’ audit table has no field Oleria can use to resume from exactly where it left off. The audit table is also regional: give Oleria a warehouse in every region your account has workspaces in, or that region’s workspace activity isn’t read (account-level activity is still captured once, from the home region).
  • No workspace-object permission revocation: Unity Catalog privileges can be revoked as a remediation action, but revoking a workspace-object permission - on a cluster, job, notebook, cluster policy, Databricks App, model-serving endpoint, or similar - is not yet available as a remediation action.
  • No grant actions: Oleria does not support granting a Unity Catalog privilege, granting a workspace-object permission, or granting a Service Principal User/Manager role through this integration - only the corresponding revoke, disable, and remove actions are available.
  • Impersonation and role-grant data may be incomplete: account-level impersonation and role-grant rule sets (Service Principal User/Manager, Group Manager, group.assumer, and the other account-wide roles) are read defensively - if Databricks returns a temporary error for a given tenant, Oleria logs it and continues rather than failing the sync, which means these relationships may be under-reported on some tenants.
  • Job-run activity only credits whoever submitted a one-time run, or a job’s service principal: a one-time run submitted through runs/submit (Airflow, ADF, the CLI, or the SDK) is credited to whoever submitted it, human or service principal. Any other job run is credited to the job’s run-as identity only when that’s a service principal, and to no one otherwise - not even the job’s creator - because Databricks’ Jobs API doesn’t say who triggered a run. With a SQL warehouse configured, a manual Run now or a runs/submit call also produces its own audit-log activity crediting whoever actually triggered it - so for those two cases the signal exists either way, just as a separate activity record when it comes from the audit log.
  • Some OAuth app integration details aren’t visible: Oleria can’t see a custom integration’s client secret value (Databricks has no API that returns it), a Databricks-published integration’s OAuth scopes, or which specific users have signed in through an integration - only an aggregate last-sign-in date, and only with a SQL warehouse configured.
  • Delta Sharing coverage is outbound only: Oleria discovers shares your account provides and the recipients granted access to them, but not shares your account receives from an external provider (foreign catalogs).
  • Some resource types aren’t discovered yet: vector search endpoints, instance pools, SQL queries and alerts, and Databricks’ own foundation-model serving endpoints (every workspace user can already query these, and Databricks exposes no per-customer ACL for them).

​
Contact us

For questions about this integration, contact us at support@oleria.com.