Core data platform resources are defined within Terraform templates and grouped inside deploy/azure directory. There are two subfolders in this directory:
infra subfolder contains the following definitions:
- Resource Group
- Azure SQL Database sample instance with database schemas
- Key Vault
- Key Vault Secrets:
- Connection strings for the created SQL databases
- Passwords to the SQL Databases
- Service Principal Secret
- Azure Tenant ID – Directory ID for Azure Active Directory application
- Azure Client ID – Application ID for Azure Active Directory application
- Databricks access token & host
- Other secret names with empty values to be replaced manually. Existing secrets are not overwritten.
- Azure Data Lake Storage Gen2
- Azure Blob Storage
- Databricks Workspace including:
- Key Vault-backed secret scope
- Azure Data Factory including:
- Managed identity for the service instance;
- Managed virtual network enabled by default. Creating an integration runtime within a managed virtual network ensures the data integration process is isolated and secure.
- Managed private endpoints created in the Data Factory managed virtual network, these
establish private links to Azure resources, such as:
- Blob Storage
- Azure Data Lake Storage
- Key Vault
- SQL Database
- Databricks Workspace
- Databricks Browser Authentication Page
- Role assignments that assign ADF managed identity roles to access the resources linked by the private endpoints.
- Log Analytics Workspace
Using a private network is the default behaviour in the Ensono Stacks Data Azure Platform. The
subfolder contains configurations for the created network and subnetworks, at its core using
Ensono Stacks Terraform module. See Microsoft documentation for more details on implementing Hub-spoke network topology in Azure.
The following diagram shows network configuration for the two default environments:
- Hub network (
- Nonprod (
- Prod (
Databricks secure cluster connectivity
Ensono Stacks Azure Data Platform uses VNet injection to deploy Databricks into a custom virtual network.
In most scenarios, we recommend that Azure Databricks is deployed in a fully secure manner, using secure cluster connectivity and disabling public workspace access. This means that Databricks can only be accessed over a private endpoint from within the private network. This also means that projects would need to have networking prerequisites such as ExpressRoute or VPNs in order to access the workspace. If this is not possible, then a virtual machine will need to be set up within the transit subnet. Users will then need to RDP into the VM and access the workspace via that.
Even without public IPs and with the data plane deployed into our VNet, there is still the option to toggle access to the Workspace UI via public networks. The default configuration disallows access to the Databricks workspace over the public internet in production environments, while leaving it open in development environments. This approach enhances the developer experience in case there is no properly configured networking/VPN set up in the target subscription.
Enabling public workspace access only opens access to the UI via public internet. Access is still restricted based on the IAM policy.
The following diagram depicts the Databricks network configuration.