Skip to content

Databricks auth: Entra ID service principal

Azure Databricks only.

When to use it

  • The same identity must reach Databricks and other Azure resources.
  • Your organization requires credentials to live in Microsoft Entra ID.

Otherwise prefer:

What you need

  • Permission to create an app registration in Entra ID.
  • Workspace admin rights, to add a service principal.
  • Your workspace URL — see Workspace URL.

Step 1 — Register the Entra ID application

In the Azure portal:

  1. Go to Entra ID → App registrations → New registration.
  2. Set:
    • Name — for example trust3-collector-databricks.
    • Supported account types — Accounts in this organizational directory only.
    • Redirect URI — leave empty. Client credentials never redirect a browser.
  3. Click Register.
  4. From the Overview page, copy:
    • Directory (tenant) ID
    • Application (client) ID

Note

Add no API permissions. Databricks does not authorize through Microsoft Graph, so anything added here is unused privilege.

Step 2 — Create a client secret

  1. Go to Certificates & secrets → New client secret.
  2. Set a description and an expiry (24 months maximum).
  3. Copy the secret Value immediately — it is shown only once.
  4. Store it in a secret manager, not in a config file in Git.

Warning

Secrets expire, and authentication fails when they do. Track the expiry date and rotate before it passes.

Step 3 — Add the application to Databricks

In the steps below, choose Microsoft Entra ID managed at step 3 and paste the application (client) ID you copied in step 1.

In the Databricks workspace:

  1. Click your user profile (top right) → Settings.
  2. Go to Identity and access → Service principals → Add service principal.
  3. Pick how the service principal is managed:
    • Databricks managed — for Service principal (OAuth M2M).
    • Microsoft Entra ID managed — for either Entra ID method. Paste the Entra application (client) ID into the Microsoft Entra application ID field.
  4. Enter a Service principal name.
    • Free text, and only a display label in Databricks.
    • Use anything recognizable, for example trust3-collector.

  5. Tick these workspace entitlements:

    Entitlement Why it is needed
    Workspace access Lets the service principal authenticate to the workspace.
    Databricks SQL access Needed to query the system catalog through a SQL warehouse for model usage traces.
    Admin access Covers all current and future workspace objects, so new clusters, jobs, serving endpoints and apps are discovered without a fresh grant each time. Also enables user email resolution on traces and ACL enrichment on assets.

  6. Click Add service principal.

This registers the service principal in the account and assigns it to this workspace in one step.

Note

Trust3 authenticates with the workspace URL and does not use azure_workspace_resource_id, which would require Contributor or Owner on the workspace's Azure resource. Adding the service principal to the workspace is what grants access instead.

Step 4 — Fill in the collector form

In the collector's Datasource Configuration:

Field What to enter
Databricks host Your workspace URL
Authentication method Entra ID service principal (Azure only)
Entra ID tenant ID Directory (tenant) ID from step 1
Entra ID application (client) ID Application (client) ID from step 1
Entra ID client secret The secret value from step 2

Choosing the method reveals only these three credential fields and hides the rest.

All three are required. If any is left blank, the connection fails rather than falling back to another credential.

Step 5 — Grant permissions

Grants are keyed on the application (client) ID:

  • The asset permissions in Assets permissions.
  • The system catalog grants below, if model usage collection is enabled.

Workspace entitlements are not Unity Catalog privileges. Even with Admin access, the identity needs these grants or the model usage and serving endpoint usage collectors return no rows.

  • Run them as a metastore admin or account admin.
  • Replace the principal with the identity the collector authenticates as.
SQL
1
2
3
4
5
6
7
8
9
-- Catalog / schema access
GRANT USE CATALOG ON CATALOG system TO `<collector-principal>`;
GRANT USE SCHEMA ON SCHEMA system.ai_gateway TO `<collector-principal>`;
GRANT USE SCHEMA ON SCHEMA system.serving TO `<collector-principal>`;

-- Table SELECT (model usage collectors)
GRANT SELECT ON TABLE system.ai_gateway.usage TO `<collector-principal>`;
GRANT SELECT ON TABLE system.serving.endpoint_usage TO `<collector-principal>`;
GRANT SELECT ON TABLE system.serving.served_entities TO `<collector-principal>`;

You also need a SQL warehouse for these queries:

  • Grant Can Use on it: SQL Warehouses → your warehouse → Permissions.
  • Copy its HTTP path from Connection details and enter it in the collector's SQL warehouse HTTP path field.

Read more