Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Databricks uses the DBFS root directory as a default ___location for some workspace actions. Databricks recommends against storing any production data or sensitive information in the DBFS root. This article focuses on recommendations to avoid accidental exposure of sensitive data on the DBFS root.
Note
Azure Databricks configures a separate private storage ___location for persisting data and configurations in customer-owned cloud storage, known as the internal DBFS. This ___location is not exposed to users.
Important
Starting on March 6, 2023, new Azure Databricks workspaces use Azure Data Lake Storage storage accounts for the DBFS root. Previously provisioned workspaces use Blob Storage.
Educate users not to store data on DBFS root
Because the DBFS root is accessible to all users in a workspace, all users can access any data stored here. It is important to instruct users to avoid using this ___location for storing sensitive data. The default ___location for managed tables in the Hive metastore on Azure Databricks is the DBFS root; to prevent end users who create managed tables from writing to the DBFS root, declare a ___location on external storage when creating databases in the Hive metastore.
Unity Catalog managed tables use a secure storage ___location by default. Databricks recommends using Unity Catalog for managed tables.
Use audit logging to monitor activity
Note
For details about DBFS audit events, see DBFS events.
Encrypt DBFS root data with a customer-managed key
You can encrypt DBFS root data with a customer-managed key. See Customer-managed keys for DBFS root
Important
Do not disable Storage account key access for the storage account backing the DBFS root. Disabling this setting leads to unexpected behaviors and errors.