azure service accesible to only certain azure websites - azure

I have a bunch of REST services running in a VM in azure. I'd like to consume them from azure websites in a secure way. I.e. I don't want these services to be accessible from anywhere other than the azure websites.
Is it possible put this limitation? I know that I can limit access to the endpoints by providing IP address ranges but websites don't have fixed IP addresses.
thanks

If you set an unique IP can do it. But remember what the static IP are not available in all web hosting plans.

Related

How to whitelist multiple ip addresses to multiple different azure services?

Right now we have multiple resources like storage accounts and key vaults where the team is using the firewall setting within the networking tab on the individual services. This means when their ip changes after a disconnect/connect to the company VPN they have to go in to each service and add their new IP address.
Not being well versed in Azure networking possibilities, what are some of the options we have to allow a group of incoming IP addresses to be able to access all these services without having to individually touch each service to add their new ip address?
All services are also on the same virtual network.
Thank You
I used to work on Azure Cloud services as a DevOps in the past.
There should be multiple ways to control incoming network traffic to your landing zone or azure resources. But you should consider your requirements meet the solution.
Here are few you could take a look at which I used:
Virtual network service endpoints
Azure Firewall
Network Security Groups
ExpressRoute

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.

Reserved outbound ip addresses for Azure websites

Currently creating websites in Azure and was wondering if there was a way to create reserved static outbound ip addresses for those websites. I am not creating and loading the websites via virtual machines or cloud services, just directly through the Azure websites option in the Azure portal. I read that by default, a virtual ip per region for your subscription is supplied but We don't want to provide this ip address to whitelist. Can anyone please help point me in the right direction? Thanks.
This is currently not possible with Microsoft Azure.
The outbound IP will be one of the IPs in the datacenter. The list of IPs in the datacenter can be found here.
The good news is that Microsoft are planning to make this feature available soon.
Now its possible!!!
you can use App Service Environment(ASE)
App Service supports dedicated outbound IP addresses for apps deployed using the App Service Environment (ASE) feature.
For the forseeable future, apps running in the public multi-tenant service will continue to use outbound addresses from a shared address pool.
from Dedicate outbound ip
ASE is very costly :)

Azure: Getting internal IP - for a WEBSITE - to create access restrictions

Background:
I'm hosting 2 separate Website instances - 1 for a WebAPI2 "API", and 1 as an MVC5 "Client" that consumes said API. I would like to restrict access for the "API" to the "Client" (there are multiple clients)
(I've only seen answers for Cloud Services or VMs, so wanted to ask if there was anything I could use for Websites. I don't want to use a cloud service or a VM, as the website is faster, lighter, cheaper - which is what I need.... could not find a firewall feature for Websites in Azure.)
Problem:
I believe I can limit access to the "API" by setting parameters in the project's Web.Config file.
But nslookup in the command prompt yields the same IP Address for all azure websites under my account.
Question:
How do I find the right IP Address -- one that the "Client" website will use to access the "API" Website instance?
If there is a better way to restrict access...please do suggest it.
You cannot secure your site by IP ACLing as web sites in Azure are running in a multi-tenant environment and they share set of IP addresses (IP addresses are per DC).
You need to rely on different security mechanisms (using some secret which only client/server know etc.).
Hope that helps.
You can also take a look at How to determine Azure website outgoing IP Address?
Petr

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