Short question, I have a SQL Server and a Website running on App Service, and I want to ensure private connectivity between them, should I put them in separate Vnets or in the same Vnet?
You may refer to this example scenario which describes how to securely connect a web app to a backend database over a fully private connection.
The architecture ensures communication from the web app in Azure App Service and Azure SQL Database only traverses a virtual network.
Refer to detailed workflow mentioned here.
Related
I'd like to configure my Azure Sql Database to only be accessible from certain Azure App Services. These App Services are in different regions than my DB.
What I've tried so far:
Firewall IP-restriction. This "works", but doesn't provide much real security. Outbound IPs are shared between many App Services. It's trivial for a malicious user to create a new App Service with the same outbound IP.
VNet Service Endpoints. This only works if the App Service and DB are in the same region.
Have you tried with a private link?
I have a small environment with 2 app services and 1 DB, and the connection is being made by private link
If you have 2 different VNETs, try to do a peering so the VNETs can see the privante link
Microsoft Docs- Private Link to SQL Server
I have an Azure Web App and an Azure SQL Server, both in the same subscription. Both of them are connected to the same VNet Subnet as shown in the below snapshots. The SQL Server is configured not to Allow Azure Resources and Services to access the server, as it should only permit access from either the connected subnet or a set of IP rules.
Unfortunately, the SQL Server is actively refusing any connection from the web app stating that the web app IP is not allowed to access the server.
The interesting thing is that I have the exact same configuration working on another subscription.
What could I be missing?
Snapshots:
1- Here you can see the web application connected to the "webapps" subnet
2- And here you can see the SQL Server connected to the same subnet
3- And that's the error I get
TLDR
The configuration is correct, but an app service restart may be required.
VNET Integration
The configuration of using a virtual network to connect a web app to a SQL database is correct: if the web app is connected to the same subnet/vnet which is allowed in the database's ACLs, and the Microsoft.Sql service endpoint is enabled on the subnet, the web app is able to communicate to the database. This is the whole reason for service endpoints: you do not need to configure with IP allowances on the database.
As to why the configuration still resulted in an error, it could be the order in which the resources were configured. We were experiencing the exact same setup and issue (which is what let me to this question)!
We connected our web app to the subnet/vnet but had not enabled the service endpoint on the subnet. We then added/allowed the subnet/vnet as an ACL in the database, during which we were prompted to enable the Microsoft.Sql service endpoint (we did). However, even after waiting ~20 minutes, we were still seeing the same connection issue.
However, once we restarted the app service, the issue went away and the web app could connect to the SQL database.
I suspect the issue is due to enabling the subnet's service endpoint after the app service was connected to the subnet. The app service must need a restart to refresh the app service's vnet config/routing.
Configuration NOT needed
Contrary to other answers, you do not need to configure firewall IP allowances nor enable access to Azure services and resources. In fact, there are downsides to both approaches:
Enabling access to Azure services and resources allows any Azure-based resource to connect to your database, which includes resources not owned by you. From doc:
This option configures the firewall to allow all connections from Azure, including connections from the subscriptions of other customers.
Unless you're using an App Service Environment (which is significantly more expensive than normal App Service plans), your web app's outbound IP addresses are neither static nor specific to your application. From doc:
Azure App Service is a multi-tenant service, except for App Service Environments. Apps that are not in an App Service environment (not in the Isolated tier) share network infrastructure with other apps. As a result, the inbound and outbound IP addresses of an app can be different, and can even change in certain situations.
The second point is further elaborated upon in this Github issue:
IPs are indeed shared with other App Service plans (including other customer's plans) that are deployed into the same shared webspace. The network resources are shared among the plans in a workspace even if the computing instances are dedicated (e.g. in Standard tier). This is inherent to the App Service multi-tenant model. The only way to have a dedicated webspace (i.e. outbound IPs) is to deploy an App Service plan into an App Service Environment (ASE) (i.e. Isolated tier). ASE is the only thing that offers true single-tenency in App Service.
So neither of the above options will truly harden your SQL database if you want to isolate communication from only your web app. If you have resources in the same subnet, using vnet integration is the correct way to solve the problem.
If resources cannot be in the same subnet, the solution is to use Private Endpoints.
Virtual networking in Azure is quite different from how it would work on premises.
I had similar problems in production environment and digging deep, the working solution (meeting security standards and create a secure connection to the database) was to create a private endpoint for SQL access in the virtual network. Then all the calls to the SQL were performed internally (it did not go on the internet), and the databases were denying all public calls.
In your case now, you deactivated the Allow Azure apps to access so when your app is trying to access the SQL the server checks the ip to find out if it is white listed or not. So fast solutions would be one of the following:
Enable Azure Web apps to access SQL
Find all outbound IPs of your web app and register them in you SQL firewall/ security settings.
If you talk about a proper production environment with security regulations I would suggest you go down the more tedious path of private endpoints.
You have to configure the outbound IPs from the app service in the sql fw.
You can find them under properties of your app service. Documentation.
The reason why is that the VNET integration doesn't give your app service an outbound IP in the VNET you configured it in, so the FW you configured doesn't work.
I have working web apps which access storage accounts and KVs. These storage accounts and KVs accept traffic from a particular subnet and the web apps have been configured to integrate with those subnets. I did face an issue where even after integration apps were not able to access these resources. What worked for me was, I changed the App service SKU from Standard to Premium and restarted the app. As you can see, it warns that "Outgoing IPs of your app might change". This is not guaranteed solution but it worked for me.. several times! Not sure about SQL server though. Private endpoint does seem like the way to go but you can give this a try.
My client has a SQL Server instance installed on an Azure VM.
I am building an Azure Logic App and the end result is to write to this SQL Server instance.
To connect to this SQL Server instance running on the Azure VM do I need to treat it the same way I would as an on-prem SQL Server and install the gateway softwaare, or is there a better way since the VM is in Azure?
You shouldn't need to use a gateway. A gateway is mainly used for securing the data connection from a cloud service to an on-prem datbase, since the traffic goes over the public internet.
With the DB on an Azure VM, you can deploy your logic app into an integrated service environment. This keeps the traffic between logic app and DB on the private VNET. See the documentation on ISEs here.
I have a large SQL server hosted in our infrastructure, and an Azure resource set up with VPN access to our servers.
I want to create an Azure Function that connects to this SQL server. It's going to be a webhook endpoint to save to that DB. I don't need the overhead of an App Service Plan, I want the lightweight Function and the cheaper consumption pricing model.
All the tutorials online refer to App Services and Hybrid Connections that don't appear to be available in to Azure Functions on Consumption Plans.
I also want to keep the connection string configuration in Azure, and not hard-coded in the source or publish (which will ultimately be via CI).
The Azure Function is currently coded in C# in VS2019, but I can change that if it helps.
How do I set this up?
This option is not available on consumption plan. There is a already user voice open for this.
https://feedback.azure.com/forums/355860-azure-functions/suggestions/33398398-add-support-for-hybrid-connections-to-consumption
Yes it is possible. You would need to use something like Hybrid Connection. Does not matter which IDE you used to create the function.Check out the following link.
The Hybrid Connections feature requires a relay agent in the network
that hosts your Hybrid Connection endpoint. That relay agent is called
the Hybrid Connection Manager (HCM). To download HCM, from your app in
the Azure portal, select Networking > Configure your Hybrid Connection
endpoints.
Azure App Service Hybrid Connections
I azure we can create Hybrid connection to local sql server from Web Sites and Mobile Service. But I need to create Hybrid service to My Local SQL server from VM or cloud service. Is there anyway to achieve this one?
You can, actually.
The tool is called the Microsoft Azure Hybrid Connection Client
This runs as a service on your VM, and you add Hybrid Connections to it.
(That is, it = the VM that needs to talk to the on-prem asset.)
When a connection is added, a HOSTS file entry is made for the particular dns name and is routed through Azure to your on-prem Hybrid Connection Manager.
The Connection String you add will be the 'Application' one(s), which you will find in the old portal
According to Microsoft Hybrid connection will support only for WebSite and Mobile Web Services.
So I couldn't directly achieve my requirement. But alternative way is, implement the WCF service which can be hosted as WebSite.Now you can hosted your SQL database locally and create hybrid connection to the database from WCF service.Then you can call your WCF service from VM or cloud service.
Thanks,
Erandika