Azure Lab 01: Hide Your Public Connection From PaaS To Storage Account

Using PaaS resources in Azure brings convenience to developers such as saving times, concentrating on coding, and etc. However, there is a paradox which convenience and secure might never on the same direction.

Your customers might challenging you by exposing the inter-connection among resources under public networks. For example, You builded a Function App for tracking customers’ information and storing them in to a Blob container (from a Storage Account). Meanwhile, connections invoked by that function uses public domain name to the container, which means those requests might have a great opportunity routing outside.

For security purpose such as ISO/IEC 27001, you may want your resources to co-op privately, however, detail network settings among PaaS services are extreamly hard to find (at least for me, a pure newbie). So this article is my research for connecting PaaS devices such as Azure Function App to a Blob container under private network (and cross region).

Here is the outline, I will inreoduce 2 methods: Service Endpoints and Private Endpoints, help you to protect your connection.

Outline

  1. Service Endpoints
  2. Private Endpoints
  3. Additional Information
  4. Conclusion
  5. References

Service Endpoints

A quick conclusion: We cannot perform a cross-region private connection under a Service Endpoints settings.

Service Endpoints is a combination of settings related to “route for the inter-resource connections by avoiding expose them under public networks”. For example, a function app invoking an outbound request to a blob container under a domain named “someblobs.blob.core.windows.net”, then, a DNS server resolve that name to an IP address of that container, and you all know the rest of the things.

The point is, “someblobs.blob.core.windows.net” via resolvable in Global DNS server and you will retrieve a public IP address from that, even thought you can directly reach to that resource through private network. In some special cases under the function app and blob container are located in the different regions, you may not have a chance to achieve such a purpose.

If you don’t mind, studying from this part is a goot way to start. Let’s go to the Azure portal and create a Resource Group.

Column NameValue
Resource group<you specified>
Region<you specified> e.g., Japan East

Create a Log Analytics Workspaces inside that Resource Group.

Column NameValue
Name<you specified>
Region<you specified> e.g., Japan East

Create 2 Storage Accounts, one of them in the region is the same with the Resource Group, the other is different from it.

Column NameValue
Storage Account Name<you specified>
Region<you specified> e.g., Japan East / West US

Inside 2 Storage Accounts, create a Blob container from each of them.

Column NameValue
Name<you specified>
Public Access LevelBlob

Inside 2 Blobs, upload a test file to each of them, you can create a file named “test” and write some message in it, and upload through Azure portal.

Last step of the Storage Account, go to the Diagnostic Settings and add a setting on it. We use it to determine the behavior to the blob such as information (source IP) from the requests.
Left side manu > Monitoring > Diagnostic Settings > Blob (under your Storage Account Name) > Add diagnostic setting

Column NameValue
Diagnostic Settings Name<you specified>
CategoriesStorageRead
Destination DetailsSend to Log Analytics workspace
Log Analytics Workspaces<you specified>

Now we start creating our Function App. We are using Functions Premium plan because it supports Virtual Network Integration, thus, please ensure to remove all the resources once you’re finished testing.

Column NameValue
Resource Group<you specified>
Function App Name<you specified>
PublishCode
Runtime StackNode.js
Version14 LTS
RegionJapan Esat
Operating SystemWindows
Plan TypeFunctions Premium
Windows Plan<you specified>
Sku and SizeEP1
Storage Accountplease do not use your previous created ones
Enable network injectionOff
Enable Application InsightsNo

Please download the sample codes from my Github, consider the readme file and make some changes to fit your experiment. Finally deploy it on your Function App.

git clone https://github.com/theringe/AzureSupportLabs.git --branch lab01
cd AzureSupportLabs
# consider the readme file and make some changes
zip -r --symlinks AzureSupportLabs.zip .
az functionapp deploy --resource-group <you specified> --name <you specified> --src-path AzureSupportLabs.zip

Now by accessing the function triggers (there are 2) via the following URLs, they may invoke a GET request to the blob file from the container:

https://0502lsecpriendplfuncapp.azurewebsites.net/track_a (Function App and Blob are in the same region)
https://0502lsecpriendplfuncapp.azurewebsites.net/track_b (Function App and Blob are in different regions)

You will get an OK message once you click it, and can close it after that.

Now we’re going to the Log Analytics workspace.
Left side manu > General > Logs
Please input the following KQL in the Query Zone

StorageBlobLogs
| where AccountName contains "0502lsecpriendplstorage"
| where OperationName == 'GetBlob'
| where Uri contains "test"
| sort by TimeGenerated desc
| take 10
| project TimeGenerated, AccountName, CallerIpAddress, OperationName

You can see the line with AccountName 0502lsecpriendplstoragea which Function App and Blob are in the same region, the Caller IP Address is 100.79.52.132, which is an interal IP address.
And the line with AccountName 0502lsecpriendplstorageb which Function App and Blob are in different regions, the Caller IP Address is 20.210.7.31, whioh can be found on outbound IP section from your Function App.

It means you are exposing the connection in public when a cross-region inter-connection be invoked, and might get the potencial risk from your system.

Now we’re going to create a Virtual Network for our Function App, to verify whether a Function App inside a VNet can reach the containers under private network or not.

Column NameValue
Name<you specified>
Region<you specified> e.g., Japan East

And then we immediatly specify some subnet range for our Function APP
Left side manu > Settings > Subnets > Add subnet

Column NameValue
Name<you specified>
Subnet Access Range10.1.1.0/24 (i.e., it could be different on yours based on your default suubnet ranges)
All the restuse the default value

Now we’re going back to our Function App and bind it on the VNet
Left side manu > Settings > Networking > Outbound Traffic > VNet integration > Add VNet > Provice the information you’ve just created

