Databricks vnet peering

Question

Environment:

• Single Azure subscription
• One resource group rgA, containing a vnet vnetA and some other resources
• I have contributor rights to this resource group.

Done:

• I created a Databricks workspace myDatabricks.
• I created a vnet peering from within the Databricks resource, following this guide.
• Step 1 was working fine (creating the unidirectional peering to my vnetA.
• Step 2 doesn't work as described, since the portal on my vnetA always wants to create a pair of vnets.
• Therefore, I used the following Azure CLI command: az network vnet peering create
  --resource-group rgA
  --name peering_a_databricks
  --vnet-name vnetA
  --remote-vnet /subscriptions/da52c3...some...custom...data.../providers/Microsoft.Network/virtualNetworks/workers-vnet
  --allow-vnet-access
  --subscription da52c3...some...more...data

Issue:

This fails with the following error:

(LinkedAuthorizationFailed) The client 'johan...@...' with object id '265...' has permission to perform action 'Microsoft.Network/virtualNetworks/virtualNetworkPeerings/write' on scope '/subscriptions/da52c3.../resourceGroups/rgA/providers/Microsoft.Network/virtualNetworks/vnetA/virtualNetworkPeerings/peering_a_databricks'; however, it does not have permission to perform action 'peer/action' on the linked scope(s) '/subscriptions/da52c3.../resourceGroups/myDatabricks/providers/Microsoft.Network/virtualNetworks/workers-vnet' or the linked scope(s) are invalid.  

Question:

• Is this due to my limited contributor rights?
• Is this a fundamental issue? I had a similar message when trying to do it with the double pairing from the Azure portal.

Answer 1

Hello @Johan Van Noten , Thank you for reaching out. Yes this might be due to your limited contributor rights. As per the documentation here to work with virtual network peering must be assigned to the following roles:

Network Contributor: For a virtual network deployed through Resource Manager.
Classic Network Contributor: For a virtual network deployed through the classic deployment model.

If you have created a custom role you should following action assigned to work with Virtual Network peering

Regarding your second question.

Is this a fundamental issue? I had a similar message when trying to do it with the double pairing from the Azure portal.

I am not sure what you meant by double pairing but the issue will occur if you role does not have actions mentioned above.

Hope this helps. Please let me know if you have any additional questions. Thank you!

Answer 2

Dear @ChaitanyaNaykodi-MSFT , thanks for your reply.

First question:

Unless I'm mistaken, my role as a "Contributor" (the default one, not customized) includes the roles that you have requested (Network contributor and Classis Network Contributor), no?

Moreover, it doesn't seem to complain about my vnet in my resourcegroup, but instead about a required "peer/action" on Databricks' resource group.
It seems impossible though to make me contributor on the Databricks resources (which might be normal since it is a SaaS).
When we tried to assign me "Contributor" rights on the Databricks instance, we got a "Sytem Deny" error.

Failed to add Role assignment
Failed to add Johan Van Noten as Contributor for databricks-rg-adb... : The client 'ourAdmin@...' with object id '7138d...' has permission
to perform action 'Microsoft.Authorization/roleAssignments/write'
on scope '/subscriptions/da52c3f.../resourceGroups/databricks-rg-adb.../providers/Microsoft.Authorization/roleAssignments/27c4f3...';
however, the access is denied because of the deny assignment with name 'System deny assignment
created by Azure Databricks /subscriptions/da52c3../resourceGroups/rgA/providers/Microsoft.Databricks/workspaces/adb...'
and Id 'e0a282ee...' at scope '/subscriptions/da52c3.../resourceGroups/databricks-rg-adb...

Should we try to assign me "lower" rights on the Databricks that are sufficient to perform the operation but are not refused by Databricks' configuration?
It feels strange to see this issue occurring, because I would expect everyone would then experience this issue when trying to peer Databricks, no?

Concerning the second question:

> Is this a fundamental issue? I had a similar message when trying to do it with the double pairing from the Azure portal.

I am not sure what you meant by double pairing but the issue will occur if you role does not have actions mentioned above.

I meant that the normal vnet peering functionality in the portal always wants to create two peerings:

• one from A to B
• one from B to A

In my case that is not desired, since the latter one is already established (from Databricks to my own vnet, following the prescribed solution).
The portal does not allow me to just create the one "missing" peering from my vnet to Databrick.

Johan

Answer 3

Dear @ChaitanyaNaykodi-MSFT ,

In the meantime my "global admin" has created the desired peering exactly the way that I did it.
So it seems to be just a problem of rights.

The question therefore boils down to:

• I already have Contributor rights on a single resource (my resource group) within our subscription.
  What rights should our Global Admin assign to me so that I am able to establish this peering to Databricks myself?
  This is a use case that we will often encounter.
• The documentation on this page does not seem to be accurate since it doesn't take into account the (probably changed) behavior of the portal: the portal always desires to make both sides of the peering, which is not the righ way to do it. The documentation should mention the correct way (e.g. through the Azure CLI).

Thanks,
Johan

Answer 4

Hello @Johan Van Noten , apologies for the delay and thank you for letting me know the issue was resolved and it was related to rights.
Responding to your queries above.

I already have Contributor rights on a single resource (my resource group) within our subscription.What rights should our Global Admin assign to me so that I am able to establish this peering to Databricks myself? This is a use case that we will often encounter.

The "Contributor" (the default one, not customized) is sufficient to create a Vnet Peering but I think the scope of your rights is limited to your resource group only hence you were unable to create peering from your DataBricks resource group. According to this documentation here In Azure, you can specify a scope at four levels: management group, subscription, resource group, or resource. Scopes are structured in a parent-child relationship. You can assign roles at any of these levels of scope. Now based on your organizations policy if you can get a role assigned to you which grants you with the actions (The screenshot in my answer above) you should be able to perform vnet peering for that resource group. You can also get role assigned to you at the subscription level which gives you access to all resource groups within it. You can go through this document to list down Azure Role assignment for a user.

The documentation on this page does not seem to be accurate since it doesn't take into account the (probably changed) behavior of the portal: the portal always desires to make both sides of the peering, which is not the righ way to do it. The documentation should mention the correct way (e.g. through the Azure CLI).

Thank you for reporting this document feedback. If you don't mind, could you please create a document feedback item regarding the same? So that we can direct it to the correct team. You can find the feedback button at the bottom of the document link you shared above.

Hope this helps. Please let me know if you have any additional questions. Thank you!