I need to configure Azure SQL Database firewall settings so that it can only be accessed by my Azure Function app. The problem is I'm running the app in a consumption plan, and as far as I know, the outbound IP address(es) can change even when I don't take any actions.
Is there a way to whitelist the app so that I protect the database from unwanted connections?
I thought of whitelisting by Azure region since everything is hosted in the same region, but then how do I guard against other apps in the same region? That's why I'm thinking of using specific IP addresses. My only concern with this approach is, I don't know if other function apps can share the same outbound IP addresses as my own.
P.S. Currently, my firewall settings deny public network access and allow Azure services to connect only.
There are several ways to achieve this.
You may want to integrate VNet or get static IP addresses for your Azure Functions
Image from: https://learn.microsoft.com/en-us/azure/azure-functions/functions-networking-options
However, what I've seen from your comments you don't want to go the premium plan.
The last thing I can suggest you implement Managed Service Identity.
The idea behind this, instead of connecting the database with connection string, you connect to the database with the access token that you granted. You can't get the access token if you are not in the same Identity.
This tutorial explains the general idea with App Service:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-connect-msi
and this tutorial pretty much covers what do you really want to achieve.
https://www.azurecorner.com/using-managed-service-identity-in-azure-functions-to-access-azure-sql-database/
Good luck!
I had the same issue but managed identity didn't make much difference.
In the firewall setting for the SQL server there is an option to allow azure resources to access the server. For me this was set to no, but needed to be set to yes.
One thing you can do is assign a managed identity to your function. It will retrieve a token from Azure AD, and it will be used to connect to Azure SQL:
if (accessToken != null) {
string connectionString = "Data Source=<AZURE-SQL-SERVERNAME>; Initial Catalog=<DATABASE>;";
SqlConnection conn = new SqlConnection(connectionString);
conn.AccessToken = accessToken;
conn.Open();
}
https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/tutorial-windows-vm-access-sql
You can do this by assigning a static IP to the function app and whitelist at the SQL Server -INbound Networking side and Deny all requests. However you have to change the consumption plan to Appservice to assign a static IP.
https://learn.microsoft.com/en-us/azure/azure-functions/ip-addresses#dedicated-ip-addresses
Also, you can try creating a Vnet peering for those services and block other requests.
I can't find where i got the answer (so not my answer but sharing it here), your Azure Functions have a list of outboundIpAddresses and possibleoutboundIpAddresses that you can add to your Azure SQL firewall rules (mine had about 10).
You can find them by...
Go to https://resources.azure.com
Expand Subscriptions -> [Expand your Subscription] -> Providers -> Microsoft.Web -> Sites
Find your Azure Function Site in the JSON, and locate the outboundIpAddresses and possibleoutboundIpAddresses, these will contain a list of IP addresses.
Add all of them to your SQL server's firewall.
While I'm not positive if these will ever change, so far they haven't for me and the person who originally posted this solution also noted that they haven't run into issues with this.
Virtual networks do not work on Azure the same way as they work on premises
If you create a vnet, add your Azure function in a subnet and in sql server you allow this subnet to access it will unfortunately not work.
If it is ok for you to allow "public access" and/or "azure resources access" then things are simple. You log in with sql credentials and you have access.
If you block public access I am not sure that your resources would be able to access your database, because all your connection go to SQL server from the internet not from your internal network.
Solution that worked for me is
Create a vnet
Create a private endpoint for Sql server in this vnet (custom DNS records were created by the IT-OPS people).
Azure function uses a subnet of this vnet.
Now, you can close public and azure resources access in your database.
All your calls will go through your virtual network (not through the internet anymore) and only applications that use a subnet of this vnet would be able to connect to the database.
Related
If I am setting up an Azure SQL Database in a vnet which Azure App Service and Azure Function will access. Is using both Subnet Delegation and Service Endpoints the right way to go? I didn't fully understand the documentation.
Regarding subnet delegation, I read this Microsoft article and this stackoverflow post, which stated:
When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner.
That sounds like a good thing but makes me wonder how it worked efficiently w/o subnet delegation.
As for Service Endpoints, I read this Microsoft article, which states:
Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services over an optimized route over the Azure backbone network. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Service Endpoints enables private IP addresses in the VNet to reach the endpoint of an Azure service without needing a public IP address on the VNet.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
They both sound like they have the same benefits and I'm struggling to understand the difference. I suppose the larger question is should I enable both for the simple architecture outlined above.
In the Microsoft service endpoints documentation they also mention:
Microsoft recommends use of Azure Private Link for secure and private access to services hosted on Azure platform. For more information, see Azure Private Link.
For some reason that seems like an Azure to on-premise thing.
• You cannot use a ‘Subnet Delegation’ along with a ‘Private endpoint’ since that subnet is delegated for the said service, in your case, the Azure SQL Database. Through a subnet delegation, you can define the NSG association for it, as well as associate multiple delegated subnets to a common NSG. You can also define the IP Address space for the delegated subnet, the route table association with it, the custom DNS entry configuration in Azure DNS as well as define the minimum number of IP Addresses available for that delegated subnet. Similarly, with regards to service endpoint, these stated functions are not available.
• In service endpoint, you do not have control over the routing mechanism as well as the IP address related allotment, reservation, or configuration. Also, managing DNS entries for the resources managed through them and controlling them through a firewall or NAT gateway isn’t required unlike a subnet delegation because all these things are managed by Microsoft Azure’s backbone network on your behalf.
Thus, both have their own features and specifications for enabling you to configure according to your own requirements.
Does that mean I cannot reach the Azure SQL Database from my home machine w/a firewall rule?
Yes, you will have to create a firewall rule to allow the access from on-premises system to Azure SQL Server/Database and configure the service endpoint accordingly to allow the VPN client IP Addresses for accessing the same over public internet.
Also, through Azure private link, you won’t be able to connect from on-premises to Azure as it uses a private IP address and a private DNS zone entry related to it to connect to Azure resources in the same virtual network.
To know more regarding the configuration of Azure service access from on-premises network, kindly refer to the below given link: -
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-service-endpoints-overview#secure-azure-service-access-from-on-premises
Also, refer to the below snapshots regarding the configuration and selection of service endpoint for a particular subnet: -
I'm trying to configure an app service such that it has a private link setup into our VPN enabled vnet but also allow public access (e.g. to allow front door and our devops agents access).
The docs (https://learn.microsoft.com/en-gb/azure/app-service/networking/private-endpoint) note that "by default" public access is diabled, to me that sounds like it is possible to not have the default, is that actually possible?
I'd rather not route everything through our vnet (using hub and spoke design) because to my mind that adds a single point of failure we don't need, e.g. having front door connect to the app service over the MS backbone means it isn't reliant on my vnet infrastructure. But the vpn access is useful for internal access direct to the app service.
I also asked this on the MS forums and with some help came to what i think is an acceptable answer: https://learn.microsoft.com/en-us/answers/questions/968600/app-service-using-private-link-but-still-need-publ.html
I have a application running on a AKS Container and would like to use the Azure Cosmos DB for storage. How can i set this up?
I think i just need to specify the ip address from which the requests are originating on the k8s cluster so that the cosmosdb will allow access.
Should this traffic go over the internet or is it possible to set up a connection between the vnets?
To connect to CosmosDB easiest way is to just use SDK provided by Microsoft in your app. You just provide your app a connection string to your database, here is a simple quickstart example. You don't have to open any network traffic on CosmosDB side if you use default configuration, but of course if you wish you can lock access to only selected networks. So if your containers have internet access they can also access your database.
To address your second concern to not go over internet you can get more information here.
To allow access from existing virtual network using portal you need to go to the cosmosdb resource into firewall tab and add existing network, you should see something like this:
We have three App Services in Azure (API1, API2, API3).
API2 is getting data from CosmosDB.
API3 is getting data from other CosmosDB.
Main API1 calls API2 to get some data. Then using this data calls API3.
We have poor performance of API1 and we are trying to figure out why. We noticed that there are too many connections in metrics. Also we have issue with SNAT ports.
We tried to setup these APIs to the same VNet but it doesn't help and we are not sure how to set up it correctly.
Do you have any idea what we should setup?
UPDATE:
Seems like VNet helped us with SNAT ports issue but performance of API was still very poor.
What really helped us was change from Windows to Linux. When all APIs runs on the Linux servers we don't see any connections anymore.
Not sure what's specific configurations about three APIs on your side. If you want to use IP from Vnet instead of an external one, you can use a separate environment ASE.
Alternatively, you can use a private link to the app service. By using Private Endpoint, you can connect privately to your web app. Read Connect privately to a web app by using Azure Private Endpoint (Preview).
Today, you can secure this connection using VNet service endpoints
which keep the traffic within the Microsoft backbone network and allow
the PaaS resource to be locked down to just your VNet. However, the
PaaS endpoint is still served over a public IP address and therefore
not reachable from on-premises through Azure ExpressRoute private
peering or VPN gateway. With today’s announcement of Azure Private
Link, you can simply create a private endpoint in your VNet and map it
to your PaaS resource (Your Azure Storage account blob or SQL Database
server). These resources are then accessible over a private IP address
in your VNet, enabling connectivity from on-premises through Azure
ExpressRoute private peering and/or VPN gateway and keep the network
configuration simple by not opening it up to public IP addresses.
For more information, you could read here.
I heard about the new update on Azure SQLDB that it can be connected to vnet but can't find any blogs on this new information.
Can someone throw some light on this information?
Now, it is supported. Please refer to this blog.
Azure SQL Database will allow you to set firewall rules for specific
public IPs, and will give you the option of allowing all Azure
Services’ IPs to connect to your Servers. If you're looking for finer
grained connectivity limitations, you would have to provision a Static
Public IP, which can be hard to manage and costly when done at scale.
Virtual Network service endpoints will allow you to limit connectivity
to your Azure SQL Database Servers from given subnets within a Virtual
Network.
You could do it on Azure Portal. Please refer to this link.