In the rest of this part, we gonna make a service endpoint by specifying a VNet from both of your Storage Accounts.
Left side manu > Security + Networking > Networking > Firewalls and Virtual Networks

Column NameValue
Public network accessEnabled from selected virtual networks and IP addresses
Virtual networksAdd Existing Virtual Network
Virtual Netework<you specified>
subnetdefault / (i.e., yes, add them separately)
All the restuse the default value

And please wait for nearly 15 minutes for populating network settings inside Azure.

Maybe you are realizing what’s going on, you cannot specify the VNet from a Storage Account if they are on different regions, so we temporally stop here.

Since you’ve just specify the Function App (Japan East) inside a VNet (Japan East) corresponding to a Storage Account (Japan East), we’re going to check the result by re-invoke a connection

PS: You can restart the Function App before invoking, and then click this link:

https://0502lsecpriendplfuncapp.azurewebsites.net/track_a

And see the result

You can see the line with AccountName 0502lsecpriendplstoragea which Function App and Blob are in the same region, the Caller IP Address is change to the VNet internal IP.

Maybe you’re thinking: why don’t we put a Function App (Japan East) inside a VNet (West US) corresponding to a Storage Account (West US)?

Well, the “Firewalls and Virtual Networks” setting is a passive restriction, use to detect the source information and apply some extra work (e.g., accept, drop) due to rules. So it has no idea how to interrupt the resolving rule from the Function App of a VNet. You still get the public IP address from the Logs when changing to new VNet (West US) and accessing Storage Account (West US). Meanwhile, you cannot even choose the VNet on the binding list from Function App under Azure portal if they are not in the same region.

PS: Although there do have some extra setting would be launch once the “Firewalls and Virtual Networks” are finished setting, we cannot apply this on our situation because we’re on the PaaS service. The extra setting is: Adding a “Effective security rules” to the NIC if there are VMs inside the target VNet. Which used to tell the VM taking internal resolving rules to the “someblobs.blob.core.windows.net” domain.

Finally, the bad news is we now understand why using Service Endpoints between PaaS resources and Storage Accounts under cross-region connection is currently unhidable. And the good news is there are some ways to compromise this kind of issue.

Thus, I am going to introduce the next tool.

Private Endpoints

Private Endpoints shares part of the same purpose from Service Endpoints but more flexible (i.e., which means there are more details settings behind each resources). Now we use the previous resources created from last chapter and keep going.

Firstly we clean up some of the previous resources:

  1. In the first Storage Account, in the “Firewalls and virtual networks”, remove all the VNet, and switch back to the “Enabled from all networks”.
  2. In the Function App, disconnect the (previously binded) VNet from it.
  3. In the Virtual Network, delete the VNet you’ve created on last chapter.

Then, we create a VNet in same regions matching your Function App:

We skip the similar snapshots.

Column NameValue
Name<you specified>
Region<you specified> e.g., Japan Esat

Inside this VNet, we keep creating a subnet form in it

Column NameValue
Name<you specified>
Subnet Access Range10.1.1.0/24
All the restuse the default value

We have to link VNet which under the different region from Function App to the related Storage Account, so go to Storage Account:
Left side manu > Security + Networking > Networking > Firewalls and Virtual Networks > Disable “Public network access”
Left side manu > Security + Networking > Networking > Private Endpoint Connections > Add Private Endpoint

Column NameValue
Name<you specified>
Region<you specified> select the VNet under the same region from Function App
Target sub-resourceBlob
Virtual Network<you specified>
subnetdefault

You might find the tricky part: you can specify the region of your VNet different from the private endpoint of your Storage Account, that means we could logically invoke an internal connection from our Function App to the blob.

Now go to the Private DNS zones:
Left side manu > Settings > Virtual network links > Add

Column NameValue
Link Name<you specified>
Virtual Network<you specified>
Auto-Registrationcheck

PS: You may already found one on the list, if so, please delete it first

This step grants the ability to the target VNet which could use the internal name resolving rules form my Private DNS zones, and is the key step to override the VNet’s resolving rule. You have to add each of the VNets from that interface when having a complex VNet chaining topology.

Back to the Function App, and bind it on the VNet
Left side manu > Settings > Networking > Outbound Traffic > VNet integration > Add VNet > Provice the information you’ve just created

Since you’ve just specify the Function App (Japan East) inside a VNet (Japan East) corresponding to a Storage Account (West US) using Private Endpoints (Japan East), we’re going to check the result by re-invoke a connection

PS: You can restart the Function App before invoking, and then click this link:

https://0502lsecpriendplfuncapp.azurewebsites.net/track_b

And see the result

Voila! You can see the line with AccountName 0502lsecpriendplstorageb which Function App and Blob are in the different regions, and the Caller IP Address is change to the VNet internal IP.

Finally, we secure the inter-connectionn among our cross-region PaaS resources with some additional settings and get the information about how the Vnet works. It’s cool isn’t it?

Additional Information

  • You cannot create a new Function App using an existing Blob you’ve create for test, or you will no longer acccessing the file system from the Function App once you disable the Public network access from that Storage Account.
  • Although you disable the Public network access from that Storage Account, the accessing log still occurs on the Log Analytics workspace when there is an outside invoking attempt.
  • For some Function Apps upgraded from consumption plan, you might add a confuguration “WEBSITE_CONTENTOVERVNET=1” to resolve the Storage Accounts’ restriction[1][2].

Conclusion

To achieve cross-region inter-connection, we have to choose a right network resources equipping a “region choosable” feature, such as Private Endpoints in this case.
To resolve the public domain name correctly, we have to add a Virtual Network Link[3] on each of the related VNets.

References

  1. Tutorial: Integrate Azure Functions with an Azure virtual network by using private endpoints
  2. App settings reference for Azure Functions
  3. What is a virtual network link?

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。