we have the following scenario
we have an api running in a azure app service, which accesses file in a blob container that has anonymous read access enabled, all is working well.
now our requirement is to move the app service and storage account into a vnet with private endpoints.
Questions
once we move both of these into a VNET will the app service be able to access the blob container anonymously ? the third party library that we are using needs anonymous access to this blob, so that it parse and do its job.
Thanks -nen
Related
I'm nearly done migrating our cloud service (classic) deployments to cloud service (extended support). I'm working now on updating deployment pipelines. My package blob is located in a storage account. I create a SAS for the blob and use an API call to management.azure.com to create/update the deployment, passing ARM template as the body of the request.
This works correctly as long as the storage account with the package blob has its network set to "allow access from all networks". I want to restrict this access. I set the allow access from:
specific IP addresses of our devops servers
our own IP addresses
private vnet/subnets for the cloud service
I also tick the "Allow Azure services on the trusted services list to access this storage account" checkbox.
Yet, API call fails with error message indicating access is not allowed to the blob. When I change the storage account network configuration to "allow access from all networks", everything works correctly.
With lots of searches, I found only one hit explaining the same problem - https://github.com/Azure/azure-powershell/issues/20299 - yet no solution has been suggested other than allowing access from all networks.
I must be missing some trick - but what is it? How can I restrict access to the storage account?
We are trying restrict public access from an Azure Storage account. We only want an App service (Web API) and a Function app to communicate to the Azure Storage account. We created a VNet and a Subnet inside it; moved the App service and the Function app into the same App service plan; and configured both the App service and Function app within the same VNet/Subnet. In the Azure Storage account's Networking tab, we restricted access to the VNet/Subnet as shown below.
The function app uses a Queue Trigger and the Azure queue exists within the same storage account we are trying to lock down.
Our situation is that the App service plan is managing to connect to the storage account (via the Shared access keys). However, the function app is not even picking up the items from the queue. This means that the function app code is never hit (first logs are not written in the Application insights and the actual communication with the Storage account via the Shared access keys is never reached). This is very likely related to the new network changes, because when the storage account is made public again, the function app works again, as expected.
This is a bit strange, because the app service and the function app have the same VNet / Subnet configuration. Our previous Function app version was consumption based and we migrated into an App Service plan based function app to be able to manage this.
Do function apps require a different configuration from app services? Particularly ones with QueueTriggers? Does the QueueTrigger not allow access in such a way?
we have a blob container with anonymous access (open to internet) and an appservice talking to it.
What are our options of ensuring that only the appservice can talk to this storage endpoint? vnet integration is our last option.
Thanks -nen
What are our options of ensuring that only the appservice can talk to
this storage endpoint?
One option would be to make use of Azure Role Based Access Control (RBAC) Data roles.
For this, first you would assign a managed identity to your App Service and then assign that identity appropriate Azure Storage RBAC data roles.
You would also need to block access to the storage account via access keys or shared access signature so that only your App Service can connect to your storage account using Azure AD authorization.
You can read more about it here: https://learn.microsoft.com/en-us/azure/storage/blobs/assign-azure-role-data-access?tabs=portal.
I have a App Service with a managed identity assigned to it to simplify connections to azure resources. I want to use DataProtection where the app stores the xml-keys in an Azure Storage Account(blob) to persist them between deploys.
Whenever I start the app I get a authentication error:
Microsoft.Azure.Storage.StorageException: This request is not authorized to perform this operation.
at Microsoft.Azure.Storage.Core.Executor.Executor.ExecuteAsync[T](RESTCommand`1 cmd, IRetryPolicy policy, OperationContext operationContext, CancellationToken token)
at Microsoft.Azure.Storage.Core.Executor.Executor.<>c__DisplayClass0_0`1.<ExecuteSync>b__0()
at Microsoft.Azure.Storage.Core.Util.CommonUtility.RunWithoutSynchronizationContext[T](Func`1 actionToRun)
I have assigned several different RBAC roles to the App Service without any succes, including:
Storage Data Owner
Storage Data Contributor
Storage Data Reader
Owner
The Storage Account is connected to a VNET and not open to the internet. THe App service is not connected to the same VNET.
I have then tried to whitelist the App services many outgoing IP-adresses in the Storage Accounts Network-section, which states "Add IP ranges to allow access from the internet or your on-premises networks."
Also have "Allow Azure services on the trusted services list to access this storage account" activated.
Any ideas whats missing? This is happening only when in the app service, from my debug-localhost I can connect, so seems related to azure networking somehow.
According to the description in your post, I can be pretty sure that your identity configuration in the portal is correct, and your code is also completely correct.
The only problem is that your app services cannot access vnet. The simple description is that the azure storage account is connected to the vnet, which is equivalent to being isolated by the vnet protection. The app service needs to access the storage account, and it must first connect to the vnet.
From the Azure portal I would like to programmatically and periodically create a service SAS token. Once a token has been created it should expire in one week and a new token also valid for one week will be created and so on. I was reading this article https://learn.microsoft.com/it-it/azure/storage/blobs/sas-service-create?tabs=dotnet but I am not very sure about where that code should run, in a Azure VM? I can't give internet access to the VM
The code from the article can be run from any compute service.
If that is the sole purpose of the compute resource, I would pick Logic Apps to have everything managed for you; it may have a connector to do it or you can embed some JavaScript.
Should that not be sufficient, I would use an Azure Function.
You can also use a VM if that is more suitable and restrict/block its internet access.
If you need to restrict internet access, you must be sure your blob storage is reachable, your options are:
Open whichever firewall/NSG to that storage account
Using service endpoints, service endpoint policies
Project a Private Link endpoint into the VNET from the storage