Balaji Shinde Thanks for posting your question in Microsoft Q&A. Quickly reviewing ARM template: Confluence Audit data connector, found that storage account was deployed with public network access enabled (default: publicNetworkAccess
- Enabled) with the following parameters:
{
"type": "Microsoft.Storage/storageAccounts",
"apiVersion": "2019-06-01",
"name": "[tolower(variables('FunctionName'))]",
"location": "[resourceGroup().location]",
"sku": {
"name": "Standard_LRS",
"tier": "Standard"
},
"kind": "StorageV2",
"properties": {
"networkAcls": {
"bypass": "AzureServices",
"virtualNetworkRules": [],
"ipRules": [],
"defaultAction": "Allow"
},
"supportsHttpsTrafficOnly": true,
"encryption": {
"services": {
"file": {
"keyType": "Account",
"enabled": true
},
"blob": {
"keyType": "Account",
"enabled": true
}
},
"keySource": "Microsoft.Storage"
}
}
}
However, it is not possible to secure an existing storage account by modifying publicNetworkAccess
property. Refer doc: Restrict your storage account to a virtual network which describe the steps to restrict your storage account to a private endpoint in a VNET while creating a new function app or an existing function app with a new storage account.
So, you can take function-app-storage-private-endpoints ARM template as a guide and modify Confluence Audit data connector template to deploy Azure Functions with a storage account behind VNET (public access disabled). Then configure Network security groups (NSG), Routes (route table) to allow outbound connections to Confluent Audit rest API. With this approach, storage account is restricted and still can access Confluent Audit API.
Note: The Consumption plan isn't supported (supported-networking-features).
I hope this helps and let me know if any questions.
If you found the answer to your question helpful, please take a moment to mark it as Yes
for others to benefit from your experience. Or simply add a comment tagging me and would be happy to answer your questions.