How do I restrict the clients that can access my Azure App Service? - azure

Given that I create an Azure 'App Service'
How do I ensure that this service is only callable from ...
A.> 2 existing external servers (whose IP addresses will be known)
B.> 3 other App Services which I will be creating, but whose IP Addresses may not be known since I may need to scale those out (Over multiple additional instances)
To clarify... Is there some Azure service that will allow me to treat this collective of machines (both real and virtual) as a single group, such that I can apply some test on incoming requests to see if they originate from this group?

on Azure WebApps, You may wish to know; the IP Restrictions (https://learn.microsoft.com/en-us/azure/app-service/app-service-ip-restrictions) allow you to define a list of IP addresses that are allowed to access your app. The allow list can include individual IP addresses or a range of IP addresses defined by a subnet mask. When a request to the app is generated from a client, the IP address is evaluated against the allow list. If the IP address is not in the list, the app replies with an HTTP 403 status code.
You can use IP and Domain Restrictions to control the set of IP addresses, and address ranges, that are either allowed or denied access to in your websites. With Azure WebApps you can enable/disable the feature, as well as customize its behavior, using web.config files located in their website.
Additionally, VNET Integration gives your web app access to resources in your virtual network but does not grant private access to your web app from the virtual network. Private site access is only available with an ASE configured with an Internal Load Balancer (ILB).
If you haven’t checked this already, checkout Integrate your app with an Azure Virtual Network for more details on VNET Integration (https://learn.microsoft.com/en-us/azure/app-service/web-sites-integrate-with-vnet)

I strongly suggest dropping the whole what's my IP approach and throwing in OAuth. Azure AD gives you access tokens with moderate effort —
Service to service calls using client credentials (shared secret or certificate)
Else, TLS client authentication would be next on my list. Although that tends to really suck if you have to deal with several programming stacks, TLS offloaders and what not.

Related

Communication between apps in same app service plan?

To clarify what I'm not asking about, there's alot of documentation about using endpoints to expose apps in a App Service Plan to a vnet, which is useful for private communication between vnet hosted VMs or other resources outside the app service plan.
What I'm asking about is specifically communication between two apps inside the same app service plan. So if we had PlanA, and AppB and AppC both deployed to that plan, then if PlanA scales to two instances, each instance would have both AppB and AppC inside it. Very similar to an IIS farm hosting multiple applications.
If I want to disable public access for AppC, but still allow AppB to call AppC(imagine if AppC is a API service and AppB is a front end web app), is that possible? How would you resolve that call if the AppC doesn't have a public IP? Would the domain appC.azurewebsites.net resolve to a privateIP that AppB can access?
The fact that two app services run in one app service plan means only that these app services can share the same set of computing resources (CPU, memory, etc.) and it does provide any network isolation or private IP addresses within an app service plan.
If you want to keep the existing setup and restrict access to AppC, you can whitelist IP addresses of AppB as follows:
Go to the AppB in Azure Portal, click Properties and copy the list of Outbound IP addresses.
Go to the AppC, click Networking -> Access Restrictions and deny access to everything apart from the outbound IP addresses you copied in step 1.
The domain appC.azurewebsites.net will still have a public IP address but Azure will only allow accessing it from the IP addresses you configured and return 403 error to any other client.
However, if you want to have a truly private endpoint and more granular control over routing configuration, then consider integrating your app services with Azure virtual network as described here. Virtual networks are not limited to VMs, they can be used for app services too.

How to allow access from certain IP to certain endpoints in Azure?

I have App Service which is classic web app written in Node.js. Let's say that my app have 2 endpoints: /SecuredEndpoint and /ClassicEndpoint. /SecuredEndpoint should be secured, meaning only certain IP addresses are allowed to access it. ClassicEndpoint on the other hand is public to whole internet.
I've found out that in Azure I can specify Access Restrictions to whole service for certain IP addresses (I can block/allow access based on IP address). But I would like to secure not the whole app but only certain endpoints.
Can someone help me how can I achieve that in Azure?
To restrict certain IP addresses is to restrict ACL in the networking layer. Access Restrictions are effectively network ACLs. However, it is implemented in the App Service front-end roles, which are upstream of the worker hosts where your code runs. In this case, you could consider selecting to use two app services for each endpoint. You can read supported security in the Azure app service.
Alternatively, you may allow certain IP addresses in your special code. Google some samples for such a feature. It might be like this SO thread. For App Service on Windows, you can also restrict IP addresses dynamically by configuring the web.config. For more information, see Dynamic IP Security.
In addition, If you are interested in securing Back-end App Service Web Apps with VNets and Service Endpoints, you could have a look at this blog.

Is it necessary to add Azure IP datacenter IP's to app service whitelist?

I have to restrict public access to my Azure app service, Hence I have implemented IP whitelist in web config. Is it required to whitelist the Azure datacenter IP ranges?
My app service uses Azure SQL, redis and search service.
Short answer to your question is no, you will not need to add Azure data center IP addresses for using Azure services. Only case where you need to add IP addresses to the allow list is when a service/application tries to access your web application and not the other way round.
Given your objective to restrict public access, you should definitely consider using the IP restrictions feature from Azure Portal. Microsoft has improved this feature and it's better than having just the web.config <ipsecurity> configuration,
With Azure App Service IP restrictions, traffic will blocked even
before it reaches your IIS.
You can still continue to use your web.config configuration as it is.
Configuration effort is pretty minimal as it's all available through portal
Read more about it here
Azure App Service Static IP Restrictions
For a time, the IP Restrictions capability in the portal was a layer
on top of the ipSecurity capability in IIS. The current IP
Restrictions capability is different. You can still configure
ipSecurity within your application web.config but the front-end based
IP Restrictions rules will be applied before any traffic reaches IIS.

Block traffic to Azure web Api which is associated to an ASE

I have created an App Service Environment and have multiple web app and web API associated with it. I want to achieve an arrangement where only my App service has access to the API, so trying to block traffic to the API using IP Restriction. But all the Web Apps as well as the web API has the same VIP and i cant find any other IP address associated with it.
Also to attach the NSG to the subnet(in which ASE is there), we need to add rules which again need specific IP. How can I achieve this?
I assume you have provisioned external ASE.
"App Service has the ability to allocate a dedicated IP address to an app. This capability is available after you configure an IP-based SSL"
So, you can limit the access to some of your apps inside the ASE by using App-assigned IP-based SSL addresses (Only possible with an External ASE and when IP-based SSL is configured).
When you provision your ASE, you can select how many external IP addresses the system should have including those for IP-based SSL purposes.
please see: https://learn.microsoft.com/en-us/azure/app-service/environment/using-an-ase#ip-addresses and slide nr.14 here https://8gportalvhdsf9v440s15hrt.blob.core.windows.net/ignite2017/session-presentations/BRK3204.PPTX

Azure Website Reserved IP

I've been trying to find an answer to this for a few days.
I want to host a new azure website in either the Basic tier or Standard tier.
The site will be calling a third party service.
I need to give this service provider an IP address that they will whitelist.
So when the new azure website makes requests to this service the IP address for the request needs to always be the same, as this will be the IP whitelisted.
I read that Azure offers "Reserved IPs" for cloud services and VMs but I wanted to know if something similar can be done with Azure Websites as I really don't want to go with cloud/VM.
My knowledge of networking is limited but as I understand it, if I were to get an IP SSL cert and apply that to my Azure Website then the website would have a static IP address.
If that is the case, would any requests to the third party service be hitting the service providers external firewall with this same static IP?
Thanks for any advice people can give.
An SSL cert with Web Sites will be tied to an inbound IP address. However, Web Sites does not provide a static outbound IP address.
If you need a static IP address to align with 3rd-party services, you'd need to have something residing in Azure (e.g. Application tier) running in a cloud service / VM that your web site accesses, and then have that app tier (with static IP address) communicate with your 3rd-party services.
As David Makogon's answer points out, applying an IP-based SSL certificate only gives the website a static inbound IP address.
However, the outbound IP address a website uses when making outbound network calls can be determined based on where your website is hosted. Microsoft has a list of the these IP addresses here. The third-party service would have to whitelist all of the IP addresses used by the scale unit your website is hosted in (e.g. waws-prod-am2-005).
Correct me if I am wrong, but the information shared by Brant Bobby above shows that, in fact:
All Azure websites (/Web Apps) already have a discoverable and published outgoing IP address.
This outgoing IP address will never be unique to their own site however. So one must keep in mind if they use it for a white-list, it will be allowing in a lot of other Azure visitors hosted on the same scale unit.
Simply get the so-called "scale unit" name for your site, which is the same as what's given in your site's FTP address (and so forth), which is in the format: "waws-prod-[3LetterVar]-[3DigitNum]", e.g. waws-prod-blu-007.
As an example from that article, all the East US region Azure websites can find the four IP addresses their site may rely on as follows (so if white-listing, all 4 should be white-listed):
East US Region
Outbound IP addresses for each scale unit, currently 4 for each. They said they may add more IPs to each scale unit in the future, but these should not change.
waws-prod-blu-001: 168.62.48.13, 168.62.48.19, 168.62.48.33, 168.62.48.122
waws-prod-blu-003: 137.117.81.128, 137.117.81.142, 137.117.81.181, 137.117.81.82
waws-prod-blu-005: 137.117.80.189, 137.117.81.52, 137.117.81.90, 137.117.80.178
waws-prod-blu-007: 23.96.33.205, 23.96.34.196, 23.96.35.20, 23.96.36.229
waws-prod-blu-009: 23.96.97.203, 23.96.97.233, 23.96.97.235, 23.96.97.238
waws-prod-blu-011: 23.96.112.60, 23.96.112.117, 23.96.112.152, 23.96.112.15
waws-prod-blu-013: 191.238.8.154, 191.238.9.80, 191.238.9.94, 191.238.9.170
waws-prod-blu-015: 191.236.19.222, 191.236.19.242, 191.236.21.165, 191.236.18.160
waws-prod-blu-017: 191.238.32.104, 191.238.32.154, 191.238.34.67, 191.238.35.12
waws-prod-blu-019: 104.45.138.197, 104.45.142.87, 104.45.128.144, 104.45.142.131
waws-prod-blu-021: 191.237.24.189, 191.237.30.36, 191.237.26.164, 191.237.28.161
waws-prod-blu-023: 191.236.50.206, 191.237.30.215, 191.237.25.148, 191.237.22.195
waws-prod-blu-025: 191.237.31.86, 191.237.26.176, 191.237.20.70, 191.237.18.239
Azure now supports having static outbound IP address as well.
https://azure.microsoft.com/en-us/documentation/articles/app-service-app-service-environment-intro/
If we do not want to go for costlier App Service Environment setup, we can directly use the outbound IP addresses mentioned in the Azure portal in properties section, Azure assures that it remain 99.9% static. Nothing really changes until there is some changes data center wide. Moreover, the reserved Ip what we use in IaaS is also not 100% reserved for us and azure provides SLA of 99.9% here as well. So, In my opinion, instead of going for ASE and hosting IaaS and using reserved IP, we can just use outbound Ip provided by azure, since we get same reliability in both cases.

Resources