I have a web app that is currently deployed in an App Service Environment. One of the advantages of this is the security offered by the VNet within which the ASE resides.
Unfortunately this is a very expensive option for a low traffic solution (currently costing approx. £1500 a month). Is there an alternative solution that offers the same level of security as the ASE solution, e.g. is it possible to deploy a standard Web App to a VNet?
Yes and no.
A way to do that would be to use VNet integration of a WebApp. Unfortunately, it doesn't isolate the WebApp from the internet (that can be done via the webconfig). The other problem is that it only allows the webapp to access resources inside the VNet, not vice-versa. For that you would have to allow resources to access WebApp from the internet.
No other way currently.
It is not possible to deploy an Azure web app to a VNET (allowing for 2-way communication) without using App Service Environment (ASE). If you want your web app to only be available to internal systems, you'd have to rely on IIS ipSecurity config (https://www.iis.net/configreference/system.webserver/security/ipsecurity).
Essentially, whitelist all allowed public IPs (from the systems accessing the website). This might get difficult to maintain, so you might want to investigate a reverse proxy type solution either deployed in IaaS, or use AppGateway, or use a 3rd party such as incapsula/silverline.
As it has already been mentioned, Azure Web App cannot be added to your VNET. There is a VNET integration option which allows it to act as a P2S client, however it may not be acceptable in all scenarios. Here are the alternate options:
Azure Cloud Services (PaaS)
Azure Virtual Machines (IaaS)
App Service Environment (Expensive)
I think the best option would be cloud services as it can sit inside a VNET and provide some benefits of being a PaaS based service. Refer here: https://learn.microsoft.com/en-in/azure/cloud-services/
Related
We have some dedicated LOB application on-premise applications. Access to these apps is through the public Internet. Active Directory Domain Services is used to authenticate users.
In Azure, there are multiple ways to create high-availability; is there something similar for on-premise apps using Azure? By this I mean if one on-premise system is down, traffic is routed to another app.
I know there are some options such as Application Gateway, Traffic manager and Front-door including Azure LB, my question is - are these the right services we should use in an on-premise setting?
For your on premise environment, you can use Network Load balancing(NLB) feature of Windows Server. See details here, it has an Azure inspired feature too.
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.
I already have a domain name purchase from Google Domains.
I would like to host this site on Microsoft Azure, How should I plan to purchase all the required resources on Azure, if I want to host a Wordpress site, but would also need control over the size, if in future I plan to host some microsite with NodeJS or any other technologies like Java or .Net Core.
What would be my cost per month considering the above requirements?
Below is the list that I envisioned that I may need, can anyone suggest something this I missed.
A VM with Ubuntu (That would take care of Wordpress, Database(MySQL), NodeJS, Java and others)
Map my domain with Azure and map it with the VM
The solution you're thinking of is also known as IaaS (Infrastructure as a Service) and it is something you'd usually consider when migrating from an on-prem solution where you already have the VMs images for your needs.
In your particular case I'd recommend looking into PaaS (Platform as a Service) - specifically Azure App Service.
Everything you enumerated can be hosted in an Azure App Service as it supports all major technologies for deploying web apps today (.Net, Node.js, Java, etc).
In addition to your own code, Azure offers a number of build-in templates for 3rd party vendors that allow you to deploy pre-packaged solutions such as Wordpress without having to worry about the installation yourself. See this Wordpress on Azure article for more details.
Pricing information for Azure Web Apps can be found on the docs page. In your case I suspect you could do with a B1 or S1 instance.
Lastly, for your domain name, you can easily map and configure any custom domain to an Azure Web App by simply updating the DNS records in your Domain Management system and reference that in the Azure Portal. See docs for details.
Adding to Alex's response. To provide you a good understanding on hosting website on Azure. Firstly, I wish to highlight that Azure offers several ways to host websites: Azure App Service WebApps (PAAS solution), Virtual Machines (IAAS), Service Fabric, and Cloud Services.
Azure App Service (PAAS solution) is the best choice for most web apps. Deployment and management are integrated into the platform, sites can scale quickly to handle high traffic loads, and the built-in load balancing and traffic manager provide high availability.
WebApp is a fully managed compute platform that is optimized for hosting websites and web applications.
If you wish to host your website/app on an Azure VM (IAAS solution), you would typically install, design and configure the app in a similar way as you would onprem. If you have an existing application that would require substantial modifications to run in App Service you could choose Virtual Machines in order to simplify migrating to the cloud.
Take a look at the supported and unsupported configuration on App Service Migrate - Migration checklist when moving to Azure App Service : https://azure.microsoft.com/en-us/blog/migration-checklist-when-moving-to-azure-app-service/
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.
We have an application running in Azure that consists of the following:
A Web App front end, which talks to…
A WebApi running as a Web App as well, which can (as well as a couple other services) talk to…
A Cloud Service load balanced set of VMs which Are hosting an Elasticsearch cluster.
Additionally we have the scenario were dev’s whitelist their IPs so that their localhost version of the API can hit the VMs as well.
We have locked down our Elasticsearch VM’s by adding ACLs to the exposed end point. I whitelisted the outbound IPs that were listed on my App Services. I was under the mistaken impression that these were unique to my Api. It turns out that these are shared across the scale unit in Azure. Other services running in the same scale unit, could, if they knew the endpoint, access the data exposed on the endpoint in my cluster. I need to lock this down, and I am trying to find the easiest way. These are the things I am looking at, and I would appreciate advice and/or redirection.
Elastic Shield: Not being considered. This is a product by Elastic
that is designed to secure ES. This is ideal, but at the moment it
is out of scope (due to the cost and overhead)
List item
Elastic plugins: Not being considered. The main plugins (such as
Jetty) appear to be abandoned.
Azure VPN. I originally tried to set this up, but ran into too many
difficulties. The ACLs seemed to give me what I need without much
difficulty. I am not sure if I can set this up now. The things I
don’t know are:
I don’t think I can move existing VMs into a new VPN.
I think you have to recreate the VMs in that VPN from the get go
Could I move my Web App into the VPN? How does that work?
This would prob break my developer scenario as the localhost API
would not be able to access the VPN, right?
Add a certificate to requests: It would be ideal if I could have
requests require a cert or a header token. I assume to do this I
would need to create a proxy that would run on the VMs and do the
validation before forwarding the request on to my Elasticsearch.
Anything else? Is there another option I have not thought of?
Thanks!
~john
You can create a VPN point-to-site connecting your Web App with your IaaS VMs. This is the best solution because you will be able to use just internal IPs on your IaaS.
The easiest way to do that using Azure Portal is create a Web App and, create a new VPN and VNet using "setup" option at "Your Web App" -> Settings -> Networking -> VNET Integration -> Setup -> Create New Virtual Network.
After that, create your IaaS inside this new VNet.
You also can create a ARM template to create Web App, IaaS, VPN and everything that you need. Take a look at my ARM template to create PHP+MySQL using Web App and MariaDB Cluster connected by VPN: https://github.com/juliosene/azure-webapp-php-mariadb