Databricks Unity Catalog: Security Misconfigurations and Attack Paths

Databricks operates at the intersection of cloud infrastructure and data engineering — sitting inside an organisation’s cloud tenant, with access to cloud storage (S3, ADLS, GCS), compute resources, and often some of the most sensitive data the organisation holds: customer PII, financial records, ML training datasets. Unity Catalog, Databricks’ unified data governance solution, controls who can access what across workspaces. When it’s misconfigured, the blast radius of a compromised account or token is substantial.

This guide walks through the primary security misconfigurations that produce real incidents and what to do about each.

Architecture and Access Control Overview

Unity Catalog sits above individual workspaces and provides a three-level namespace: Catalog → Schema → Table (or Volume, Function, Model). Access is governed through GRANT statements on these objects, workspace-level group assignments, and external cloud identity integration (IAM roles for AWS, managed identities for Azure, service accounts for GCP).

The attack surface spans several layers:

Personal access tokens (PATs) — long-lived credentials scoped to a workspace
Service principal credentials — OAuth secrets or Azure managed identity bindings
Cluster-level access controls — who can attach to a shared cluster
Storage credential bindings — external location access to cloud storage
Workspace-to-workspace federation — cross-workspace Unity Catalog access

Misconfiguration 1: Long-Lived PAT Proliferation

Personal Access Tokens are the most common credential type in Databricks environments. By default, PATs have no expiry — users create them once and they persist indefinitely. A token stored in a .bashrc file, a git repository, a CI/CD secret manager, or a developer laptop is a persistent credential that provides full workspace access.

Attack path: An attacker with access to a developer’s workstation or to the codebase finds a Databricks PAT. They authenticate to the workspace API, list all accessible catalogs and schemas via GET /api/2.1/unity-catalog/catalogs, enumerate tables, and begin downloading data using the SQL endpoint or cluster API — all with the permissions of the token owner.

Detection:

# List PATs with no expiry or expiry > 90 days
databricks token-management list | jq '.token_infos[] | select(.token_expiry_time == null or .token_expiry_time > (now * 1000 + 7776000000)) | {token_id, comment, creation_time, token_expiry_time}'

Remediation:

Enforce maximum token lifetime via workspace admin settings: Admin Console → Security → Personal access token lifetime
Rotate any tokens with no expiry date
Use service principals with OAuth M2M (machine-to-machine) tokens where possible — these can be scoped more tightly and rotated programmatically
Enable token usage audit logging via Databricks audit log delivery to cloud storage

Misconfiguration 2: Overly Permissive Unity Catalog Grants

Unity Catalog’s ANSI-SQL grant model is flexible but easy to over-provision. The most common pattern: a data engineering team grants USE CATALOG, SELECT, and MODIFY on the entire production catalog to a shared group that includes analysts, external contractors, and CI/CD service principals.

Blast radius: A single compromised account in that group has read/write access to every table in the catalog. MODIFY permission additionally allows DML operations — including DELETE and TRUNCATE.

Audit current grants via SQL warehouse:

-- List all grants on the production catalog
SHOW GRANTS ON CATALOG production;

-- List all grants on a specific schema
SHOW GRANTS ON SCHEMA production.customer_data;

-- Find principals with broad catalog-level MODIFY
SELECT grantee, privilege_type, securable_type, securable_name
FROM information_schema.privilege_assignments
WHERE privilege_type = 'MODIFY'
  AND securable_type = 'CATALOG';

Remediation:

Implement least-privilege catalog grants. Analysts should receive SELECT on specific schemas, not the full catalog.
Separate catalogs by sensitivity tier: raw, curated, restricted. Service principals and users should receive access only to the tier their role requires.
Remove MODIFY from analyst groups entirely — write access should require a service principal operating under a documented data pipeline.

Misconfiguration 3: Shared Cluster Access

All-purpose clusters in Databricks workspaces can be configured as shared (multiple users attach to the same running cluster) or single-user. The security implication is significant: on a shared cluster without credential passthrough, all users share the cloud identity of the cluster’s instance profile or managed identity.

Attack path: A user with CAN ATTACH TO permission on a shared cluster that has a powerful IAM role (e.g., an instance profile with s3:* on a production bucket) can run arbitrary Spark code under that identity. They bypass any Unity Catalog table-level controls by accessing the underlying storage directly:

# Direct S3 read bypassing Unity Catalog grants
df = spark.read.parquet("s3://prod-data-lake/restricted/")
df.write.csv("/tmp/exfil/")

Remediation:

Enable credential passthrough on shared clusters for user-identity binding
Prefer single-user clusters for privileged workloads — higher cost but the identity is explicit
Apply Unity Catalog’s external location controls to restrict which storage paths can be accessed from within Databricks, independent of underlying cloud IAM

Misconfiguration 4: Workspace Admin Proliferation

Databricks workspace admins have broad permissions: they can view all running clusters, access all notebooks in shared spaces, manage users, and bypass most access controls. Workspace admin is frequently assigned too broadly during initial setup and never reviewed.

Audit workspace admins:

# List all workspace admins
databricks groups get-members --group-name admins --output json | jq '.members[].user_name'

Remediation:

Apply just-in-time (JIT) elevation for admin access using Databricks service principals with time-limited credentials
Separate workspace admins from data admins — the cluster management persona does not require full data access
Use Unity Catalog’s metastore admin role for data governance tasks rather than granting full workspace admin

Misconfiguration 5: Audit Logging Gaps

Databricks generates detailed audit logs covering API calls, notebook execution, cluster operations, and data access. By default, these logs are not enabled or delivered — teams must configure log delivery to cloud storage.

Without audit logs, an attacker who exfiltrates data through a compromised token leaves no trail in any SIEM. The organisation may not detect the breach until data appears elsewhere.

Enable audit log delivery via Terraform:

resource "databricks_mws_log_delivery" "audit_logs" {
  account_id           = var.databricks_account_id
  credentials_id       = databricks_mws_credentials.log_writer.credentials_id
  storage_configuration_id = databricks_mws_storage_configurations.audit.storage_configuration_id
  delivery_path_prefix = "databricks-audit"
  config_type          = "AUDIT_LOGS"
  log_type             = "AUDIT_LOGS"
}

Remediation:

Deliver audit logs to a centralized SIEM with a minimum 90-day retention window
Alert on: bulk table reads by accounts with no recent history of similar access, PAT creation by service principals, workspace admin changes, external location access from unexpected clusters

Summary Checklist

Control	Status
PAT maximum lifetime enforced (≤90 days)
PAT usage audit logging enabled
Unity Catalog grants reviewed at schema level
No analyst groups with MODIFY on production catalogs
Shared clusters use credential passthrough or are replaced by single-user clusters
Workspace admin count minimized and reviewed quarterly
Audit log delivery configured to SIEM
External location access controls applied

Databricks is powerful enough that a single misconfiguration can expose an entire data lakehouse. The controls above are not exotic — they’re the baseline that a properly governed Databricks deployment should meet before it processes production data.