Operating in the public cloud is a whole different ball game compared to on-premises data centers, both technically and commercially. And when it comes to multi-tenant configurations, things can get even more complicated. That’s why I’m excited to share with you a scenario that requires setting up Azure Storage Service Endpoint in a multi-tenant configuration. And the best part? This is not documented anywhere, at least not in one page like this. So, let’s dive in!
Sample Scenario
- Imagine we are Company A (CA) and we have our own Azure AD Tenant, and Azure Subscription in Azure Southeast Asia region.
- Now let’s say we need to use an app and fetch files from Company B (CB) from an Azure compute service in our subscription.
- However, without our knowing, CB’s Azure Subscription is also in Southeast Asia region, and they have restricted access to their Azure Storage Account to select VNETs and public IP addresses.
It’s Different on the Cloud
In this case, many Azure users think they need to share the public IP of their Azure compute service (i.e., public IP of the virtual machine, or of the firewall) with CB to get it whitelisted on CB’s Azure storage account. However, this is not the case. According to Microsoft’s Azure Storage documentation, this approach will not work.
Wishing the context of what we described here, if you continue to whitelist the public IP address of the Azure services accessing the storage account in a different tenant and different Azure subscription, you will not be able to to access any files in the storage. That’s because the private IP of our Azure services will be used to communicate with CB’s Azure storage account instead of the public IP that’s whitelisted. In CB’s storage logs, CB will see our private IP as the source and there’s an error 403 (authorization failure).
Since we can’t whitelist private IP address and public IP address is not used in this case, we need to use a different approach…
Use Azure Storage Service Endpoints in Multi-Tenant Configuration
I’ll assume that we (or Company A) already have an Azure virtual machine that’s connected to demo-ca-vnet
and democahostssubnet
. I’ll also assume that Company B (CB) already has an Azure storage account and have selected Public network access: Enabled from selected virtual networks and IP addresses
.
1. CB needs to create a multi-tenant Azure Enterprise Application
2. Then CB needs to create a Secret Key
for this app.
In Azure Portal, go to Azure AD → select Enterprise Applications → search and select the multi-tenant application from step 1 → click on Single sign-on and then click on Go to application on the right pane:
In the app page, select Certificates & secrets → click New client secret → and then click Add. CB needs to copy and save somewhere the Value that will be generated. CB needs to give us (or Company A) the Application ID of this app.
3. Then CB needs to give this enterprise app an Azure role on the Azure storage account.
4. Now we will go to our (or Company A) Azure Subscription and give the enterprise app from step 1 a role on our VNET. We will assign a custom role to it to give it the least privilege necessary since this app is from a different company after all.
In our Azure Portal, go to Subscription → select Access control (IAM) → add a custom role here:
As for the role or permission, we want to create Microsoft.Network/virtualNetworks/subnets/joinViaServiceEndpoint/action
Now let’s create a service principal that will have this role at the VNET level only that needs to access CB’s Azure Storage Account. Use this Azure CLI command to create the service principal:
az ad sp create --id "<CBenterpriseAppID>"
And then assist this custom role to this service principal on the VNET:
5. We (or Company A) need to enable Service Endpoint: Microsoft.Storage on the subnet within the VNET, and then share the subnet’s Azure resource ID to Company B (CB).
6. Now CB must login to their Azure using PowerShell and the Enterprise App (from step 1) and allow our (or Company A) subnet in the network rule of their Azure Storage.
To be able to login to Azure using Powershell and Enterprise App, CB needs to convert the Enterprise App key to something usable and here are the PowerShell commands to do it:
$usr = "<applicationID>" $pswd = ConvertTo-SecureString -String "<secretValue>" -AsPlainText -Force $cred = New-Object -TypeName "System.Management.Automation.PSCredential" ` -ArgumentList $usr, $pswd Connect-AzAccount -ServicePrincipal -Credential $cred -Tenant "<tenantID>"
CB should have <applicationID>
and <secretValue>
from step 1 and step 2. Here’s an example:
For CB to allow our subnet in their Azure Storage Network rule, they need to do something similar via PowerShell:
As of now, there’s no way to allow VNETs from another tenant and other subscription using the Azure Portal.
With the right combination of storage access (e.g., SAS), we should be able to access the files stored in the storage account of Company B.