Locking down a port on Azure Databricks (managed resoruce)

Thank you for the reply. I had previously read the VNet injection page, but it's not very helpful for my use case as the Deny Assignment prevents me from making changes to the existing VNets, and the linked page states:

You cannot replace the virtual network for an existing workspace.

It appears my only option to go the VNet injection route is to create an entirely new Databricks workspace and perform these detailed migration steps.

This seems like a lot of work for every single user of a managed workspace at Microsoft to perform, in order to meet Microsoft security requirements because the first class Microsoft-managed service is non-compliant. It makes no sense that the Microsoft managed instance is completely unusable to internal Microsoft customers.

I will pursue a support request with Databricks.

Hello @Daniel Widdis ,

Yes, you cannot replace the virtual network for an existing workspace. If possible, I would suggest you to create a new workspace.

If you have a support plan you may file a support ticket, else could you please send an email to azcommunity [at] Microsoft [dot] com with the below details, so that we can create a one-time-free support ticket for you to work closely on this matter.

Subject of the email: <ATTN: PRADEEP - Locking down a port on Azure Databricks (managed resoruce)>

Thread URL: Databricks Notebook - Microsoft Azure - Autocompletion is NOT working when attached to cluster

Subscription ID:

Please let me know here once you have done the same.

I have just sent the requested email.

Hello @Daniel Widdis ,

Thank you for reaching out.
We have enabled for one-time free technical support.
I hope you have received one on one support to work towards a resolution on this matter.
Once the issue is sorted out with the support, please do share the resolution, which might be beneficial to other community members reading this issue.

As a follow-up, the reply to my ticket indicated that the audits were incorrect and triggered on re-used IP addresses. The audits did go away after 24-48 hours. Here is the verbatim response:

When Databricks workspace is non VNet-injected, worker-sg is a managed resource and users are not allowed to modify it.

We confirm that Databricks uses Linux VM and doesn’t listen port [obfuscated].

The IPs used by Databricks are in a resource pool and can be shared by other Azure services. When a cluster in Databricks is started, there will be some public IPs attached on it, and when the cluster is terminated, these IPs will be released to the pool and can be used by other Azure services later on.

I think there are some delay on the scanning tool, so actually these IPs are already used by other Azure windows service and you saw the alert. But from Databricks, we never open these ports.