I am searching for a solution to expose an Azure SQL DB table over the Azure API Management and then allow a Kubernetes hosted app to talk with the Azure SQL DB over this API. What would be the less time consuming approach for building this API to expose the table?
I have found doc for couple of solution, but coming from the BigData world, I couldn't figure it out which is worth to invest the time and to build it. Any suggestion where should I take a closer look?
For example this one: https://www.youtube.com/watch?v=U6SlmoXWf3o
What is the configuration of your Azure SQL server. By default the networking configuration of the server is always "Allow all".
This setting can be found at Firewalls and virtual networks.
When Deny public network access is set to Yes, only connections via private endpoints are allowed. When this setting is No (default), customers can connect by using either public endpoints (with IP-based firewall rules or with virtual-network-based firewall rules) or private endpoints (by using Azure Private Link)
Related
I currently have the following setup in Azure:
An Azure API Management API that maps to
an Azure Function App with multiple functions that accept data and store it in
an Azure Storage Account.
A private (no public access) Azure SQL database.
Now I want to add a few more API endpoints and Azure functions that provide access to some data from the SQL database. I am now facing the problem that my Function App and API Management are public and therefore cannot connect to resources within my VNet (i.e. the database).
Is there a way to have functions connect to the private database without making the functions private, too? And if I have to make the functions private I would also have to make the API Management private, right? Which would make the whole API unavailable from the internet.
The plans for API Management and Function App that support VNet integration are way more powerful and expensive. I don't need so much power, just the VNet integration.
Does anyone know how to solve this issue?
Before deploying APIM myself, I did some research on how to create a similar setup, where most of our backend services (azure functions, app services etc.) live inside a virtual network. Note that we are still using the developer SKU for API Management, it has almost the same features as the premium SKU (source). For our use case, developer tier has enough bandwidth and the premium SKU is pretty darn expensive. The developer tier is not backed by a Microsoft SLA, so be careful using this in production environments. Below, I'll start with a short summary and describe the scenario's at the end.
Summary
I hope this overview highlights some of our concerns, which may help you to decide the best fit for your scenario. In the end, we choose scenario two, which provides the necessary security we needed. It reduces the attack surface because all backends are private. The main reason is that we wanted to use consumption plan logic apps. Standard logic apps are expensive and not really user-friendly in terms of deployment. With an additional Front Door in place, it also enables us to easily move to solution three at a later point in time. Since you don’t have to move around with custom domains and certificates when putting APIM private, Front Door still remains your main entry point.
1) Scenario one
APIM without vnet integration (public)
Azure Function with Vnet integration
Azure SQL and Storage with private endpoints
Pros: In this scenario your are able to choose APIM standard or basic sku. These are a lot cheaper than the premium sku.
Cons: The Azure function is exposed to the public internet, so be careful and protect it with AAD authentication. When you would deploy multiple azure functions like this, it increases the attack surface.
2) Scenario two
APIM with vnet integration (external mode)
Azure Function with private endpoint
Azure SQL and Storage with private endpoints
Pros: Setup is not that difficult if you follow the APIM vnet documentation (source). May be useful if you want to expose your APIs to external parties as well. Everything behind APIM resides securly within a virtual network.
Cons: Only developer and premium tiers are available for this setup. APIM is reachable over the public internet, so make sure you put in the necessary policies that always checks the JWT. You could even put in a policy that check's the IP address, basically a poor man's firewall solution.
1) Scenario three
APIM with vnet integration (internal mode)
Azure function with private endpoint
Azure SQL and Storage with private endpoints
Optional: Application gateway with or without Front Door to safely expose certain routes to the outside world.
Pros: Most secure solution, since everything is shielded from the public internet. I would call this the preferred enterprise setup. If needed, you could even extend this setup with an application gateway with or without Front Door to control who has access to certain API’s from outside the virtual network.
Cons: This is the most extensive setup, meaning that it takes a lot more time to deploy. You have to take into account all the necessary routes, NSGs, private DNS entries, etc. Advisable to be familiar with azure policies as well to do some of this automatically.
Note: APIM is going to support private endpoints as well in the near future, which is a bit confusing. I would say the two vnet modes are already comparable to how you would use vnet integration and private endpoints for azure functions and app services.
You can achieve this with a VPN Gateway
This means the VPN Gateway provides a public IP to your VPN!
So the public Azure Functions can access the VPN resources.
Tutorial: Create and manage a VPN gateway using the Azure portal
A better approach is, to use the internal mode of API Management:
Connect to a virtual network in internal mode using Azure API Management
With Azure virtual networks (VNets), Azure API Management can manage internet-inaccessible APIs using several VPN technologies to make the connection. For VNet connectivity options, requirements, and considerations, see Using a virtual network with Azure API Management.
I'm finishing a desktop App (Winforms). Azure MS SQL on server-side and WinForms clients. So they can come from unpredictable IP... So its impossible set new firewall Azure rule for every client network move...
My question what is the best approach to secure access from clients and how to set Azure firewall rules...
(the client uses a SQL server login)
on some forums, people recommend bypassing the azure firewall by setting rule 0.0.0.0-255.255.255.255 but it does not seem as good secure solution for me)
possible solutions I'm considering:
a) Setup a VPN on AZURE for the client (any tip for a good tutorial, and how to limit client traffic only for AZURE = client watching youtube will not spend my azure budget?
b) any third party VPN? (most of the VPN providers don't offer permanent IP but dynamic range)
c) another way
Thanks!
Pavel
I would suggest a Client, Server, Database architecture. As a rule you generally don't want your clients connecting directly to a database. If you configure a WebAPI to contact the DB and allow your clients to communicate with that API it would be a much better approach
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.
For security concerns I'm planning to not allow Azure services to communicate with Azure services but the services it is only working with.
For example, I've some web apps that uses Azure SQL Databases. Should I only add the outbound IP addresses of Azure Web Apps in the Azure SQL server firewall?
or I need to do something else?
This is not as easy as it should be. SQL Azure is not designed to be virtual network friendly so your only options are "Allow all Azure services" or hard-coded IPs. Unless your web apps have static IPs however, this won't be possible without writing a custom updater for the database which picks up IP address changes.
You could install a SQL server onto a VM and use virtual private networks, otherwise, make sure the login credentials are secure and accept the fact that an Azure client from anyone could attempt to connect to your database server.
The best way to lock down your SQL Database is with AAD Integration, and Managed Service Identities. Azure will provision an AAD identity for your application, and only code running in that application will be able to generate an Access Token for that Identity. Then you can provision it as an AAD user in your SQL Server.
This has the (large) added benefit of removing the secrets from the application, so you don't have to configure your application with a Client Secret, or a SQL Login/Password.
You can also run your App on a VNet, and configure your SQL firewall to only permit access from that VNet using Virtual Network service Endpoints For Azure SQL Database.
Or use the newer and much better Private Link for Azure SQL Database.
Some of the ways to secure the connection to the sql database that could be considered in this case are -
As you mentioned you are already thinking of configuring a firewall to whitelist the allowed IP addresses. The firewall could be configured both on the sql server level and the database level(we can use SSMS to configure the firewall at the database level).
We can encrypt data. Of course this would be encryption at rest. And the good news is the application connecting to the database need not change to query encrypted data.
The third way would be the traditional way(even if we were not using azure db) we would prevent unauthorized access by creating users/roles/permissions.
A very nice feature I found Azure db provides is the Threat Detection Capability. If you turned that on we would be notified of the possible vulnerabilities of the current db/server setup. And also where can we make improvements to fix those issues.
Connect your Azure function with your SQL DB using private endpoints and VNET integration. Your app service will need to be standard or premium. Even Premium function plan will do. This LINK talks about it.
Authenticate your azure function on your SQL DB using managed identities. See this link for info on how to do that. Managed identities
In short yes.
You can possibly make this more secure by creating vnet connection from the web app and creating a service endpoint for SQL. I'm not sure that will work, but worth a try.
I have an existing on-premises web app that I'd like to migrate to Azure, just a basic migration to start with.
The current app is made up of two websites, a publicly facing front end web site and a private SOAP API site that is accessibly only via a VPN connection.
I can happily place the front end in a standard web app, but can't see a cheap way of hosting the SOAP API. I have used Azure Service Environments in the past, but this approach is expensive and a bit much for the early stages of this migration.
Ideally I would just host the SOAP API in an Azure Web Site and put a Gateway infront of it to manage VPN access. But I'm struggling to see if that is supported.
Is there anything else I can do here?
On the App Service hosting the API, have you looked into using the "Networking" blade to configure an IP restriction? This way you could limit access from only the IP address of your front-end.
Additional considerations:
There is no guarantee on a static IP for your front-end so you may need to consider range(s) based on what's in the DC you're app is hosted in (the IP doesn't change often but understand it's allocated from a pool that MS maintains). For this solution, you'd also need to include the IP of any client needing access for development/debug since it wouldn't use a VPN
You could also use a VNet to isolate services on the network and have more control over the configuration. Unfortunately you'd also need to deploy the app into an ASE which will add further costs. As a bonus, this would allow you to use a VPN as explained here: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-howto-point-to-site-resource-manager-portal
Good luck!
For example, you can create a P2S VPN from the web to Vnet, create another S2S or P2S VPN from on-premise to Vnet. And there can be an NSG associated to the Vnet, so you can manage the VPN access. I think the document Integrate your app with an Azure Virtual Network
could give you an idea. Unfortunately, you'd also need to deploy a VPN.