Intro:
I have an asp.net core app service hosted in Azure.
This app service has an API controller that reads/writes to an Azure Table Storage.
The code for this is using Azure.Data.Table library w/ an Access Key that i setup from the Azure portal (for the table storage).
Now, under the storage account / Networking blade, I have selected the "Enabled from All Networks".
Question:
Does this mean this storage account is open to the entire internet? I am confused whether this is secured because my code is accessing it via the Access Key (which I mentioned above).
Thank you.
Regarding the settings above, Enabled from all networks means the storage account endpoints (i.e. blob, table, queue, etc.) will accept traffic from the internet but you still need access key to view any data.
Enabled from selected virtual networks and IP address means that traffic will only be allowed from resources on the same VNET or specific IP address that you've configured e.g. your local device public IP provided by your ISP. This is a more secured method because you essentially whitelisting your what can connect.
Disabled means nothing outside of Azure can access the storage account and you will connect via Private Endpoint.
If your access key is inside your code, then this isn't the best secured method. You would want to have your connection with access key in either Application Settings so it can be retrieved as an environment variable or through Azure Key Vault. Using Key Vault allows you dictate what service or user can retrieve that value.
I will suggest assigning the system assigned managed identity to the app Service. Then use the resource instance rules for storage setting to configure the firewall https://learn.microsoft.com/en-us/azure/storage/common/storage-network-security?tabs=azure-portal#grant-access-from-azure-resource-instances
Related
We have a React app hosted in a storage account (with static website enabled). We have a Azure Front door in front of the storage account.
We are looking at ways to limit access to the storage account, to ensure that only the Azure Front Door could read from it.
We put the storage account in a VNet and tried setting up a private link to allow Azure Front Door access to it. But when setting up the Azure FD profile, we get an error saying The origin type or host name does not support private link.
Is there a way to secure the storage account in a VNet and allow Azure FD access to it? Or is there a better way to secure this?
• Yes, you surely can secure the connection from the Azure Front door to the storage account deployed in a virtual network, to be specific, to a static website hosted in it. For that purpose, you will have to deploy an Azure front door in classic tier and configure the frontend domain hostname as ‘xyzfd.azurefd.net’ and the backend pool hostname target as FQDN ‘storageaccountname.z29.web.core.windows.net’ as shown below as well as enable the routing rules for this configuration by selecting the accepted protocol and the frontend domain for this routing request: -
Once done, ensure to create a DNS zone and create the requisite ‘A’ host DNS records in it pertaining to the custom domain that is registered as the frontend domain/hostname in the Azure front door and similarly create a CNAME record for the same hostname/domain name with the alias being the static website primary endpoint as shown above.
• This will ensure that secure access to the static website is configured through the DNS records registered as above and are accessible through them.
For more information, kindly refer to the below links: -
https://docs.rackspace.com/blog/Azure-Front-Door-Storage-Static-Website/
I have a Storage account in our Azure "https://MysecuredStorageaccount.blob.core.windows.net" where we need to provide access to an external vendor to push the data to our blob. Since it is a PAAS service by default it is accessible with "Shared access Signature" .
However, as part of Security compliance policy in our ORG, i can not allow any service publicly accessible, so i have created a private end points to access Storage account internally.
Do we have any other Network Firewall Solution to allow blob access to external vendor application that too without whitelisting their Public IP in Storage account Network Firewall.
Any Firewall/NAT kind of solution that can be used to provide a secured connection externally.
If it's being accessed manually or from a specific machine/user you can consider Azure Point-to-Site with a VPN Gateway else look into a Site-to-site VPN setup with the vendors firewall.
It's not that hard to setup and will give them access directly to the subnet/IP of your choice. The setup complexity would depend on the firewall the vendor uses but in general its not too bad.
That's the easiest option I can think of.
I have been using azure timer based function in my project.
Since I started using the function, I was getting error 403 related to access forbidden from Azure storage account.
I tried adding AzureWebJobsStorage Key in function's configuration
I tried adding outbound IPs of Allowed ip ranges of azure storage accounts
I tried checking the option of allowing azure managed services to the storage account.
However, I'm still getting the error in that particular timer function of my function app. The other functions run properly.
Although, if I allow all the networks in storage account firewall and VN settings, my function runs proper.
Both the function and storage account are in same region.
I want to enable it somehow that I do not need to choose the allow all networks. What can be done?
In case anyone else is searching for this... I had a similar issue. I had a function app that I had created a private endpoint and regional VNet integration back with the VNet interacting with a Storage Account that also had a private endpoint with the same VNet. The Storage Account's network/firewall settings only allowed connections from the VNet (no external traffic allowed). Both the storage account and function app reside in the same region.
Attempt at fix #1 (not ideal):
I added code to determine what IP the function app was running from. That led me to add all of the IP's in the portal under function app --> Properties --> Additional Outbound IP Addresses. This is exposed by Terraform if using that.
Attempt at fix #2 (better):
The resolution is to ensure you have the proper function app settings set.
See: Microsoft documentation
Setting
Suggested value
Description
WEBSITE_CONTENTOVERVNET
1
Create this app setting. A value of 1 enables your function app to scale when your storage account is restricted to a virtual network.
WEBSITE_DNS_SERVER
168.63.129.16
Create this app setting. When your app integrates with a virtual network, it will use the same DNS server as the virtual network. Your function app needs this setting so it can work with Azure DNS private zones. It's required when you use private endpoints. This setting and WEBSITE_VNET_ROUTE_ALL will send all outbound calls from your app into your virtual network.
WEBSITE_VNET_ROUTE_ALL
1
Create this app setting. When your app integrates with a virtual network, it uses the same DNS server as the virtual network. Your function app needs this setting so it can work with Azure DNS private zones. It's required when you use private endpoints. This setting and WEBSITE_DNS_SERVER will send all outbound calls from your app into your virtual network.
Note: The 168.63.129.16 is a static value for Azure DNS.
After setting all of these, my function app was able to connect to the storage account through the VNet as expected.
There're already some answers about this issue, you can see here and here.
In short, if the function and storage account are in same region, they communicate in an internal way without going through outboundIpAddresses.
The workaround is that create them in different regions.
I have an Azure Storage account and need to enable the storage firewall.
I have added the outbound IP addresses of my App Service, but the firewall still prevents access. (I know that these addresses can change, but they change predictably, so I can live with that.)
Is there a solution to grant an App Service access to the Storage account other than disabling the firewall (and other than using an ASE, which isn't an option)?
So it turns out that in a new Azure Storage account with a new App Service, setting the storage firewall to the outbound IPs of the App Service does work as expected. Unless the client browser is actually doing the download, adding the client's IP is not required.
Edit
This only works reliably when the storage account is in a different data centre to the App Service. When they are both in the same data centre, an internal outbound address (e.g. 10.x.x.x) is presented from the App Service to the Storage account. Internal addresses cannot be added to the Storage firewall.
If you access your web app service from on-premises networks, you need to grant access from your on-premise networks to your storage account with a public Internet-facing IP address used by your network. You can get more details from Grant access from an internet IP range
If you have VNet Integration with your apps. You should first enable service endpoints for storage in the VNet. You can refer to Grant access from a virtual network.
I'm trying to enable Azure DocumentDB firewall by enabling the "Enable IP Access Control".
I managed to allow connections from my App Service. However the webjobs that reside on the app service does not have access to the Azure DocumentDB.
Is there a way to allow web job access to the DocumentDB?
thanks
Is there a way to allow web job access to the DocumentDB?
In short, no.
If we want to enable firewall blocked access policy, we need to add the allowed list of IP addresss or IP address ranges.We can get more info from document. But the Azure WebApp IP is not static.
all of access to your Azure Cosmos DB database account from machines outside the configured allowed list of IP address ranges are blocked
I managed to allow connections from my App Service
If it is meaning that you have turn Allow access to Azure Portal on.
If it is that case, it doesn't mean that we can access DocumentDB from Azure other services, it means that we can peform operations on the collections or docuemtns within account from azure portal.
Without portal access enabled, you will not be able to perform any operations on collections or documents within this account from the portal
In summary, if we want to allow web job access to the DocumentDB then we need to
trun Enable IP Access Control off. Or we could use Azure cloudservice or virtual machine to instead of WebJob.
Edit:
According to your comment, if we want to use the same IP as WebApp, we could use the outbound IP, we can get them from the azure resources(https://resources.azure.com/) then add the outboundIpAddresses to the DocumentDB allowed IP list. Then webjob could access to the DocumentDB.
Note: The outboundIpAddresses are not static ips, they may be changed when we restart the WebApp or change WebApp service plan.