Databricks documents that an external location is accessible from every workspace attached to its metastore by default unless workspace binding limits it. Databricks, Manage external locations That default makes the relationship between workspace, catalog, external location and cloud credential an important buyer test.
Quick answer. A Unity Catalog security test should identify each protected catalog, external location, workspace binding and service principal. Prove allowed and denied access using synthetic datasets, and separate Databricks permissions from underlying cloud storage permissions. Stingrai can scope human-led cloud testing around the customer-owned workspace, storage account and connected applications.
A principal granted an external-location privilege such as READ FILES can exercise that privilege from any workspace attached to the metastore while the location is open to all workspaces. That is distinct from querying a table in a catalog: a catalog binding can deny that query even when the principal holds a table privilege. Test the location action and catalog query as separate decisions with the same synthetic fixture. Databricks external-location binding and workspace-catalog binding
The buyer's test matrix
This matrix assigns a specific operation to each boundary. Replace the generic objects with named customer-owned workspaces, catalogs, locations, test identities and a synthetic storage prefix. The data owner should approve both the allowed and denied results before a tester runs either case.
Boundary | Expected decision | Safe test | Evidence to keep | Control owner |
|---|---|---|---|---|
Catalog binding | Table query works only from an approved workspace | Query the same synthetic table as the same principal from allowed and denied workspaces | Catalog binding, privilege and query result | Metastore owner |
External location | A granted location privilege works only in approved workspaces | Exercise | Location binding, grant and result | Data platform owner |
Existing external table | Location unbinding is not mistaken for retroactive table revocation | Query an already created synthetic external table after an approved binding change | Table and catalog bindings, observed result | Data platform owner |
Storage credential and IAM | Cloud policy reaches only the approved path | Review credential mapping and perform bounded cloud-side validation with the cloud owner | Credential, IAM policy and test-prefix outcome | Cloud security owner |
Service principal | Job identity has only required platform and data privileges | Run a synthetic job under its real identity and compare with a denied test identity | Run identity, grants and denial proof | Platform administrator |
Audit evidence | Selected access and grant changes can be attributed | Correlate controlled actions with platform and cloud records | Actor, workspace, action and telemetry gaps | Security operations |
Figure 1: A practical evidence path for this assessment. The stages are an editorial test-planning model based on the cited provider documentation.
Map the layers before testing
Unity Catalog authorization is easier to reason about when the buyer separates a catalog query from a direct action on an external location. A catalog contains schemas and data objects; its workspace binding decides which workspaces may access it. An external location combines a cloud object-storage path and a storage credential, and its own workspace binding governs where principals may exercise location privileges such as READ FILES or CREATE EXTERNAL TABLE. The underlying cloud policy controls what the credential can reach outside that Databricks object model. Databricks, Workspace-catalog binding, Manage external locations, and External locations
A proposal should specify which of those decisions it will demonstrate. A successful table query does not establish that the external-location privilege is appropriately limited across workspaces. A denied table query does not prove the underlying cloud IAM role is narrow. A grant inventory without a runtime attempt does not show whether the chosen compute, identity and workspace can exercise the grant. Each statement requires its own fixture and evidence.
Start the workshop with a boundary map: metastore, workspaces attached to it, named catalog, schema, table or volume, external location, storage credential, cloud account and storage path, plus the job or user identity that traverses them. Mark which objects the customer owns, which belong to Databricks, and which are controlled by another provider. The customer should approve a test prefix and synthetic files so the assessment does not enumerate production buckets. If the organization cannot provide a denied workspace or a restricted test identity, list that as a coverage limit before the SOW is signed.
Prove catalog binding through query outcomes
Databricks says catalogs are generally available to workspaces attached to the same metastore unless binding restricts them. For a bound catalog, access from an unbound workspace is denied even when the user holds an explicit data privilege. The automatically created default workspace catalog is an exception: it is initially bound only to its own workspace. Databricks, Workspace-catalog binding A tester must therefore record the selected catalog's actual binding mode rather than assume every catalog shares one default.
Create or identify a synthetic table in the selected catalog and give the test principal the privileges needed for the planned query. Databricks' setup guide notes that accessing data normally requires both the operation privilege and relevant parent usage privileges. Databricks, Unity Catalog setup guide Query the same table from an approved workspace and an unbound workspace. Preserve the workspace identity, principal, catalog binding, grants, query outcome and any error category. If the approved query fails, check missing usage grants and compute configuration before interpreting the denial as a successful binding control.
The matrix deliberately tests data access rather than whether the catalog's name is visible. Databricks notes that metastore administrators and catalog owners can still see a catalog that is not bound to the current workspace, although its children are not visible or queryable there. Databricks, Workspace-catalog binding Visibility for a privileged operator is therefore not the same result as query authorization. A report that calls a grayed-out catalog an access bypass would misstate the platform's documented behavior.
The acceptance result should identify the specific policy. If a catalog is intentionally open to several workspaces, access from a different attached workspace is not automatically a defect. The buyer must say which workspace should be denied. If the reason for isolation is a regulated dataset, record the owner-approved boundary and the named data objects within it; do not treat an unspecified production/development label as a complete authorization rule.
Exercise external-location privileges separately
Databricks documents that an external location is open to all workspaces in the metastore by default. A principal with READ FILES on that location can exercise that privilege from any attached workspace unless workspace binding limits it. Binding is checked when the principal exercises a location privilege, alongside the ordinary privilege check. Databricks, Manage external locations This calls for a direct location test, not a table query offered as a substitute.
Place a synthetic file under an approved test prefix. With a principal that has the required location privilege, attempt the same read from an allowed workspace and a workspace that the data owner expects to be denied. Collect the external-location description, its grant list, workspace assignments, storage path and both observed outcomes. The Databricks management guide documents DESCRIBE EXTERNAL LOCATION and SHOW GRANTS ... ON EXTERNAL LOCATION as ways to capture configuration. Do not broaden the test to unrelated paths because a prefix is readable.
For write controls, the expected result needs extra care. Databricks states that WRITE FILES also requires READ FILES on the same external location; a denial with only WRITE FILES granted would be an invalid test fixture. It also documents a read-only setting for an external location, which can block writes despite broader Unity Catalog or underlying IAM write permissions. Databricks, Manage external locations Use a disposable synthetic object and an owner-approved cleanup plan if a write test is needed. Preserve the relevant privilege combination and read-only setting with the observed decision.
Do not interpret an existing table's behavior through the wrong control. Databricks says that if an external location is subsequently unbound from a workspace, an external table created earlier using that location continues to function. Its binding check occurred when the location privilege was used to create the table. Databricks, Manage external locations To assess a later table query, examine the catalog's binding and table privileges. To assess a new action on the location, attempt that new action separately. The report should make this time and object distinction explicit, especially when a remediation plan proposes unbinding an external location as the only fix.
Separate catalog, location and cloud read-only controls
“Read-only” can refer to different controls with different owners. Databricks permits a catalog to be bound to a workspace with read-only access, which blocks writes from that workspace to the catalog. An external location does not offer a read-only workspace binding type. The external-location object can instead be marked read-only, which blocks writes to files under it even if the Unity Catalog grant and underlying IAM role would otherwise permit writing. Databricks, Workspace-catalog binding and Manage external locations A cloud IAM policy may independently deny writes to the storage path. A buyer who asks whether a workspace is “read-only” should say which of these boundaries is the actual acceptance criterion.
Design the cases around the intended operation. If the requirement is that analysts may read a catalog but cannot update its tables from a development workspace, compare an approved read with a disposable table write from that workspace and preserve the catalog's binding type. If the requirement is that no job may write files through a particular external location, use a synthetic path and an identity that deliberately has both READ FILES and WRITE FILES; then verify the external-location read-only setting and the observed denial. A test identity with no write grant would not prove that setting works. Databricks notes that the location setting can take time to reach compute resources, so record when it was changed and test after it has propagated. Databricks, Manage external locations
For an IAM restriction, compare the storage credential's cloud role and its policy with the approved storage path. A Databricks denial alone cannot show whether cloud policy would also deny the action. Keep the result labels precise: catalog write denied, direct location write denied, or cloud path write denied. The same visible “permission denied” message can lead to different remediation owners. An enterprise team can then decide whether to narrow a catalog binding, change the external-location setting or grant, or edit the cloud role, instead of applying a broad change to every layer.
Inspect storage credentials and cloud IAM
On AWS, Databricks describes a storage credential backed by an IAM role and an external location that pairs that credential with an S3 path. Databricks, Connect to an AWS S3 external location A cloud security owner should review the role's trust and permissions against the path the data team intended to expose. The assessment should compare the S3 policy resource scope with the external-location URI and the synthetic prefix, then validate only approved actions within that prefix.
This is a separate trust boundary because a Unity Catalog denial cannot establish what happens if the cloud identity is used through another approved route. Conversely, a restrictive IAM policy can produce a failed test even when the Databricks grant and binding would otherwise allow it. The report should assign the root cause to the policy layer observed in evidence: missing catalog binding, open external location, broad location grant, overbroad cloud role, or a combination. “Cloud storage exposed” is too vague to guide an owner to the right fix.
The SOW should state whether cloud-side validation is authorized. Some buyers will permit policy review but not live S3 actions. In that case the report can identify a broad permission as a configuration observation, while the dynamic finding remains limited to the Databricks path actually tested. Do not portray an unperformed cloud action as demonstrated access. Do not include credentials, token values, production object names or raw sensitive records in the evidence handed to procurement.
Exercise the identity used by jobs
Databricks says service principals may authenticate to its APIs with OAuth tokens or personal access tokens. Its documentation recommends OAuth where supported and notes that PATs are limited to workspace-level APIs. Databricks, Manage service principals For an enterprise assessment, inventory the actual service principal assigned to each selected ingestion or transformation job, the way it authenticates, its Unity Catalog grants and the workspace where the job executes. A test using an administrator's interactive identity will not prove what that production automation can do.
Build an approved job fixture that reads or writes only synthetic data. Run it under the job's assigned identity from its intended workspace, then compare a deliberately restricted test identity or workspace. Record both the job configuration and runtime identity. If a credential rotation or revocation test is in scope, coordinate it with the job owner and define a rollback; breaking a production pipeline is not a necessary proof of least privilege. Distinguish platform API authentication from data authorization: a valid OAuth token identifies the caller, while grants and bindings decide the data action.
Ask how permissions are maintained over time. A service principal may have a broad grant because several jobs share it. The buyer should decide whether to split identities, narrow object grants, restrict workspace access, or change the underlying cloud role. The best remedy depends on which test case failed; avoid prescribing a new credential type when the actual problem is an open external location or excessive table grant.
Correlate results with available audit evidence
Databricks documents the system.access.audit table for account activity and currently labels it Public Preview. Its schema includes workspace, event time, identity, service, action and request information; identity metadata can distinguish the initiating actor from the identity used for authorization. Databricks also notes regional visibility and masking of some request parameters. Databricks, Audit log system table An SOW should require the security team to confirm that the relevant audit source is enabled and accessible before promising complete correlation.
For each selected case, preserve the test window, workspace, principal, object, operation and observed result, then request the corresponding audit record. A missing record can mean a telemetry limitation, a delay, a permissions problem or a test that did not reach the expected service. Do not silently translate absence into “the control failed to log.” If cloud-side S3 actions were authorized, ask the cloud owner for the matching cloud record and correlate it with the Databricks event without copying raw customer data into the pentest report.
The report should distinguish configuration proof, runtime proof and detection proof. A screenshot of the catalog binding establishes intended configuration. A successful or denied query under the documented identity establishes the access outcome. A matching audit event establishes visibility into that selected operation. None replaces the others. Where a log source was unavailable, say so and describe the impact on the evidence rather than generalize about all Databricks activity.
Interpret mixed results before naming a finding
Mixed outcomes are expected when controls govern different objects. If a user with READ FILES can read a test file through an open external location from a development workspace, while the same user's table query in a production catalog fails there, the two outcomes can both match their respective binding rules. The finding, if any, is whether the customer intended the direct location read. If a previously created external table still answers queries after its location is unbound, check the catalog and table authorization before describing a location-binding failure. Databricks, Manage external locations and Workspace-catalog binding
Likewise, a failed write with an apparently broad IAM role may reflect the external-location read-only setting, while a failed direct file read may simply mean the test principal lacks READ FILES. For each surprising result, preserve the workspace, principal, operation, grants, binding, read-only state and cloud policy before assigning severity. This small diagnostic step prevents the report from recommending an IAM change to fix a catalog binding or treating a fixture error as effective least privilege. It also gives the buyer a clear retest: repeat the same operation under the same identity after changing the one control that caused the deviation.
Define deliverables and stop conditions in the SOW
A buyer can turn the matrix into acceptance criteria: the selected catalog is queryable in its approved workspace and denied in an unbound workspace; the permitted READ FILES action works against the synthetic prefix only from an approved workspace; an existing external table is evaluated under documented binding semantics; the cloud role is no broader than its approved path; and the selected service principal completes its intended job without gaining unrelated data access. Each criterion should name the fixture, actor, object, workspace and expected outcome.
List the metastore, workspace identifiers, catalog and external-location names, storage credential, cloud account and test prefix. Include the owner who authorizes each action, test window, request and write limits, monitoring contact, stop condition and cleanup responsibility. If the assessment includes a third-party BI connector or another cloud account, secure that owner's authorization and add a separate acceptance test. Permission to use a Databricks workspace does not by itself authorize testing the managed service, every attached workspace or an external vendor's system.
Require a deliverable that groups the positive and negative observations for each boundary, includes sanitized configuration and runtime evidence, attributes the root cause to the right control owner, and names limitations. Useful limitations include unavailable denied workspace, missing cloud IAM review, nonrepresentative test storage, lack of audit access and jobs that could not safely be run under their production identity. This makes a scope gap visible to procurement before it is mistaken for assurance.
Retest the exact failed boundary
For a catalog-binding finding, restrict the catalog to the approved workspaces and repeat the same synthetic table query from both workspaces. For an external-location finding, change the location binding or grant and repeat the direct location operation, not only a table query. For a cloud IAM finding, narrow the role policy and repeat the cloud-side test within the approved prefix. For a job-identity finding, change the principal's grants or assignment and rerun the synthetic job under the real automation identity. Databricks documents these as separate objects and authorization checks. Workspace-catalog binding, Manage external locations, and Connect to S3
A retest should preserve the original actor, workspace and object context, plus the intended permitted case. A fix that makes every action fail can hide the excessive access by breaking the legitimate workflow. Check that the authorized operation still works and that the forbidden operation is denied. If an external table remains queryable after location unbinding, evaluate that result against the catalog and table policy, not as an automatic failure of the location change. Close the finding only when the specific control that failed has been demonstrated in its intended state.
What Stingrai can scope
Stingrai is a CREST-accredited penetration testing company with human-led web, API and cloud testing for regulated and enterprise environments. A quote for this topic should begin with the named customer-owned assets and their authorization boundaries. The testers can compare role or identity behavior, document confirmed findings with proof and remediation guidance, and retest remediated findings. Stingrai's service overview describes the available assessment areas.
A one-time assessment can answer a defined procurement or audit question. For a changing integration or cloud configuration, the buyer may choose a continuous program as well. The SOW should state the coverage and evidence expected in either model. Findings should support the customer's own security and audit program without substituting for the customer's control ownership.
Frequently Asked Questions
What should a Databricks Unity Catalog security test cover?
It should cover named catalogs, external locations, workspace bindings, storage credentials, service principals, underlying cloud IAM and relevant access logs, with positive and negative cases using synthetic data.
Why test two workspaces?
Workspace binding is a separate access dimension. The same user and data privilege can have a different result depending on which workspace is bound to the object.
Does unbinding an external location disable existing external tables?
Databricks documents that an existing external table can continue to function after the location is unbound. Test the exact intended control and avoid interpreting that documented behavior as a defect by itself.
What should procurement ask a tester to deliver?
Ask for a boundary diagram, test identities and fixtures, observed workspace-by-workspace results, cloud IAM context, redacted evidence, coverage limits and retest criteria.
Related reading
Talk to Stingrai
Share the assets, identities and expected access decisions you want tested. Get a Quote or book a free discovery call to define the authorization boundaries and deliverables.
